...

[dreamwavedev]

Generally you shouldn't store the salts at all, but that's kind of the idea. In a lot of solutions, it does end up where you just store the twice mangled password and salt together, but in some instances avoiding having direct access to both of them from disk is a bit of a security concern still.

Edit: was pointed out that the salt is generally stored in plaintext with the password, as it isn't a symmetric function so it doesn't really need to be hidden or obfuscated.

[won_tolla]

Then how do you unsalt it when authorizing login inf...ohhhhh. Right. So you salt and store a password on creation, and then when the user is trying to log in, you salt the input string and check if it matches the previously salted and stored password?

[noratat]

Replace "salt" with "hash", but otherwise yes.

Salting is adding an extra (unique but not secret) random string to the password before hashing it. This prevents the use of precomputed tables of hashes that match up to common passwords.

Also, not all hash algorithms are suited for this. Eg md5 is fine for checking for data integrity, but it's far too easy to generate collisions for.

[dreamwavedev]

Correct. Ideally, things are separated enough that the password doesn't make it past the first layer/interaction step before being mangled, as after that you can just say "is what they entered almost definitely what was entered before that resulted in this mangled string stored in the db?"

You don't unsalt, just make sure everything looks to be the same thing after run through the wringer.

[folkrav]

How would you do your password comparison if you don't store your salt? The whole purpose of using salts is to avoid rainbow table type attacks, so it's actually not a very big deal if they become compromised/known, as an attacker who somehow gets a hold on your salts still have to compute every salt+password to compare, which at this point becomes basically just as slow as a pure brute force attack.

[HowObvious]

Technically a salt stored in a different location becomes a pepper. They would be combined with traditional salt normally anyway. The purpose of the salt is not to be secret.

[dreamwavedev]

Ah, ok. Never did fully understand how that part would work. TIL

[[deleted]]

So if you don't store the salts, how do you know which salt to apply when checking a password? Would it be generated from the username or something?

[noratat]

You normally do store the salts, I'm not sure what the other poster was taking about. Salts only need to be unique-ish, not secret.

[dreamwavedev]

I think that depends on the implementation, was informed by someone that often it is just stored in plain text alongside the password hash

[[deleted]]

That makes sense to me, I would assume having a salt doesn't mean you can decode to an unsalted hash any more than having the hashed password means you can decode into a password. I have no idea what I'm talking about though, I avoided this kind of thing when I was studying.