<<<
NEWS FROM THE LAB - Monday, June 11, 2012
>>>
 

 
Still using the default setting on your password safe? Don't. Posted by SecResponse @ 15:52 GMT

Last week, we republished a post called: Are you sure SHA-1+salt is enough for passwords?

To continue on the topic of passwords: not only should you use a proper iteration count when implementing password hashing in code — the same thing also applies to password safe software such as KeePass.

As strong passwords are pain to remember, many people opt to use KeePass or other password managers, and then copy the password manager to one or another sync service. Passwords can then be available on all devices whether a desktop, laptop, phone or tablet. However, this brings a potential problem. The password file is more likely to end up in the wrong hands if one of the devices is compromised, stolen or the sync service is hacked.

An obvious defense for this is to use a strong password on the password database file. But strong passwords are a pain to enter on a mobile phone. And so that causes many people to use shorter passwords than is wise. A greater than 14 character password or passphrase is the proper way of doing things but we all know that most people just won't do it.

One can mitigate the problem of a short password in mobile use by adjusting key iteration count in the password manager configuration. Common wisdom is to set the iteration count so that it takes about 1 second to verify password on slowest device your are using.

For example, if you use KeePass the default key derivation iteration count is 6,000. On the typical mobile phone you can get about 200,000 iterations per second. So by setting a proper key iteration count you make password cracking ~33 times more expensive for attacker. Of course adding one character to your password gives about the same protection and adding two characters gives about 1024 times better protection. But that is no reason to leave the key iteration count to a ridiculously low default value.

Here's KeePass on a Windows laptop, set to a value of 4,279,296:

Number of key encryption rounds

And a free tip to anyone who is developing mobile password manager: the low CPU power of mobile devices seriously limit the key iteration count from proper figures, which should be around 4-6 million instead of hundreds of thousands. So how about using the phone's GPU for password derivation? Using that you could have a proper iteration count for key derivation, and you will have a more level playing ground against password crackers which use GPU acceleration.

Post by — @jarnomn