![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
It is possible that as many as 17 MILLION passwords were leaked.
A lot of the problem was that all three services, LinkedIn, Last.FM, and eHarmony, stored hashed passwords without a salt value rather than storing an encrypted password. What a hash does superficially looks like encryption, but it isn't. Let's say your password is XYZ. You plug it in to a hash algorithm and it spits out 128 bytes or more of seemingly random data. The problem is something called Rainbow Tables, and the Wikipedia entry for them is quite interesting. When hackers try to break hashed tables, they know that XYZ produces a hashed value of 123456whatever, and without a salt, it does this every time. So if they see a hashed value of 123456whatever, they know the value supplied was XYZ. The rainbow tables contain huge numbers of words passed through hash function generators, so all they have to do is match stolen/captured values against the rainbow tables and they might have usable hits.
If you use a salt value, which is a fixed or repeatable random value appended to the value being hashed, you increase the difficulty of successfully using a rainbow table to break your hashes. So instead of passing XYZ through a hash algorithm, you pass XYZ(salt value), and the salt value is probably different for every implementation because "I" as the system programmer decide on the value or the algorithm that supplies the value before it gets passed to the hasher. So maybe I do a permutation on your email address, and instead of passing XYZwayne@someemail.com, which might be predictable, I pass XYZ_COMwayneSOMEEMAIL which can be consistently duplicated algorithmically. Since 'you' will configure your web site's hasher with a different salt value, if someone steals my hash file and breaks it against a rainbow table, it won't break your hashed values.
Further, adding characters for the salt to the value being hashed greatly increases the difficulty of brute-forcing the original password, and adding a munged-up version of someone's email address will add a lot of bits of entropy.
Here's the sad part: "although eHarmony implores its users to use strong passwords including both upper and lower case letters, it saves the passwords in all upper case, thereby weakening its already weak security further." I quit the bank that I was with because they bought a new online banking system. They forced me to change my password, no problem. The system took my new password, acknowledged that I typed it correctly twice, and I was good for that session. I was then never again able to log on with that password. I'd call their tech support and they'd tell me that it had to be more than X characters long. No problem there, it was about half again longer. Well, it turns out that the password had to be between X and X+3 characters, and the password that I wanted to use was X+4 (or longer) characters. Their software wasn't smart enough to tell me that my password was too long, a combination of bad programming and stupid design, and because of that, they lost me shuffling probably over $100,000 through that account in five years.
http://www.h-online.com/security/news/item/Password-leaks-bigger-than-first-thought-1614516.html
A lot of the problem was that all three services, LinkedIn, Last.FM, and eHarmony, stored hashed passwords without a salt value rather than storing an encrypted password. What a hash does superficially looks like encryption, but it isn't. Let's say your password is XYZ. You plug it in to a hash algorithm and it spits out 128 bytes or more of seemingly random data. The problem is something called Rainbow Tables, and the Wikipedia entry for them is quite interesting. When hackers try to break hashed tables, they know that XYZ produces a hashed value of 123456whatever, and without a salt, it does this every time. So if they see a hashed value of 123456whatever, they know the value supplied was XYZ. The rainbow tables contain huge numbers of words passed through hash function generators, so all they have to do is match stolen/captured values against the rainbow tables and they might have usable hits.
If you use a salt value, which is a fixed or repeatable random value appended to the value being hashed, you increase the difficulty of successfully using a rainbow table to break your hashes. So instead of passing XYZ through a hash algorithm, you pass XYZ(salt value), and the salt value is probably different for every implementation because "I" as the system programmer decide on the value or the algorithm that supplies the value before it gets passed to the hasher. So maybe I do a permutation on your email address, and instead of passing XYZwayne@someemail.com, which might be predictable, I pass XYZ_COMwayneSOMEEMAIL which can be consistently duplicated algorithmically. Since 'you' will configure your web site's hasher with a different salt value, if someone steals my hash file and breaks it against a rainbow table, it won't break your hashed values.
Further, adding characters for the salt to the value being hashed greatly increases the difficulty of brute-forcing the original password, and adding a munged-up version of someone's email address will add a lot of bits of entropy.
Here's the sad part: "although eHarmony implores its users to use strong passwords including both upper and lower case letters, it saves the passwords in all upper case, thereby weakening its already weak security further." I quit the bank that I was with because they bought a new online banking system. They forced me to change my password, no problem. The system took my new password, acknowledged that I typed it correctly twice, and I was good for that session. I was then never again able to log on with that password. I'd call their tech support and they'd tell me that it had to be more than X characters long. No problem there, it was about half again longer. Well, it turns out that the password had to be between X and X+3 characters, and the password that I wanted to use was X+4 (or longer) characters. Their software wasn't smart enough to tell me that my password was too long, a combination of bad programming and stupid design, and because of that, they lost me shuffling probably over $100,000 through that account in five years.
http://www.h-online.com/security/news/item/Password-leaks-bigger-than-first-thought-1614516.html
