Other Software > Developer's Corner
Essays on Proper Storage of Site Passwords
TaoPhoenix:
A few point by point comments from the Brian Krebs article:
"Separate password breaches last week at LinkedIn, eHarmony and Last.fm exposed millions of credentials, and once again raised the question of whether any company can get password security right. "
Hmm, I hadn't heard of the ones at eHarmony and Last.fm. And interesting choice of phrase - "whether *any* company can get it right" (emphasis mine).
"Ptacek: The difference between a cryptographic hash and a password storage hash is that a cryptographic hash is designed to be very, very fast. ... Well, that’s the opposite of what you want with a password hash. You want a password hash to be very slow. "
Okay, so I can *almost* see a somewhat smaller "less important" site like Last.fm making this mistake. (Although even they are too big.) But LinkedIn strikes me as different. In some ways, except for a couple of annoying software features they have that lead to address book invasions, I respect LinkedIn more than any of the "recreational" social networks. LinkedIn is for a fairly high grade of professional - not that many fast food workers, etc. So I would think that would be a very demanding clientele. Wouldn't anyone at that level have wanted LinkedIn to just spend $50,000 for a month's worth of consulting to review their overall practices? The security guy Brian Krebs talked to nailed in twelve seconds. Add another $100,000 for a two-man security programming team for a year. Done (sorta).
Okay, here we go: further down:
Ptacek: At a certain point, the cost of migrating that is incredibly expensive. And securing Web applications that are as complex as LinkedIn is an incredibly hard problem."
So now we get a new question, that maybe someone *did* notice, but it got tabled as a migration cost issue. That's a whole different notion.
Edit 2:
So okay, in the NY Times article, it seems my off the cuff guess wasn't so bad after all:
"Mr. Grossman estimates that the cost of setting up proper password, Web server and application security for a company like LinkedIn would be a one-time cost of “a couple hundred thousand dollars."
mouser:
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.
db90h:
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.
-mouser (June 13, 2012, 04:11 AM)
--- End quote ---
*EXCLUDING SALTS FOR SIMPLICITY OF DISCUSSION*
As I posted elsewhere, my approach to updating my own personal database was to use double hashing. So, say I had the initial passwords stored as:
SHA1(password)
Now, to update them I could either use metadeta like you say, and update when they login, OR double hash ... That's right, hash the hash ;). The new algorithm would then become:
SHA2-512(SHA1(password))
...
or to be precise with salting,
SALT^SHA2-512(SALT^SHA1(password))
...
This is an easy way to update existing unbreached databases with new hashing algorithms, and it also increasing the computation complexity at the same time, and -- as an added benefit -- creates a 'unique' combination of algorithms that can serve to further protect you. Later, some day, if I need to increase the hash algorithm again, I can continue to add additional hash algorithms, using a third or fourth round of hashing the hash of the original password.
mouser:
it might be more flexible if you instead moved to using a prefix in the stored hash which contained the meta information.
so your original stored hash strings are: SHA1(password)
your new ones would be:
HASHVERSION_2:SHA2-512(SHA1(password))
The only change being that you would explicitly be storing some meta data that would make it easier for you to identify which users had upgraded their passwords, and make it easy to change schemes in the future.
mouser:
I will say that it's a clever and neat idea you have there of running the extra new higher security hash on the OLD_HASH rather than on the plain text, so that you could in fact upgrade the entire database any time you upgrade your hash algorithm, rather than having to wait until the person next logs in. That's clever.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version