undefined | Better HN

0 pointsexcuse-me14y ago0 comments

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.

0 comments

2 comments · 1 top-level

MSM14y ago· 1 in thread

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.

excuse-meOP14y ago

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

j / k navigate · click thread line to collapse