I've always heard that scrypt was better than bcrpyt... because of memory causing GPU a very difficult time to crack. However, the notion always was that scrypt hadn't been tested, it was kind of a new crypt method, and that I should wait it to be tested before using it.

Has that time come where people have made scrypt the new standard to use? or is it still in beta phase?

  • One issue with scrypt is that it has data dependent RAM access, which can lead to side-channel attacks in some scenarios. Not sure how realistic those scenarios are, and if the attack can be mitigated by randomizing memory access. Commented Sep 26, 2013 at 16:24
  • I'm not sure time has tested scrypt much. I think there aren't many cryptographers who tried to break it. Commented Sep 27, 2013 at 8:11

3 Answers 3


Scrypt has mostly survived. It is not bad; it just turns out that the touted advantages of scrypt over the competition (mainly bcrypt and PBKDF2) might not be as marvellous as first claimed. As always, it is a trade-off: like any password hashing function, its role is to make password hashing expensive for everybody, attackers and defenders alike. Scrypt uses a lot of RAM in order to force the attacker to use the same hardware as the defender (a PC). The bad point, though, is that it uses a lot of RAM.

See this presentation for some information on the present of password hashing. An open competition is being run, to obtain, publish and analyse new and hopefully better functions (currently in the phase of gathering candidates).

  • 6
    Everyone paying close attention to the Password Hashing Competition expects that Colin Percival will be submitting a revision of scrypt. Commented Sep 26, 2013 at 5:16
  • 1
    IMO one big practical problem with scrypt is that it doesn't use enough RAM under the time constraints on a typical server. Commented Sep 27, 2013 at 8:10

A fair bit of the inherent safety in scrypt is that it doesn't make any specific promises but is already effectively guaranteed to be at least as good as the existing alternatives.

So in the worst-case scenario, scrypt is only as good as existing iterative hash composition techniques. Since scrypt is, itself, an iterative composition technique, and since existing techniques are relatively naïve, it's difficult to imagine how scrypt could possibly be less secure than the alternative. Its safety in this sense is based on the fact that it's using well-established hashes in their recommended configuration.

In the best-case scenario, scrypt will also increase the price of any hardware you'd use for brute-forcing password hashes. By how much? No guarantee. The design goal is that hash-cracking devices will have to have a significant amount of dedicated RAM, which is the simplest way to either dramatically increase the amount of chip dye space that would have to go in to such a device, or dramatically limit the speed of the device, since memory is either very slow or very expensive.

But there's no metric for success, no specific attack to defend against. There's just a general "it probably makes the hardware more expensive" claim that is hardly a claim at all.

The primary downside, of course, is that it probably makes the hardware more expensive. Your hardware, this time. The design goal is to increase the cost of hashing, which means your computer will have to either cost more or perform worse that an equivalent setup with other hash strategies. If you don't understand what scrypt is for, then this can be a real problem.

  • I've been using scrypt for a couple of years based on this logic. Commented Sep 26, 2013 at 16:10
  • Does the "hardware is more expensive" really matter if you're not operating at a large scale? What if I only expect a maximum of one log in every 10 minutes?
    – jpmc26
    Commented Jun 2, 2017 at 19:38

With Thomas Pornin's most excellent answer in mind, one interim option is to use a mechanism that will thwart today's GPU-based cracking systems, but with the expectation of migrating to the results of the password hashing competition once those become available.

For example, using PBKDF2-HMAC-SHA512 will prevent cracking on today's GPUs by virtue of using SHA512. But this kind of measure should be seen only as a temporary approach. It is not a long term solution.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .