Re: crypt(3) interface to scrypt

[Robert Ransom <rransom.8774@gmail.com>]

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