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.