fwiw, colin disagrees.
imo, scrypt is clear overkill for storing passwords. the value of an authorization password is equal to the value of what it grants access to, and generally access to a password hash implies access to whatever the password protects. anybody who can read /etc/spasswd is already root, they can login as me just by calling setuid(). in the event of a breach, i can change my password and revoke access.
encryption keys are a little different. having access to my encrypted hard drive does not imply the ability to read its contents. and in the event of theft, i can’t simply change my password. a pbkdf needs to be more durable than a password hash.
Never heard of /etc/spasswd before, is the equivalent of /etc/shadow on most Linux/GNU systems?
Because /etc/passwd is word readable.
Yeah, shadow, whatever it is. The one with the secrets. I figured that would be more recognizable than spwd.db. oops.
The biggest problem with scrypt is parameter selection.
First, there is no effective documentation for the parameters. The draft RFC spec for scrypt has nothing to say about parameter selection, and Colin’s original paper simply says:
Users of scrypt can tune the parameters N, r, and p according to the amount
of memory and computing power available, the latency-bandwidth product of
the memory subsystem, and the amount of parallelism desired; at the current
time, taking r = 8 and p = 1 appears to yield good results, but as memory
latency and CPU parallelism increase it is likely that the optimum values for
both r and p will increase.
If you try those parameters and find them to not fit your problem (i.e., you’re not using it as a KDF for an interactive process), good luck trying to figure out what to change. If you choose poorly and it uses <1MB of memory, like the Litecoin folks did, it’s less secure than bcrypt.
It’s worth noting that Colin’s scrypt utility doesn’t expose the N/r/p parameters to end-users, but instead auto-discovers optimal parameters given space and time bounds. Given the interdependence of the parameters (i.e., increasing the memory usage also increases the CPU usage), that strikes me as the responsible choice, but that model is documented and explained only in the source of scrypt. Every other scrypt library I’ve seen just asks the end-user for the N/r/p parameters, which is catastrophic from a human factors perspective.
(BTW, shout out to the scrypt gem for Ruby and Crypt::Scrypt for Perl for doing the right thing and asking for space/time bounds.)
Been there, done that. Created a file with scrypt on one machine, then found I couldn’t decrypt it on another because the second machine didn’t have enough RAM.
He’s changed this article multiple times since he posted it (although, unfortunately, not the headline!), but in its current state it essentially says, “scrypt, at its recommended settings, is more secure than bcrypt, so you should use bcrypt.”
Previously he stated that scrypt has had less outside analysis than bcrypt, but he didn’t provide evidence for that claim and has since removed it.