48

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?

Community
  • 1
Brendan Long
  • 2,898
  • 1
  • 19
  • 27
  • 2
    are you asking, is the information in http://security.stackexchange.com/questions/211/how-to-securely-hash-passwords up to date? According to http://security.blogoverflow.com/2011/07/06/a-tour-of-password-questions-and-answers/, no reason to think it's not... – AviD Jul 25 '11 at 07: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
  • 1
    [Argon2](https://password-hashing.net/) would be the new recommendation – ptman Jan 26 '16 at 07:37

2 Answers2

54

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.

Community
  • 1
Thomas Pornin
  • 322,884
  • 58
  • 787
  • 955
  • 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 05 '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
  • 8
    `For practical usage now, I recommend bcrypt`, is this advice still applies now, in Jan 2015. Thanks – dav Jan 16 '15 at 07:12
  • In any context "new" is not synonymous with "good". You should change that to "in cryptography, 'new' is synonymous with 'bad'" – B T Apr 02 '15 at 01:59
18

It's 2016, so it's well worth revisiting this 5 year-old question. There was a Password Hashing Competition conducted from 2013 to 2016, which accepted 24 submissions and selected Argon2 as its recommended password hashing algorithm.

Everything that Thomas said about new vs. good still applies. As recently as February 2016 (after the end of the contest) Argon2 had a small change made to it (version 1.3) in order to harden it against a minor weakness. So I wouldn't automatically jump on it just yet, but it's work keeping it in the corner of one's eye, since it's likely that Argon2 will become more common in the coming years.

Luis Casillas
  • 10,361
  • 2
  • 28
  • 42