More Techniques for Password Storage

GPUs

Moore’s Law has altered the landscape in this cat-and-mouse game. The problem with using general-purpose hashing algorithms for password hashing is that general-purpose hashing algorithms are designed to be really fast. And Moore’s Law makes them faster all the time. Salting doesn’t increase the number of possibilities that need to be checked; salting only changes the set of possibilities that need to be checked from one population (all the printable passwords under, say, 10 characters) to another (that same set of passwords, each prefixed with the same prefix or salt.) This is very parallelizable and a great task for the many cores in a graphical processing unit (GPU) on a modern video card. Checking several billion passwords per second is well within reach.

Additionally, a dedicated password-cracking rig can achieve 350 billion passwords per second for Microsoft’s LM hashing algorithm.

Keep in mind that these two benchmarks describe the state of password cracking from 2013 and 2014, respectively. Cracking has only gotten faster since, due to Moore’s Law. So the defense against this is to use Moore’s Law to make defenses stronger over time. This is done with tunable password- hashing algorithms.

Tunable password-hashing algorithms can be thought of as carefully salted passwords that don’t just get hashed once. Instead, the password P is hashed to produce hash H1. Then H1 is hashed to produce H2. This is repeated tens of thousands of times. So a defender can decide how much time they’re willing to spend on password hashing at user login time. Something like a tenth of a second might be appropriate. The defender then works backward to see how many hashing iterations can fit in that amount of time. The login logic is then set up to hash that many times on each login. In approximately eighteen months, when Moore’s Law has kicked in again and made it easier to do that hashing operation, the defender can double the number of hashing iterations and maintain the level of security they had at the outset. The tunable nature of this defense is key. As time goes on, the defender can keep adjusting the number of hashing iterations to provide the desired performance/cost tradeoff.

Password storage done right

Remember how easy it was to get crypto wrong, even if you knew enough to use AES? It’s nearly as easy to get hashing wrong. And, as is always the case with developing cryptographic software, the ways in which hashing goes wrong tend not to be obvious errors that prevent themselves as bugs. They tend to show up as attacks that make researchers famous. So if you’re looking at hashing passwords, you want to use a trustworthy implementation of one of the following algorithms:

1. bcrypt
2. scrypt
3. Argon2
4. PBKDF2

All of these are solid choices. All of these use salts correctly to prevent rainbow attacks and they’re all tunably slow, so they’re resistant to brute forcing and can become more so over time by adjusting their work factors. Earlier we covered criteria to evaluate cryptographic software even though we aren’t elite cryptographers ourselves. All four of these hold up. They’re well regarded, they’ve been well studied, and they were written by people with great track records.

                                                 Q U I Z