

Smartphone password managers are largely insecure - skimbrel
http://www.elcomsoft.com/WP/BH-EU-2012-WP.pdf

======
mef
Response from Agilebits (publisher of 1Password) to this paper:
[http://blog.agilebits.com/2012/03/16/strong-security-
require...](http://blog.agilebits.com/2012/03/16/strong-security-requires-
strong-passwords/)

~~~
dorianj
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.

~~~
roustem
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.

~~~
MattRogish
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.

~~~
roustem
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.

~~~
imajes
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.

~~~
pyre

      >  i've seen almost zero iOS 3 deployment
    
      > You should feel incredibly comfortable deploying
      > as iOS 5+
    

A number seems to be missing there.

------
jsight
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.

------
mdc
Sorry to see iKeePass missing from the analysis.

~~~
skymt
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.

------
krupan
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.

~~~
dpeck
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.

~~~
skymt
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.)

------
ValG
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.

~~~
sirclueless
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.

------
acqq
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."

------
drewwwwww
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.

