"It is worth noting that the affected members who update their passwords and members whose passwords have not been compromised benefit from the enhanced security we just recently put in place, which includes hashing and salting of our current password databases."
Because I'm obviously missing something: what's wrong with a hash + salt?
Depending on how it's done, wouldn't a hash of an unknown salt + password be impossible to translate back to plaintext? Even if the salt is known, as long as it changes per user, doesn't that make the look up incredibly time consuming? (Honest questions)
A salt protects you against rainbow tables of precomputed hashes of known words. It's still possible to just try all possible inputs and check the resulting hash against the list - and on GPUs it can actually be faster than reading rainbow tables from a disk.
Remember you don't need the original password, just any string that hashes to the same value. The one thing a salt does give you is that you can't crack a single passwd and then check for all other entries with the same hash = users with the same passwd.
But if you use a weak hashing function (sha-1 isn't state of the art) it may be that collisions, with different shorter keys producing the same output, are more likely than you would expect from the number of bits.
Of course you have to know the salt, but I'm suggesting something like using a different storage medium, so that one vector of attack cannot get both keys- unknown to the attacker.
That's dangerously close to "security through obscurity" - whatever process reads the passwd store has to know about and have permission to read the salt store - so just putting it in a different file or giving it a different name only buys you a false sense of security.
The reason for moving the passwords out of /etc/passwd is that there are a s lot of processes that do need to read the user list but don't need access to the passwd hash. But there is nothing to gain from splitting the salts out of /etc/shadow into a another file
Comments
From the updated blog entry:
"It is worth noting that the affected members who update their passwords and members whose passwords have not been compromised benefit from the enhanced security we just recently put in place, which includes hashing and salting of our current password databases."
Still doing it wrong I see.
Because I'm obviously missing something: what's wrong with a hash + salt?
Depending on how it's done, wouldn't a hash of an unknown salt + password be impossible to translate back to plaintext? Even if the salt is known, as long as it changes per user, doesn't that make the look up incredibly time consuming? (Honest questions)
http://news.ycombinator.com/item?id=4075873
TLDR: PBKDF2, bcrypt, and scrypt already do salting, hashing, and stretching, and better than any roll-your-own scheme.
You can't have an "unknown" salt
A salt protects you against rainbow tables of precomputed hashes of known words. It's still possible to just try all possible inputs and check the resulting hash against the list - and on GPUs it can actually be faster than reading rainbow tables from a disk.
Remember you don't need the original password, just any string that hashes to the same value. The one thing a salt does give you is that you can't crack a single passwd and then check for all other entries with the same hash = users with the same passwd.
But if you use a weak hashing function (sha-1 isn't state of the art) it may be that collisions, with different shorter keys producing the same output, are more likely than you would expect from the number of bits.
Of course you have to know the salt, but I'm suggesting something like using a different storage medium, so that one vector of attack cannot get both keys- unknown to the attacker.
I should have made that more clear.
That's dangerously close to "security through obscurity" - whatever process reads the passwd store has to know about and have permission to read the salt store - so just putting it in a different file or giving it a different name only buys you a false sense of security.
The reason for moving the passwords out of /etc/passwd is that there are a s lot of processes that do need to read the user list but don't need access to the passwd hash. But there is nothing to gain from splitting the salts out of /etc/shadow into a another file