Possible Duplicate:
Do any security experts recommend bcrypt for password storage?
I'm no security expert and do not pretend to be that's why I'm asking here. I write many PHP based applications and up to now I have been using bcrypt to hash my passwords.
The scrypt website claims to be 4000 times slower than bcrypt, can this claim really be correct? If so would it be 'better' for a safety conscious developer to switch over to use scrypt instead of bcrypt?
Scrypt is supposed to be "better" than bcrypt, but is is also much more recent, and that's bad (because "more recent" inherently implies "has received less scrutiny").
All these password hashing schemes try to make processing of a single password more expensive for the attacker, while not making it too expensive for your server. Since your server is, basically, a PC, and the attacker can choose the most efficient hardware for his task, password hashing schemes try to be such that the best platform for them will be a PC. PBKDF2 can be thoroughly optimized with GPU, while bcrypt and scrypt are much less GPU-friendly. Bcrypt and scrypt both require fast RAM, which is a scarce resource in a GPU (a GPU can have a lot of RAM, but will not be able to access it from all cores simultaneously).
It so happens that modern FPGA embed many small RAM blocks which are very handy to optimize a parallel dictionary attack with bcrypt: this means that an attacker will get a huge boost by using 1000$ worth of FPGA instead of 1000$ worth of generic PC. This is the kind of boost that we want to avoid. Hence scrypt, which requires a lot more RAM; not too much for a PC (we are only talking about a couple megabytes here), but enough to make life hard for a FPGA (see this answer for a detailed treatment of the question).
Thus, theoretically, scrypt should be better than bcrypt. However, this is all subject to whether scrypt lives up to its cryptographic promises. This kind of guarantee of robustness can only be achieved through time: the scheme will be deemed secure if it survives years of relentless assaults from cryptographers. How much time is needed, is of course a bit subjective, and also depends a lot on exposure (the more widely deployed a scheme is, the more "interesting" a target it becomes, in that breaking it would increase the academic fame of the perpetrator; thus attracting more scrutiny). My own rule of thumb is to wait for about 5 years after publication, thus 2014 in the case of scrypt.
There is also the question of availability: if you want to use a function, then you need an implementation which can be inserted in the programming framework you use.
I would take the "Scrypt is 4000 times slower than BCrypt" assertion with a grain of salt. First, both of these algorithms are variably-complex; even if that "4000x" figure holds, you can make BCrypt just as slow by adding an additional 11 rounds to the key derivation. Second, at some point both SCrypt and BCrypt are limited by how long it takes to legitimately compute one hash on the average user's computer (or on your server if you're doing it server-side for a web app). SCrypt being 4000x slower may well increase your website's bounce rate by more than the increased security.
Reasons to choose BCrypt:
BCrypt is 14 years old, based on a cipher that's over 20 years old, and neither have been shown to have any feasible theoretical weakness (there is a known-plaintext vulnerability in Blowfish which doesn't affect BCrypt in the slightest, but there is a bug in one UNIX implementation of BCrypt could cause application failures if it were fed certain character codes).
SCrypt is only 3-4 years old, so it doesn't have the cryptanalytic pedigree required to gain most cryptographers' trust. That doesn't mean it's vulnerable; it means mopst security experts aren't confident enough that it isn't vulnerable yet.
There's really only one reason to choose SCrypt over BCrypt and it's the reason that SCrypt was designed: BCrypt's main weakness against a distributed cracking system is low, constant memory usage. This makes BCrypt vulnerable to cost-effective brute-forcing using relatively inexpensive Field-Programmable Gate Arrays or FPGAs. These arrays have a relatively small amount of SRAM built in to their logic blocks, which is still enough to hold BCrypt's state data. As Thomas said, these arrays are cheaper to buy and set up than a distributed network of traditional CPU- or GPU-based crackbots, so equivalently, your attacker gets more for his money.
SCrypt, by contrast, uses not only exponential time, but exponential memory; as the number of rounds of derivation increase, SCrypt requires the storage of a series of intermediate state data "snapshots", which are used in further derivation operations. That's no problem to a legitimate user's computer generating one hash (you're probably using a few MB at most), but an FPGA block's limited memory quickly becomes insufficient. Now, anything you could store, you could calculate "on-demand" instead, but because each of these intermediate states is the result of its own exponentially-complex series of operations (each of which is lesser-complexity than the final hash, but must be calculated more times for on-demand use), the attacker is now on the horns of a dilemma; they either need exponentially more FPGAs to keep up with the increased computational time of the on-demand model, or they need to upgrade the FPGAs to something with sufficient memory to do the job (basically you're considering simple high-clock CPU/FSB/RAM architectures at this point, which is what's behind the multi-million-dollar petaflop distributed clusters). Either way, FPGAs are no longer as feasible as they are for BCrypt (or PBKDF2).
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
Per https://stackoverflow.com/questions/1226513/whats-the-advantage-of-scrypt-over-bcrypt
