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.
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.
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.
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)
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.
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?
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.
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. :-)
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.
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.
> 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.
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.
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. :)
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
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.
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.
[+] [-] sarciszewski|10 years ago|reply
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
[+] [-] tptacek|10 years ago|reply
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.
[+] [-] shuzchen|10 years ago|reply
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)
[+] [-] pbsd|10 years ago|reply
[+] [-] daviddahl|10 years ago|reply
[+] [-] homakov|10 years ago|reply
[+] [-] lucasgonze|10 years ago|reply
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.
[+] [-] devgeeks|10 years ago|reply
[+] [-] daviddahl|10 years ago|reply
http://monosnap.com/image/npl8jAtBNPAHUJAws8x4p3s3iAw36S#
I already have it (as I am a contributor). Its just getting better
[+] [-] hermanmerman|10 years ago|reply
Side question: does it support sharing of secured notes and credentials? even to non-encryptr users?
[+] [-] vetrom|10 years ago|reply
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.
[+] [-] neoCrimeLabs|10 years ago|reply
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. :-)
[+] [-] verandaguy|10 years ago|reply
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.
[+] [-] shuzchen|10 years ago|reply
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
[+] [-] sarciszewski|10 years ago|reply
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.
[+] [-] feld|10 years ago|reply
[+] [-] egeozcan|10 years ago|reply
[+] [-] dbmikus|10 years ago|reply
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.
[+] [-] ymse|10 years ago|reply
The best part is that the program itself is a ~500 line shell script: https://github.com/zx2c4/password-store/blob/master/src/pass...
[+] [-] cmrx64|10 years ago|reply
[+] [-] bitskits|10 years ago|reply
EDIT: After more digging, it looks like it does not, but may in the future. https://github.com/devgeeks/Encryptr/issues/123
[+] [-] vanous|10 years ago|reply
[+] [-] newscracker|10 years ago|reply
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. :)
[+] [-] homakov|10 years ago|reply
[+] [-] tmd83|10 years ago|reply
[+] [-] Ruud-v-A|10 years ago|reply
[+] [-] vetrom|10 years ago|reply
[+] [-] wjyagainyc|10 years ago|reply
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] msh|10 years ago|reply
[+] [-] devgeeks|10 years ago|reply
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.
[+] [-] systemz|10 years ago|reply
[+] [-] joeyspn|10 years ago|reply
[+] [-] Nux|10 years ago|reply
[+] [-] feld|10 years ago|reply
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.