Honestly, I would feel much more comfortable if sites publicly disclosed their password encryption strategy. Just saying "oh they're hashed" really doesn't make me feel any better -- how do I know they didn't just do a quick MD5 instead of a proper password-appropriate process?
Funny you should mention that.
I thought at one point that I could set up a http://tosdr.org/ like database, showcasing the best password securities in use. You could have lists of the people using MD5, scrypt, bcrypt, and so forth. Think of it as a trophy case of password storage algorithms. My sticking point was finding the information, aside from looking at already leaked databases, you just have to go and ask the developers.
I emailed about 35 companies with a standard block of text asking if they were willing to disclose their scheme, the responses were mostly in the following:
• "our passwords are encrypted, you don't need to worry"
• "we can't disclose this for security reasons"
• "you're trying to hack us!"
I don't know what I expected really. We will have to stick to laughing at the atrocities listed on on http://plaintextoffenders.com/ .
This sounds like the beginning of a pretty good blog.
And, from a security perspective, it's mostly irrelevant as to whether passwords were hashed (where hash = MD5, SHA, or some other high speed hash function), or salted+hashed.
Why:
Look at two scenarios,
Scenario #1: The security of your Strong, high-entropy password.
Scenario #2: The security of all the n00b's weak passwords.
Option #1: Hashed, no Salt
Option #2: Hashed + Salt.
In Scenario #2 - the vast majority (60%+) of those weak passwords can be brute forced with sophisticated dictionary attacks in a couple days even with a hash+salt - no need to use rainbow tables.
Ironically, Salt's offer no security for you (you don't need them), or the vast majority of people (whose password will be broken, even if they are salted+hashed). Salts+Hash were relevant from 1990-2010, prior to high speed GPUs and ASICs overtaking Rainbow Tables. People learned lessons then, that are no longer relevant.
Now, where Salts ARE important, is with a multi-iteration key-derivative function like bcrypt or scrypt. There, a salt (which is part of the bcrypt and scrypt algorithm) actually does offer (a lot) of security to the n00bs. Without salts scrypt/bcrypt would once again tip the balance back in favor of Rainbow Tables. But, of course, scrypt/bcrypt are inherently salted.
But your high-entropy password is safe regardless.
As always, http://codahale.com/how-to-safely-store-a-password/
In an ideal world we wouldn't use passwords anymore. But right now we have no choice so we have to do whatever we can to mitigate our eventual compromised accounts.
That really doesn't make that much of a difference anymore, given the fact that it's known information that's easily parseable. Rainbow tables are really just a quick convenience, but it's not like there aren't programs that can automate the process of getting and appending the salt to a password string and then just brute forcing. Even with something like bcrypt, you're still working against 1) infinite time and 2) users who don't understand how dangerous a weak password is.
http://www.name.com/blog/general/2013/05/we-got-hacked/#comm...