After a lot of reading the expert opinion on password hashing, I understand that scrypt (which is both memory hard and CPU intensive) is a good candidate for password hashing. But I saw the experts recommending a wait of at least 5 years until it is thoroughly peer reviewed and baked (chicken and egg problem ? :) )

  • In 2015, can we take the plunge and start using scrypt with confidence ?
  • Is there a plan to make this a standard / recommendation by NIST and other standard bodies ?

ref 1

ref 2

  • 4
    I dont see how this is a question. I doubt anyone can answer explicitly yes or no... You should rephrase this to ask a question vs start a discussion. – Matthew Peters Nov 19 '14 at 2:41
  • @Matthew Peters Do you have any suggestions ? I intend to know if it is safe / secure to use scrypt in a production environment in 2015 or should I hold off until NIST / any other standards body approves ? – acthota Nov 19 '14 at 7:02
  • Maybe something like: "What is preventing us to start using scrypt in production"? – domen Nov 19 '14 at 12:49
  • The point is to wait for the results of review, not simply to bide your time until a 5 year clock runs out. – schroeder Nov 19 '14 at 15:36
  • Also discussed in this thread. I don't think anyone's jumping at the bit to make SCrypt the standard choice for password storage. – Xander Nov 19 '14 at 18:51

If we want to look for rational reasons not to use scrypt right now, we can find mostly these three:

  • It is unclear whether a "memory-hard" function is what is needed, with the parameter configurations supported by scrypt. Scrypt was initially designed to support local encryption, particularly whole-system encryption. This means that the password must be hashed during the system bootup process; at that time, the computer has nothing else to do, so the whole CPU and RAM is available for a single scrypt; and since bootup already takes a non-negligible amount of time, a password hashing extending over 5 or 10 seconds is no hardship.

    A typical server will need a distinct configuration, that uses less RAM (a server cannot afford a gigabyte per password hashing, if it has to serve several clients and not crumble under peak load) and less CPU (a Web site authentication should be done within less than 1 second, because users are not patient; and, there again, we must account for peak load). Whether scrypt is better than bcrypt when configured for "server usage" remains to be seen; in fact, if you need to put CPU usage down to about 1 ms per hash, then scrypt uses less RAM than bcrypt, making the latter a superior option.

  • As far as memory hardness is concerned, scrypt turned out not to be as optimal as it could be. Some GPU-based optimization is still doable with time-memory trade-offs. The attacker's gain is not devastating, but if we are to change our password hashing function then we may as well try to find one that fulfils its promises.

Such issues, and other information, can be found in this presentation. To summarize: while the ideas expressed in the scrypt design are quite interesting, the general feeling of cryptographers is that there should be more research; and, indeed, it prompted the PHC: an open competition, in the spirit of past efforts such as AES, SHA-3 or eSTREAM, where new candidates are proposed and reviewed.

If you deploy scrypt right now in production, then it should be reasonably strong, although it depends on the parameters you choose. That is the main conclusion of 5 years of research: the cryptography is sound, there is a time-memory trade-off which is not damning, but we don't have a lot of guidance on how to configure it in ways that will work well in typical servers.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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