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. – Andrew Hoffman Jun 23 '14 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 '14 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 – Andrew Hoffman Jun 23 '14 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 '14 at 6:14

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). – Stephen Touset Jun 23 '14 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 '14 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. – Stephen Touset Jun 24 '14 at 18:13
  • Agreed completely. Also both are better than rolling your own. :) – David Jun 24 '14 at 18:24

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.