Good observations from Tao.
Let me add a few of my own.
First, I think this whole debacle is just more evidence that there is some value in core User Management code projects that can be reused when building custom sites and is focused on getting things like this right -- which is exactly the kind of thing I hope to accomplish with my
Yumps project.
I'm guessing most modern sites get the password thing mostly right. The most important thing is salting and hashing. Using a slow hash vs a cryptographic hash is important, but not nearly as much as the core concepts of salting+hashing. Only a *really* sophisticated and dedicated hacker is going to be able to employ timing info to exploit the "mistake" of using a fast cryptographic hash. In fact, I think you could argue that you are about a trillion times more likely to be attacked by someone who is trying to crash your site by hitting it with requests that slow it down than you are to be attacked by someone trying to exploit timing differences in password checks -- and so a slow password check might even hurt you there, unless you put in place an anti-hammering thing, which is actually a bit of work to get right. Furthermore, a timing attack on passwords is likely to be pretty low on the list of exploits to search for. Before you worry too much about that I would worry about network traffic interception, forcing https login, and a bunch of other stuff. If you are building a site where you think you might be so attractive that you are going to have world class hackers attempting timing attacks on your user passwords, you might want to reconsider the entire concept of allowing simple password logins, and implement additional checks with things like hardware tokens.
A meta issue, which is touched on by Tao above when we talks about costs of migration, is building in a mechanism by which you can migrate passwords to new approaches. So dont just store a password hash and salt, store extra info like: When the password was last changed, and the hashing algorithm/parameters used when it was stored. So that if you decide to move from using 5000 rounds of blowfish as your hash algorithm to 10000 rounds of sha512, you can identify which algorithm was used to store each users password, and you won't break people's logins as you migrate them (looks like some of the modern password hashing algorithms are being clever and embedding this infomation in the hashed output) to make it easier to keep track of. And have an automated system in place for forcing users to upgrade their passwords, etc.
Recent Posts