"The information that was accessed includes usernames, passwords, physical addresses, email, hashed passwords..." They mention passwords AND hashed passwords, I wonder if this means they had some passwords saved in the clear.
And also whether "hashed" means salted and hashed or just simply hashed.
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?
> Honestly, I would feel much more comfortable if sites publicly disclosed their password encryption strategy.
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/ .
I would feel much better if passwords were just stored on a HSM (Hardware Security Module) instead of an local unix file system.
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.
Then, look at two options:
Option #1: Hashed, no Salt
Option #2: Hashed + Salt.
In Scenario #1 - your password is secure in Option #1, because your password does not appear in a rainbow table.
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.
I think we all need to accept that once we've given a password to a website it's compromised. It does not matter how they protect it - it's no longer safe. If someone has walked in to their website and taken our information, it doesn't matter which hashing scheme they've used. It's no longer important. Assume that any password you ever give out is gone. Be prepared to change your password / key on a site at any time. Mine are 26 character keys I don't know and will change as required (or leave a service that loses them).
1password for me. You can choose whatever you want though. Write them on a piece of paper you keep in your pocket if that works for you. Whatever you do, don't reuse them between services. It's just a matter of time before someone loses them and all your accounts are wide open.
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.
> And also whether "hashed" means salted and hashed or just simply hashed.
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.
They're lying or confused, the data I have is definite proof. 9gag's password and ours were hashed unsalted with MySQL's PASSWORD(). I'll reply on that comment.
