Multiple values can lead to one hash, so if you hash a password, no one could get the password back from that hash. It prevents you as the owner of a system from knowing which password a user has chosen.
Adding some string to the password, called a salt, before hashing it, makes the hash different again, but this time different from all the other sites where the user used the same password.
So if some malicious person aquired a bunch of password hashes from you they couldn't use them on other sites.
If you use a different salt for every password, you would make the hashes different for every user that used the same password, even on your own site.
Basic example here would be, someone signs up to your service and uses a password for this. Then they somehow steal your hashes. Now they look for their own account and what hash they have and check if someone has the same hash. Then they log in to that other persons account.
If all passwords were salted with their own salt, even the same passwords would have a different hash.
If passwords are always hashed (and salted differently each time), how are you able to produce the same hash to authenticate a user when they're logging into the system?
Is there something that keeps a track of these things?
Rember the main reason of having salt is to prevent the hacker from using the rainbow tables. So it’s totally fine to store them as plan text in the db. Because the hacker will have to generate a whole new rainbow table for each password to be able to check againet them. Which is near impossible with current cpu capabilities.
Multiple values can lead to one hash, so if you hash a password, no one could get the password back from that hash. It prevents you as the owner of a system from knowing which password a user has chosen.
Adding some string to the password, called a salt, before hashing it, makes the hash different again, but this time different from all the other sites where the user used the same password.
So if some malicious person aquired a bunch of password hashes from you they couldn't use them on other sites.
If you use a different salt for every password, you would make the hashes different for every user that used the same password, even on your own site.
Basic example here would be, someone signs up to your service and uses a password for this. Then they somehow steal your hashes. Now they look for their own account and what hash they have and check if someone has the same hash. Then they log in to that other persons account.
If all passwords were salted with their own salt, even the same passwords would have a different hash.
I got a followup question to that if that's okay:
If passwords are always hashed (and salted differently each time), how are you able to produce the same hash to authenticate a user when they're logging into the system?
Is there something that keeps a track of these things?
Normally you store the password and salt together in your db.
This way each password have a different salt and they are stored in your db.
For checking,
Rember the main reason of having salt is to prevent the hacker from using the rainbow tables. So it’s totally fine to store them as plan text in the db. Because the hacker will have to generate a whole new rainbow table for each password to be able to check againet them. Which is near impossible with current cpu capabilities.
Thank you for the detailed response, I think I understand the gist of it a lot better now :)
As far as I know you can simply store the hash and salt together in the account record in the DB.