57

I'm looking at ways to securely store passwords. Some people claim that scrypt is "better" than bcrypt, and so far I've seen nobody who claims vice versa or that scrypt is insecure, though some call bcrypt "more reputable".

What's the advantage of scrypt over bcrypt? According to the scrypt website, "the cost of a hardware brute-force attack against scrypt is roughly 4000 times greater than the cost of a similar attack against bcrypt". If that's the only advantage then can't I just use bcrypt with a larger number of rounds?

Blekk
  • 156
  • 1
  • 2
  • 9
Hongli
  • 18,682
  • 15
  • 79
  • 107
  • 1
    Recommended reading on this topic: [Do any security experts recommend bcrypt for password storage](http://security.stackexchange.com/questions/4781/do-any-security-experts-recommend-bcrypt-for-password-storage) (on [security.se]) – Gilles 'SO- stop being evil' Jun 07 '13 at 18:46
  • 1
    Bcrypt requires 4k of memory to perform it's computations. A video card with 8 GB of RAM could have 2M bcrypts running in parallel. That is why scrypt has a configurable memory requirement. If you required it to use 128 MB of memory, you could only get 64 of them running in parallel in an 8GB video card. Large memory requirement is also done because video cards are very slow in reading-writing memory randomly. Another virtue of scrypt is a) it is basically a glorified PBKDF2 - so auditors will be happy b) it also can be used as a key derivation function (not just password storage) – Ian Boyd Aug 04 '18 at 17:44
  • 1
    Scrypt was designed to read and write randomly to a lot of memory. This kills the advantage ASICs have, and it makes parallelization prohibitive. Colin Percival uses PBKDF2 to do the hashing, but he basically uses an *"expensive"* way to generate salt. So the algorithm is at least as strong as PBKDF2. He used Salsa20 stream cipher as a way to hash the memory and write it back to the memory repeatedly. He did this without any formal design idea; just that i randomly reads and writes to RAM. – Ian Boyd Aug 04 '18 at 17:50
  • 1
    The `argon2` folks take the same idea as scrypt (we want to read/write to a large block of memory to thwart ASICs and video cards). But they started with the understanding that they want to give CPU users every possible advantage. Their hashing algorithm uses the fastest software-only hashing algorithm known - using only op-codes that are fast on a CPU. They don't use anything that could give an ASIC an advantage. They realized that they want to read-write to RAM **at** memory bandwidth, where PCs shine and GPUs suck. That's why it uses Blake2b hashing, the fastest software-only hashing known. – Ian Boyd Aug 04 '18 at 17:54
  • 1
    SHA3 is faster than Blake2b in custom hardware, but we're not trying to make it faster for custom hardware - we're trying to make it fastest on a CPU. – Ian Boyd Aug 04 '18 at 17:55

1 Answers1

63

With scrypt in addition to increasing computation you can increase the amount of memory needed to compute the hash. This doesn't bother software implementations much but is much harder to implement with hardware - which is what a dedicated attacker is likely to develop and use.

bcrypt (and PBKDF2) use constant, and small, amounts of memory.

orip
  • 73,323
  • 21
  • 116
  • 148
  • 2
    Interesting article about [BCrypt vs SCrypt](http://www.unlimitednovelty.com/2012/03/dont-use-bcrypt.html) – deamon Nov 09 '12 at 15:12