From what I read, scrypt is (on paper) more secure than bcrypt, but it's pretty new so it's better to let it get time-tested and scrutinized first. However, is there any good, compelling reason to assume that it won't stand up to scrutiny?

  • Probably not weaker. Its too soon to say, and I'm definitely not one to review it, but from doing an implementation I can definitely say that you need to be intimately familiar with what your hardware can handle and what kind of traffic your site will be expected to handle during peak hours, it can eat up memory very quickly depending on your config values. Jun 23, 2014 at 20:25
  • 1
    I mean that's the general idea, if I'm not mistaken? That it's easier to parallelize CPUs than it is to parallelize memory? (thus theoretically giving scrypt an edge?)
    – user49637
    Jun 23, 2014 at 20:29
  • Yep, but as such you have to know how much memory each scrypt thread is going to consume and throttle appropriately. And buy lots of ram for your login server. :P Jun 23, 2014 at 20:31
  • bcrypt has the same general idea, e.g. compared to PBKDF2; scrypt just uses even more memory. (And makes it tunable.)
    – Ry-
    Jun 24, 2014 at 6:14

1 Answer 1


Not yet. If there were any good, compelling, reason, cryptographers would already be warning people off of using it. Internally it uses SHA-1, which has shown weaknesses for collisions, but in password storage, the concern is more preimage attacks than weaknesses, and there are no indications SHA-1 will fall to preimage attacks in the foreseeable future. Scrypt is incredibly simple in structure, I doubt that any weakness would be found in it that would not actually be a weakness in SHA-1.

  • Actually, the Catena paper outlines a cache-timing attack against scrypt. This largely negates the memory-hardness property of scrypt against a well-motivated attacker. As a result, if you ignore scrypt's memory-hardness property, bcrypt may be better in that there's a far smaller difference in its performance characteristics on CPUs (likely defender hardware) and GPUs (likely attacker hardware). Jun 23, 2014 at 23:37
  • As I understand it, that's relevant only if you're running on the same hardware as scrypt, and is not relevant to reversing/cracking the hashes from, say, a database dump.
    – David
    Jun 24, 2014 at 0:17
  • 1
    True. There are also well-known time-memory tradeoffs that an attacker can use against scrypt, negating the memory requirements. Just thought I'd mention that there are some arguments for going with bcrypt over scrypt. That said, both are excellent, and any security distinction between the two is minuscule compared to using a simple salted hash. Jun 24, 2014 at 18:13
  • Agreed completely. Also both are better than rolling your own. :)
    – David
    Jun 24, 2014 at 18:24

You must log in to answer this question.

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