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.
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.