[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: crypt(3) interface to scrypt



FWIW, I mostly disagree with Robert's arguments below.  I've been through
similar discussions on several other occasions, and I don't think we need
to have one in here.  Basically, password stretching, if used right, makes
a lot of sense for website passwords.  I will be touching some of these
issues with inline Q-and-A in an article on website password security that
I wrote, to be published in May.  I may post an URL in here then.

On Thu, Apr 08, 2010 at 12:30:28PM -0700, Robert Ransom wrote:
> 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