[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Thu, 12 May 2011 15:21:06 +0400
From: Solar Designer <solar@...nwall.com>
To: crypt-dev@...ts.openwall.com
Subject: using scrypt for user authentication
David, Yuri, Colin -
The primary advantage of scrypt is in increased cost of a hardware-based
offline attack, due to scrypt's use of large amounts of RAM.
This works well in the scrypt file encryption program, which can
allocate tens or hundreds of megabytes of memory.
However, if we try to define a crypt(3) function based on scrypt, we
have to consider that there may be a large number of authentication
requests made simultaneously. We don't want the server to run out of
RAM (nor to take too much RAM away from other tasks).
I can think of several options:
1. Use such settings that scrypt doesn't use more than, say, 1 MB of
memory. Is 1 MB way too low? Is scrypt at this setting significantly
better than bcrypt or not?
2. Use locking - allow at most N calls into scrypt to proceed
simultaneously, with the rest having to wait.
2a. This may have to be something like a SysV semaphore, in order for it
to work for typical Unix services that fork separate child processes
(rather than use threads).
2b. Use shared memory for scrypt (expanding it for up to N instances as
needed, then shrinking back), also with due locking.
2c. crypt(3) may talk to a service process (perhaps over a Unix domain
socket), which will actually impose the max N limit (and will have the
scrypt code in it and will allocate/free the memory as needed).
Finally, we could choose not to hook crypt(3) at all. Instead, have a
custom PAM module, to be used instead of pam_unix (or the like). But
that does not make much of a difference for the problem defined above.
In many cases, we'll need decent password hashing other than for OS
passwords - e.g., for web app passwords. The interfaces to provide
could then be different, but the problem is similar.
I don't particularly like any of the solutions/workarounds I proposed;
if anyone has another idea, please speak up.
Thanks,
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
