Smartphone password managers are largely insecure(elcomsoft.com)
elcomsoft.com
Smartphone password managers are largely insecure
http://www.elcomsoft.com/WP/BH-EU-2012-WP.pdf
22 comments
Response from Agilebits (publisher of 1Password) to this paper: http://blog.agilebits.com/2012/03/16/strong-security-require...
The crux of it:
"1Password uses PBKDF2 to significantly slow down attackers. Currently this is not available on iOS as we needed to support older devices. The next major release of 1Password will only support iOS 5 and at that time we will be incorporating these additional defences"
This is absolutely unacceptable. Agilebits has long talked about how they use PBKDF2 to secure your passwords, and using anything different on mobile is an abuse of trust.
Agilebits' response is hand-waving. Of course longer passwords are more secure. If we all used 32-character passwords, we wouldn't even need key derivation.
But we expect to use reasonably simple (7-10) character passwords because it's possible to make these secure against cold attacks using math. And when the software you use has in the past described the algorithms it uses, you expect all versions of the software to work in the same manner.
I've long used 1password, and I don't plan to stop using it yet, but this is a serious breach of trust, and I feel less secure in using it now.
This is absolutely unacceptable. Agilebits has long talked about how they use PBKDF2 to secure your passwords, and using anything different on mobile is an abuse of trust.
Agilebits' response is hand-waving. Of course longer passwords are more secure. If we all used 32-character passwords, we wouldn't even need key derivation.
But we expect to use reasonably simple (7-10) character passwords because it's possible to make these secure against cold attacks using math. And when the software you use has in the past described the algorithms it uses, you expect all versions of the software to work in the same manner.
I've long used 1password, and I don't plan to stop using it yet, but this is a serious breach of trust, and I feel less secure in using it now.
I agree.
I am going to add the PBKDF2 strengthening and fix the problem with the PKCS#7 padding mentioned in the article. We plan to submit the 1Password update by the end of March.
The support iOS 3 and the old devices really hurt us there as the performance gap between iPhone 3 and iPhone 4S is huge and so far we were targeting the lowest common denominator. I am still not sure what to do about the older iPhones. We'll probably try to adjust the number of PBKDF2 iterations based on the device. Unfortunately, the PBKDF2 calibration API is only available on iOS 5.
I am going to add the PBKDF2 strengthening and fix the problem with the PKCS#7 padding mentioned in the article. We plan to submit the 1Password update by the end of March.
The support iOS 3 and the old devices really hurt us there as the performance gap between iPhone 3 and iPhone 4S is huge and so far we were targeting the lowest common denominator. I am still not sure what to do about the older iPhones. We'll probably try to adjust the number of PBKDF2 iterations based on the device. Unfortunately, the PBKDF2 calibration API is only available on iOS 5.
Hardly anyone runs on iOS3 and/or iPhone3 - do you have data showing this market segment is large?
Weakening security for such a tiny market segment - I can't imagine that's worth it.
Weakening security for such a tiny market segment - I can't imagine that's worth it.
We don't collect any usage information.
About 18 months ago I removed support for iOS 3 and we got a huge pushback from existing users. I spent another month adding back iOS 3 support. I am sure things must be different now.
About 18 months ago I removed support for iOS 3 and we got a huge pushback from existing users. I spent another month adding back iOS 3 support. I am sure things must be different now.
in other products which are very very non-tech consumer focused, i've seen almost zero iOS 3 deployment. You should feel incredibly comfortable deploying as iOS 5+ only at this point.
> i've seen almost zero iOS 3 deployment
> You should feel incredibly comfortable deploying
> as iOS 5+
[deleted]
People most definitely still use older phones. I use my iPhone 3G when I travel overseas because there's an easy unlock available for it (unlike the baseband on my current model). And password manager is one of the things I really want to work across all my devices. Actually, if I can't share 1password database between old and new phones, I'll probably be looking for a different password manager. Having said that, I obviously don't expect it to perform fast on older hardware.
Thank you for being forthright and responsive.
I think the better thing to do for older devices would have been to make it a user-settable option, with a note on first install. I would have preferred to have a 5 or even 10 second delay in opening my 1password keychain, rather than have it less secure. But it's a moot point now--as others noted, the older devices are quickly falling out of favor (at least among those savvy enough to use something like 1password).
I think the better thing to do for older devices would have been to make it a user-settable option, with a note on first install. I would have preferred to have a 5 or even 10 second delay in opening my 1password keychain, rather than have it less secure. But it's a moot point now--as others noted, the older devices are quickly falling out of favor (at least among those savvy enough to use something like 1password).
Wow, some of these are amazingly insecure. It's really incredible that at least one of the developers of a paid security app stores the master-password encrypted (not-hashed) using a hardcoded private key.
Sorry to see iKeePass missing from the analysis.
I was curious about KeePass as well, so I downloaded the source. I haven't done anything resembling a source audit, so I can't speak to implementation flaws, but the design seems solid (to my admittedly amateur eyes).
KeePass databases are AES-encrypted with a 256-bit key. The key is generated from your passphrase with a user-configurable number of bcrypt rounds, followed by a single SHA-256 round, to reduce it to the 256 bits needed by AES.
KeePass databases are AES-encrypted with a 256-bit key. The key is generated from your passphrase with a user-configurable number of bcrypt rounds, followed by a single SHA-256 round, to reduce it to the 256 bits needed by AES.
KeePass is the only one I really wanted to see...
Indeed.. as well as KeePass for Blackberry.
In short, protect your device from physical access by untrusted people, and don't connect it to untrusted machines. Use a PIN or device password just in case someone else does get ahold of your device.
Don't connect to untrusted machines? As in, never connect to anything? What the point in having a smart phone then? (debatable why anyone needs one, I'm personally considering going to a dumb prepaid for cost/lack of need reasons)
I appreciate the paranoia, but it doesn't scale for normal users. With every page the users browses/app they install/etc there is a chance of the device executing code that's going to do something naughty. Operating under that assumption, one would hope that things like password managers would mitigate some of the long term effects of that, but as we see from this report that is not typically the case.
I appreciate the paranoia, but it doesn't scale for normal users. With every page the users browses/app they install/etc there is a chance of the device executing code that's going to do something naughty. Operating under that assumption, one would hope that things like password managers would mitigate some of the long term effects of that, but as we see from this report that is not typically the case.
I assume krupan meant never physically connect a smartphone to an untrusted PC. (That's one of the two methods for obtaining an encrypted password database described in the paper.)
One Ring to Rule Them All... but seriously, interesting article; I think more interesting is the phone log-in password that all smart phones now have. I just read an article where the DOJ subpenaed Google to unlock an Android based phone because after several weeks of working on the log-in, they still couldn't get in. If you think about it, Password management software for your phone is really protected by 2 systems, the one native to your phone and the apps own security systems. Although, yes, some of these apps are essentially bunk.
That's not as important as you make it seem. They can crack the two independently, so it is at most a factor of 2 increase in security over just the stronger method.
Conclusion from the article:
"Many password management apps offered on the market do not provide adequate level of security. We strongly encourage users not to rely on their protections but rather use iOS or BlackBerry security features.
For Apple users: set up a passcode, and a (complex!) backup password. Do not plug the unlocked device to computers you do not trust to prevent creation of pairing. If you can't encrypt backup for some reason, restrict access to it as much as possible."
"Many password management apps offered on the market do not provide adequate level of security. We strongly encourage users not to rely on their protections but rather use iOS or BlackBerry security features.
For Apple users: set up a passcode, and a (complex!) backup password. Do not plug the unlocked device to computers you do not trust to prevent creation of pairing. If you can't encrypt backup for some reason, restrict access to it as much as possible."
does anybody know how the cpu and gpu rates are derived in the summary table?
i'd like to know how parallelized the computation is assumed to be.
i'd like to know how parallelized the computation is assumed to be.