Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

This question made me start thinking about password hashing again. I currently use bcrypt (specifically py-bcrypt). I've heard a lot about PBKDF2, and scrypt.

What I'm wondering is if there are any "more modern" password hashing methods that I might not know about (because they're new, so people don't talk about them as much), or maybe other methods I don't know about.

And then going on from there, which one should I use? Most people seem to recommend bcrypt, but I wonder if that's just because it's old (read: well-known). scrypt seems better (variable amount of memory usage). I don't know much about PBKDF2.

So if I was making a user-management scheme, which of these should I use? Or should I use something completely different?

share|improve this question
2  
are you asking, is the information in security.stackexchange.com/questions/211/… up to date? According to security.blogoverflow.com/2011/07/06/…, no reason to think it's not... –  AviD Jul 25 '11 at 7:31
1  
@AviD: I'm more wondering if there's anything beyond the canned response to that question ("Use bcrypt, scrypt or PBKDF2"). I already know that bcrypt is the general recommendation; what I wonder is if there's anything else that people tend to leave off, maybe because it's just not as well known. Thomas Pornin's answer leads me to believe that "well known" is a property of good password hashing schemes though, so maybe this will be less interesting than I was hoping. –  Brendan Long Jul 25 '11 at 15:51
    
Right, dont forget Kerkchoffs' Law.... Secrets in cryptography algorithms are bad, and the same goes for the algorithm itself. –  AviD Jul 25 '11 at 17:53
add comment

1 Answer

up vote 33 down vote accepted

In cryptography, "new" is not synonymous to "good". That bcrypt is twelve years old (12 years... is that really "old" ?) just means that it sustained 12 years of public exposure and wide usage without being broken, so it must be quite robust. By definition, a "newer" method cannot boast as much. As a cryptographer, I would say that 12 years old is just about the right age, and anything younger than, say, 5 years, is definitely "too young" for general deployment (of course, these estimates depend on how much exposure the algorithm got; an early, wide deployment, although risky for those who decide to deploy, will go a long way toward building confidence in security -- or revealing weaknesses at an early stage).

Scrypt is much newer than bcrypt; it dates from 2009. The idea is quite smart. Namely, slow password processing is meant to make dictionary attacks N times more expensive for the attacker, while implying that normal processing is N' times more expensive for the honest systems. Ideally, N = N'; the scrypt author argues that with PBKDF2 or bcrypt, use of ASIC allow an attacker to get a N much lower than N' (in other words, the attacker can use specialized hardware, because he is interested only in breaking a password, and thus hashes many more passwords per second and per spent dollar than the honest system). To fix that, scrypt relies on an algorithm which requires quite some RAM, since fast access RAM is the specialty of the PC, and a sore point of ASIC design. To which extent scrypt is successful in that area remains to be measured; 2009 is recent times, and the figures given by the scrypt author are based on 130 nm ASIC technology and an hypothesis of "5 seconds worth of processing", which is quite beyond what the average user is ready to wait.

For practical usage now, I recommend bcrypt.

Scrypt notwithstanding, current research on the concept of password processing is more about specialized transforms that allow more than mere password verification. For instance, the SRP protocol allows for a cryptographic key agreement with mutual password-based authentication, and resilient to dictionary attacks (even in the case of an attacker actively impersonating the client or the server); this calls for a bit of mathematical structure, and the password-hashing in SRP involves modular exponentiation.

share|improve this answer
2  
+1, great post. There is one point that you are missing. scrypt uses a variable amount of cpu and memory. There for when the next generation of GPU's come out with larger registers, you can increase the memory requirements. Or even have these resource consumption values calculated as a function of time. –  Rook Apr 5 '12 at 17:39
    
@Rook - To add even more detail, scrypt requires either variably exponential memory and exponential time, or constant memory and variably exponentially more time. Basically, you can crack N rounds of an H-bit scrypt hash function in 2^(N+H) time and (2^N)H memory, or in something like 2^(N+NH) time and constant memory. Your choice, but that choice is a Morton's Fork for FPGA crackers, even with relatively small hash sizes. –  KeithS Dec 21 '12 at 19:50
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.