Re: crypt(3) interface to scrypt

[Royce Williams <royce@alaska.net>]

Robert Ransom wrote, on 4/8/2010 11:30 AM:
> On Thu, 08 Apr 2010 08:31:39 -0800
> Royce Williams <royce@alaska.net> wrote:
> 
>> Robert Ransom wrote, on 4/8/2010 8:13 AM:
>>> scrypt is a bad idea for website passwords -- tying up a web server's
>>> CPU for 0.5 seconds just to check a password is silly, and it is
>>> unlikely to add any security.  (After all, the user just typed the
>>> password into a browser...)  A web browser could use scrypt to protect
>>> an SSL secret key, but that is entirely a client-side decision.
>> Really?  I'm a sysadmin/practitioner, not a developer ... but my
>> inclination was to move to scrypt for any password storage that I can
>> control, based on the following:
>>
>> * scrypt's parameters can be adjusted to find an acceptable turnaround
>> time for a given use.
> 
> From scrypt-1.1.6/lib/scryptenc/scryptenc.c:
> 	/* Allow a minimum of 2^15 salsa20/8 cores. */
> 	if (opslimit < 32768)
> 		opslimit = 32768;
> 
> There may be other minimum difficulty parameters in Dr. Percival's
> source; if these minima are removed or lowered further, I don't think
> scrypt can be made worse than PBKDF2 (which it uses to preprocess the
> password), but using scrypt with low difficulty parameters is not much
> better than using PBKDF2.
> 
>> * This may be naive of me, but if the web server and application are
>> (ideally) set up to keep the password safe from prying eyes while in
>> flight and in use, then isn't the weak link in the chain its storage?
> 
> If your users send unhashed passwords to your server, I assume that any
> competent attacker who can retrieve hashed passwords from your server
> can also modify your server software to steal unhashed passwords for
> him, and that when (and if) you discover the attack, you will be unable
> to prove that any particular unhashed password has not been stolen.
> This is a rather pessimistic assumption, but I consider it reasonable.
> 
> If you are only worried about attackers who are not competent enough to
> backdoor your server software, keep in mind that the easiest attack to
> mount is a DoS, and using scrypt for password hashing on a web server
> makes DoS attacks very easy indeed.  In this case, using scrypt only
> reduces your server's security.
> 
>> * Since users often use the same password multiple places, keeping any
>> password as secure as possible is better for the Internet ecosystem as a
>> whole.
> 
> If a person uses the same password for multiple web sites, there is no
> point in your server using a more time-consuming password hash function
> than Google, Amazon, or the user's bank.
> 
> 
> 
> But all of the above is a little silly -- if an attacker obtains a
> password used to access a web site, the user can change his password,
> and the old one instantly becomes useless.  scrypt was designed for
> password-based encryption of data which *must not* be disclosed, even
> to an absurdly well-funded attacker.  (e.g. long-term signature secret
> keys, plans for world domination, secret recipes, ...)
> 
> Robert Ransom

Good explanations, all.  Thanks for handing me some clue fodder.

The only thing that I would add is that websites can also be relatively
fleeting, but backups that contain passwords can live forever.  That
exposure can exist long after the server is dead and gone.

Heh. To be efficient, I've signed my plans for world domination (which
involve a secret recipe). :-)

Royce