You are reading a single comment by @AlexD and its replies.
Click here to read the full conversation.
London Fixed Gear and Single-Speed is a community of predominantly fixed gear and single-speed cyclists in and around London, UK.
This site is supported almost exclusively by donations. Please consider donating a small amount regularly.
AlexD
What you need to know for this conversation is that with a hash function you can't derive the input from the output. If that were the only characteristic, modulo 10 would be a hash function. If the output is 3, you don't know if the input was 3, 13, 53 or 1003. Obviously that isn't useful for password systems as one in 10 guesses would get you a login. Actual hash functions have a rather larger number of possible outputs which are "scattered" so that knowing the result for "bed" doesn't help you guess the result for "bee".
So the basis of most password systems is the storage of the output of a hash function applied to the password.
Time was, it was enough to simply store the hash. Even if somebody stole the password database, they couldn't just work backwards to the passwords. They'd have to a) know the hash function used (although there are only a few ones in common use) and b) run all the possible character combinations through the hash function until they found a match.
Then Moore's Law kicked in and it became quite feasible to do this. Particularly if you had the whole password database, since you could crack all of the passwords in one pass. So a randomly-chosen short sequence of bytes - the salt - would be added to the password before it was hashed. The salt would be stored alongside the password - which might seem unhelpful but the aim isn't to make one password harder to crack but to make a password database much harder to crack in a single pass, since for each possible password sequence you now also have to try each possible salt.
Even today, storing passwords in plain text is surprisingly common in incompetent/careless/unprincipled businesses.