Encryptr – Free, open-source password manager and e-wallet(encryptr.org)
encryptr.org
Encryptr – Free, open-source password manager and e-wallet
https://encryptr.org/
15 comments
There doesn't appear to be much crypto in this project; it's a small application built on SpiderOak's Crypton.io. I'm not a fan of Crypton, but it's not clownshoes crypto.
Just to be clear to everyone on the thread: it's very unlikely that there's anything practical an attacker can do with the modulus bias in a situation like this.
Just to be clear to everyone on the thread: it's very unlikely that there's anything practical an attacker can do with the modulus bias in a situation like this.
> Just to be clear to everyone on the thread: it's very unlikely that there's anything practical an attacker can do with the modulus bias in a situation like this.
Correct. This was just the first thing I saw in a cursory glance through their app.js file.
I haven't reviewed Crypton.io and can't say whether I like it or not. What don't you like about it in particular?
Correct. This was just the first thing I saw in a cursory glance through their app.js file.
I haven't reviewed Crypton.io and can't say whether I like it or not. What don't you like about it in particular?
> I'm not a fan of Crypton
Just curious - is this to do with using javascript crypto[0]? or something that goes beyond that?
[0] https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...
Just curious - is this to do with using javascript crypto[0]? or something that goes beyond that?
[0] https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...
JavaScript is only a real issue when you have an insecure code delivery mechanism. The article spells that out pretty well.
Yes, I understand. I was wondering why tptacek wasn't a fan though, and the only reason I could think of was that it might encourage this usage?? even though it looks like they explicitly discourage this[0]. It's the first time I hear of crypton.io - so just trying to learn more.
[0] https://crypton.io/docs/
[0] https://crypton.io/docs/
Encryptr's security bits are likely all implemented in the crypton framework. If you search the repo for that function (randomString), you'll see that it's only used in one place: to propose a new password (https://github.com/devgeeks/Encryptr/search?utf8=%E2%9C%93&q...). While it'd be best to not have any bias at all, this low bias only assists people trying to brute force passwords created by encryptr.
Crypton itself has been audited a couple times by crypto persons, see https://crypton.io/docs/security/audits.html
(disclaimer: i used to work at spideroak, but neither on crypton nor encryptr. i still think they're all awesome though)
Crypton itself has been audited a couple times by crypto persons, see https://crypton.io/docs/security/audits.html
(disclaimer: i used to work at spideroak, but neither on crypton nor encryptr. i still think they're all awesome though)
The contents of the second audit in particular deeply troubled me. Lots of simple but grevious mistakes. It's nice that they got the audit though.
FWIW, the audit happened directly in the middle of a dev cycle, without any of the normal internal review of that code first. The audit report describes those circumstances in the first few pages. Scheduling audits is hard work!
Yeah, especially when there are no clearly defined "sprints".
Biases caused by modulo reduction are dangerous when the source integer is relatively close to the target distribution. This bias is unlikely to be useful for attackers. The probability difference between the most likely output, 0, and the less likely outputs is 2^-32. For comparison, Cryptocat's bug had a much larger distance of 1/251 ~ 2^-8, which greatly reduces the amount of samples needed for distinguishing the output from random. EdDSA itself uses modulo reduction for the nonce, using a large enough source (~2^512 modulo ~2^252) value that renders the bias irrelevant.
This is using getRandomValues which is cryptographically secure. The account/login/privacy crypto is using SJCL and the entire app is a signed desktop or mobile application - (no remote code)
Yes, but see the other comments about how the % operator can introduce bias into an RNG's output.
What's wrong with window.crypto.getRandomValues?
Nothing in principle; it's the % operator that can biased the output.
Also, outside the scope of Cordova apps, Node.js uses OpenSSL rather than /dev/urandom for their crypto.getRandomBytes() implementation, so I don't really trust it in that context. ;)
Also, outside the scope of Cordova apps, Node.js uses OpenSSL rather than /dev/urandom for their crypto.getRandomBytes() implementation, so I don't really trust it in that context. ;)
% shouldn't decrease the entropy, modulo of random is still random.
If you generate 1000 random integers, but we know there's a 28% chance it will be 0 and a 14% chance it will be 1,2,3,4, or 5, a clever attacker can more accurately predict/brute force outputs.
When you're working with cryptography, you want a uniform distribution of possible values as well as unpredictable randomness.
When you're working with cryptography, you want a uniform distribution of possible values as well as unpredictable randomness.
For 0..max random integer it depends on max and length. If max is 2^32 and 2^32 modulo charset.length = 0 it should be fine. Am I right?
In our case length is 85 and it is indeed biased. Needs a pull request.
Correct, that's the edge case where it actually falls together neatly.
If you're starting with a random byte and charset.length is an even power of 2, you end up with no bias.
It's better to design functions like this to discard values outside of an acceptable range and try again until they generate a safe value (also, apply a & bit mask to reduce the number of retries). This allows you to accept any arbitrary charset size without being concerned about security.
See also:
https://github.com/paragonie/random_compat/blob/5aa6689651a5...
I'll open a PR tonight if nobody beats me to it.
If you're starting with a random byte and charset.length is an even power of 2, you end up with no bias.
It's better to design functions like this to discard values outside of an acceptable range and try again until they generate a safe value (also, apply a & bit mask to reduce the number of retries). This allows you to accept any arbitrary charset size without being concerned about security.
See also:
https://github.com/paragonie/random_compat/blob/5aa6689651a5...
I'll open a PR tonight if nobody beats me to it.
In theory, haha. In practice it gives me some numbers twice more. [2001954,
1000322,
998546,
1001551,
999105,
2000886,
998760,
998705,
1000001,
998424,
1000978,
2000907,
1002097,
998786,
1000101,
998818,
1000381,
1999818,
999662,
1001260,
999531,
1000076,
Your RNG is not cryptographically secure, I'd wager.
http://3v4l.org/DC0RM
http://3v4l.org/DC0RM
I thought instead of cutting off out of range results we could num*85/4294967296 and round it. But now realized buckets for rounding won't be of equal size and it's wrong.
This also works i guess
max = 100
length = 85
num = rand(max)
puts (num * length)/max
max = 100
length = 85
num = rand(max)
puts (num * length)/max
Entropy is maximized when the distribution probability is uniform. A biased random sequence has less entropy than the one of the same length which has uniform distribution.
Here's an example from Wikipedia (https://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle#M...)
"For example, assume that your random number source gives numbers from 0 to 99 (as was the case for Fisher and Yates' original tables), and that you wish to obtain an unbiased random number from 0 to 15. If you simply divide the numbers by 16 and take the remainder, you'll find that the numbers 0–3 occur about 17% more often than others. This is because 16 does not evenly divide 100: the largest multiple of 16 less than or equal to 100 is 6×16 = 96, and it is the numbers in the incomplete range 96–99 that cause the bias. The simplest way to fix the problem is to discard those numbers before taking the remainder and to keep trying again until a number in the suitable range comes up. While in principle this could, in the worst case, take forever, the expected number of retries will always be less than one."
Here's an example from Wikipedia (https://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle#M...)
"For example, assume that your random number source gives numbers from 0 to 99 (as was the case for Fisher and Yates' original tables), and that you wish to obtain an unbiased random number from 0 to 15. If you simply divide the numbers by 16 and take the remainder, you'll find that the numbers 0–3 occur about 17% more often than others. This is because 16 does not evenly divide 100: the largest multiple of 16 less than or equal to 100 is 6×16 = 96, and it is the numbers in the incomplete range 96–99 that cause the bias. The simplest way to fix the problem is to discard those numbers before taking the remainder and to keep trying again until a number in the suitable range comes up. While in principle this could, in the worst case, take forever, the expected number of retries will always be less than one."
[deleted]
This is one of the bugs found in CryptoCat.
http://tobtu.com/decryptocat.php
http://tobtu.com/decryptocat.php
^ hopefully i didn't sound too confident! Thanks for explanations.
To see the bias compare the last two pictures
https://www.wakari.io/sharing/bundle/jfs/Test%20PRNG%20using...
From http://stackoverflow.com/questions/16829183/what-is-pseudo-r...
From http://stackoverflow.com/questions/16829183/what-is-pseudo-r...
Encryptr does not ue node.js crypto at all. Just Blink and Webkit's getRandomValues, which is secure
Yep, this is why I prefaced my statement with "outside the scope of Cordova apps".
UX wins -
1. Readable typography.
2. Clean and simple flows.
3. Dedicated forms for credit cards, passwords, and notes.
UX shortcomings -
1. No way to tweak the password generator algorithm. This matters because different contexts need different things. EG mobile passwords should avoid special chars and be longer to tradeoff.
2. No way to search. In any reasonably long lived password file you will be unable to scroll through quickly enough.
3. No importer(s) for legacy password manager files.
1. Readable typography.
2. Clean and simple flows.
3. Dedicated forms for credit cards, passwords, and notes.
UX shortcomings -
1. No way to tweak the password generator algorithm. This matters because different contexts need different things. EG mobile passwords should avoid special chars and be longer to tradeoff.
2. No way to search. In any reasonably long lived password file you will be unable to scroll through quickly enough.
3. No importer(s) for legacy password manager files.
Also, both password gen configuration and (probably CSV) import/export are coming as soon as I can get them in there.
Search is coming in the next release!
http://monosnap.com/image/npl8jAtBNPAHUJAws8x4p3s3iAw36S#
I already have it (as I am a contributor). Its just getting better
http://monosnap.com/image/npl8jAtBNPAHUJAws8x4p3s3iAw36S#
I already have it (as I am a contributor). Its just getting better
Does it support self-hosting of the server part? If I could deploy it to one of my Digital Ocean servers easily, I could see it become my default (and last) password manager. I'm too small a fish for a hacker to actually hunt my own server, and even if they do... it's zero knowledge, so I think I'd be comfortable with that.
Side question: does it support sharing of secured notes and credentials? even to non-encryptr users?
Side question: does it support sharing of secured notes and credentials? even to non-encryptr users?
In theory, sure. Crypton.io itself is available on github and you could build your own server.
On the Encryptr app side, src/app.js uses window.crypton.host and _.port to specify the crypton endopint to connect to. I think the app store build of encryptr uses a crypton endopint at devgeeks.org.
You could just use (apache) cordova to roll your own build of the android app with app.js set to point to your preferred self-hosted endpoint.
YMMV.
Note: this is definitely a product at the MVP stage. The platform is capable of implementing data sharing, but that is not currently used by the Encryptr application.
On the Encryptr app side, src/app.js uses window.crypton.host and _.port to specify the crypton endopint to connect to. I think the app store build of encryptr uses a crypton endopint at devgeeks.org.
You could just use (apache) cordova to roll your own build of the android app with app.js set to point to your preferred self-hosted endpoint.
YMMV.
Note: this is definitely a product at the MVP stage. The platform is capable of implementing data sharing, but that is not currently used by the Encryptr application.
Indeed, you can do this and we encourage it. We are also building a private "feed" application called "Kloak", which resembles Twitter but is private and "un-dataminable".
See: https://zk.gs/ZK/kloak.pdf
See: https://zk.gs/ZK/kloak.pdf
> Does it support self-hosting...?
This was my first question too. I checked the android app, and there was no obvious configuration option for a different server.
It's open source, so at least in theory it's possible to modify it to your needs.
Also side note: Was a little disappointed to not see this on f-droid's marketplace since it is open source and hosted on github. Need to get that changed. :-)
This was my first question too. I checked the android app, and there was no obvious configuration option for a different server.
It's open source, so at least in theory it's possible to modify it to your needs.
Also side note: Was a little disappointed to not see this on f-droid's marketplace since it is open source and hosted on github. Need to get that changed. :-)
Yes!
I'm cautiously optimistic about this, but won't be using it to manage passwords for anything important -- yet.
On one hand they claim to be in league with SpiderOak (how, I'm not sure), which surfaced after the Snowden leaks as a zero-knowledge encrypted alternative to Dropbox/Google Drive.
On the other hand, it's a cloud-based solution which to me is still a cause for caution, and I'd feel more reassured if someone (who knows JavaScript and security better than I do) conducted an audit of this.
Hoping for the best for Encryptr, but I'll have to keep it on the sidelines until it's more battle-tested.
On one hand they claim to be in league with SpiderOak (how, I'm not sure), which surfaced after the Snowden leaks as a zero-knowledge encrypted alternative to Dropbox/Google Drive.
On the other hand, it's a cloud-based solution which to me is still a cause for caution, and I'd feel more reassured if someone (who knows JavaScript and security better than I do) conducted an audit of this.
Hoping for the best for Encryptr, but I'll have to keep it on the sidelines until it's more battle-tested.
I used to (as recent as a couple months back) work at SpiderOak. Encryptr is connected to SpiderOak in a couple ways. First, it's build on top of crypton (https://crypton.io/) which is a SpiderOak research project. Second, the dev (https://github.com/devgeeks) works for SpiderOak (see his github teams or https://spideroak.com/about/team-&-leadership). Encryptr was a side project of his that he started in his spare time (to mess around with crypton), though obviously SpiderOak is now interested in its success (since it's one of the first/only crypton projects live in the wild).
Some other notes: SpiderOak didn't surface after the Snowden leaks. It was around at the same time that dropbox started. However, the Snowden leaks did prompt a lot more interest in zero-knowledge cloud services, so if you mean "surface" as in "became more popular with the public" you're right on those lines.
Also, while I'm not sure if Encryptr has been audited or not, the Crypton project itself has been at least a couple of times. See https://crypton.io/docs/security/audits.html
Some other notes: SpiderOak didn't surface after the Snowden leaks. It was around at the same time that dropbox started. However, the Snowden leaks did prompt a lot more interest in zero-knowledge cloud services, so if you mean "surface" as in "became more popular with the public" you're right on those lines.
Also, while I'm not sure if Encryptr has been audited or not, the Crypton project itself has been at least a couple of times. See https://crypton.io/docs/security/audits.html
> On the other hand, it's a cloud-based solution which to me is still a cause for caution, and I'd feel more reassured if someone (who knows JavaScript and security better than I do) conducted an audit of this.
I can extend an offer to them on behalf of Paragon Initiative Enterprises and, if it's accepted, post our findings on HN at a later date.
I can extend an offer to them on behalf of Paragon Initiative Enterprises and, if it's accepted, post our findings on HN at a later date.
That'd probably help them out hugely regardless of the results. I'd be interested in reading the findings if/when they're posted.
looks like at least one of the devs works on the SpiderOak team according to github membership
The site seems to be down. Here's the repo: https://github.com/devgeeks/Encryptr
I like this for my password manager: http://www.passwordstore.org/
It's all UNIX based and takes advantage of GPG and Git for encryption and versioning, respectively. Super lightweight, and there are various front-ends for it, including an Android app.
It's not a cloud-based solution by default, but it wouldn't be hard to set it up to git push to a central location on each update and to pull from that location down to all your end-points.
It's all UNIX based and takes advantage of GPG and Git for encryption and versioning, respectively. Super lightweight, and there are various front-ends for it, including an Android app.
It's not a cloud-based solution by default, but it wouldn't be hard to set it up to git push to a central location on each update and to pull from that location down to all your end-points.
It also supports multiple identities, so passwords can have different recipients. Good if you don't want to share everything with your phone.
The best part is that the program itself is a ~500 line shell script: https://github.com/zx2c4/password-store/blob/master/src/pass...
The best part is that the program itself is a ~500 line shell script: https://github.com/zx2c4/password-store/blob/master/src/pass...
I dislike pass because it doesn't encrypt all information in the typical configuration. Its simplicity is nice.
Does Encryptr support 2FA? I don't see any mention on the landing page or on Github.
EDIT: After more digging, it looks like it does not, but may in the future. https://github.com/devgeeks/Encryptr/issues/123
EDIT: After more digging, it looks like it does not, but may in the future. https://github.com/devgeeks/Encryptr/issues/123
This looks like very nice, lightweight interface, great work! Hopefully it will get browser support as per https://github.com/devgeeks/Encryptr/issues/169
Two suggestions for the web page. First, please include the system requirements for each platform under the platform names. That would make it easier to decide whether to download the application or not.
Second, a nitpick - the OS on Mac computers is called "OS X" since the time of OS X 10.7 Lion and not "Mac OS X". Please fix that. The name "Mac OS X" was used only for older releases up to Mac OS X 10.6 Snow Leopard. :)
Second, a nitpick - the OS on Mac computers is called "OS X" since the time of OS X 10.7 Lion and not "Mac OS X". Please fix that. The name "Mac OS X" was used only for older releases up to Mac OS X 10.6 Snow Leopard. :)
This is cool, will install it right now. Shameless plug: I work in the same field but instead of storing passwords trying to replace passwords and 2fa altogether with one scheme working as a web app: truefactor.io/app
How does it work? Any info on that.
Nothing new, private keys are generated per account, the entire app will be in appcache, and sync is done via simple API and encrypted with your passphrase messages (same as crypton - zero knowledge). From the start you get 2 private keys both stored in your browser on truefactor.io/app. Later if you you decide to "2factorize" some website it can done with 1 click. To log in you need two signatures so you have to click "approve" on both devices with a private key.
The integration flow for consumer websites is also very simple: 1 tiny JS lib and 10-20 lines of code on the server side to verify 2 signatures against public keys of the user.
Out of box fixes passwords reuse, phishing, bruteforce, 2factorization, enforceable, open and free etc
The integration flow for consumer websites is also very simple: 1 tiny JS lib and 10-20 lines of code on the server side to verify 2 signatures against public keys of the user.
Out of box fixes passwords reuse, phishing, bruteforce, 2factorization, enforceable, open and free etc
The site is using a startcom certificate … how ironic.
How is StartCom as a cert provider ironic?
It is a rogue CA that does not revoke compromised certificates even when presented with a proof of such compromise, unless the customer pays a revocation fee. If the customer does not pay the fee, StartCom provides trust (which is what CAs do; they say “we guarantee to the best of our knowledge that this server is the server it claims to be”) for websites which are known (by StartCom) to be compromised, defeating the purpose of having CAs in the first place.
After Heartbleed many certificates had to be revoked, and one person who did not want to pay the revocation fee had the idea of publishing his private key so that the certificate was compromised without doubt. StartCom refused to revoke it, and the page that explained the story has since disappeared mysteriously. The HN thread about it is here: https://news.ycombinator.com/item?id=7577290
After Heartbleed many certificates had to be revoked, and one person who did not want to pay the revocation fee had the idea of publishing his private key so that the certificate was compromised without doubt. StartCom refused to revoke it, and the page that explained the story has since disappeared mysteriously. The HN thread about it is here: https://news.ycombinator.com/item?id=7577290
Yeah, I haven't been happy with them. Luckily it's just the "marketing site" that uses it, not the actual backend server.
Sorry, accidentally downvoted. Meant to upvote.
Why don't everyone use Firefox sync, it is also zero-knowledge? I am not provoking, just curious.
[deleted]
Strange that there are no iOS client.
Warning: long answer ahead. Short version: there will be very soon. I use it daily on my own iPhone.
The issue is that because Crypton does crypto with JavaScript in the web view of a Cordova app, it needs to not be stupendously slow. The default iOS web view available for Cordova apps, up until iOS 8, was the UIWebView which is well known for not having access to a JIT (like Nitro in mobile Safari). This means that JavaScript crypto (particularly done the way SJCL does it) is VERY slow. We're talking almost two minutes just to log in. :/
However, even though iOS 8 now provides a web view with a JIT (WKWebView), it has been slightly crippled by Apple. The WKWebView disallows loading local files except from the app's tmp folder. This has meant some work for the Cordova iOS team to get the WKWebView working. It is finally at a stage where it can be used, but some of the changes Cordova had to make to get it working, plus some differences in WKWebView's API, mean some changes had to be made to both Crypton and Encryptr to get it all to work.
It's working now. However, since I will still have to dance through a few more hoops of fire (Apple submission and other pain), I am planning on pushing out a new version for the existing platforms first. Then I should be able to do what needs to be done to get the iOS version out.
The issue is that because Crypton does crypto with JavaScript in the web view of a Cordova app, it needs to not be stupendously slow. The default iOS web view available for Cordova apps, up until iOS 8, was the UIWebView which is well known for not having access to a JIT (like Nitro in mobile Safari). This means that JavaScript crypto (particularly done the way SJCL does it) is VERY slow. We're talking almost two minutes just to log in. :/
However, even though iOS 8 now provides a web view with a JIT (WKWebView), it has been slightly crippled by Apple. The WKWebView disallows loading local files except from the app's tmp folder. This has meant some work for the Cordova iOS team to get the WKWebView working. It is finally at a stage where it can be used, but some of the changes Cordova had to make to get it working, plus some differences in WKWebView's API, mean some changes had to be made to both Crypton and Encryptr to get it all to work.
It's working now. However, since I will still have to dance through a few more hoops of fire (Apple submission and other pain), I am planning on pushing out a new version for the existing platforms first. Then I should be able to do what needs to be done to get the iOS version out.
Sounds great :)
If you need a beta tester please mail me (martindk at mailbox.org)
If you need a beta tester please mail me (martindk at mailbox.org)
Cloud based and private? It's not how this works.
It works if what you upload is already encrypted, which is the case here... Apparently it uses https://github.com/spideroak/crypton
"Cloud-based. Private." ... Right.
It's hard to trust a cloud-based password manager.
Now, if they're doing the crypto all local and syncing between devices with a miniature version of SpiderOak that would be OK. This is basically what 1Password does -- local crypto and stored on Dropbox or iCloud. That's not worrying at all as long as the crypto -- completely managed locally -- is strong.
But if they're using, say, SSL and an API with your credentials to access the encrypted cloud storage and they have the key... this is bad.
Now, if they're doing the crypto all local and syncing between devices with a miniature version of SpiderOak that would be OK. This is basically what 1Password does -- local crypto and stored on Dropbox or iCloud. That's not worrying at all as long as the crypto -- completely managed locally -- is strong.
But if they're using, say, SSL and an API with your credentials to access the encrypted cloud storage and they have the key... this is bad.
It encrypts locally and sends encrypted data to "the cloud".
That's a good model to adopt. It's also the "ubiquitous encryption" that has James Comey crying like a baby.
I encourage more apps and services to adopt this model. Just, be careful when you do. Definitely open source your code, and definitely get it audited by a qualified team (e.g. NCC Group's crypto services).
I encourage more apps and services to adopt this model. Just, be careful when you do. Definitely open source your code, and definitely get it audited by a qualified team (e.g. NCC Group's crypto services).
I think SpiderOak commissioned an audit of the underlying framework, Crypton... (googled) yep: https://crypton.io/docs/security/audits.html
Yep, this was mentioned above, and by Least Authority too. They do great work.
The other issue is whether your passwords would be lost if they shut down, or had some catastrophic server failure.
A planned feature is "export all data"
It's not hard to trust a cloud-based password manager -- it's insane.
I'm a bit concerned that their random number generator might produce biased output. This is usually a red flag that there are other issues in the code that haven't been examined by a crypto person.
Just a word of caution from a casual glance. For all I know the rest of the code is fine. For all I know, the rest of the code is clunky swiss cheese.
Further reading on biased RNGs, with a visual: https://stackoverflow.com/a/31374501/2224584