Please read as I did many searches and believe this is NOT a duplicate question.
For your reference, I've read these articles and other questions already:
Long version of question - story time
Why not just not store the salt? I'm NOT talking about not using a salt. I'm talking about regenerating the salt each time the user logs in and never storing the salt at all anywhere.
This is why I bring it up: We, the group I'm in, is deciding to change the password scheme because we want to move to something better. Someone in the group felt that storing the salt was a security risk for some reason so they decided :
"well, let's just not store the salt. Let's regenerate it each time."
I heard this and thought, "what? why?"
As a reply I got back, "It's a puzzle piece that if they don't have they can't use and so the password is protected."
"ok, how do we generate the salt each time? It would have to be based off of something that will remain constant for the entirety of the user's existence and never change", I said.
"Let's use the user's global user identifier id (aka their user id or guid)"
"But doesn't that make the salt not really random and predictable?"
"We'll add a random component to mix it up."
"But.....then how will you regenerate it each time."
"Well, here is the algorithm:"
For user creation:
- On user creation, create a new salt for the user using their guid. Then we do some "magic" with sha512 to "randomize" the salt.
- Now we create a password hash by taking the salt from step 1, the password and create a password hash.
- Store the password hash, don't store the salt.
- We regenerate the salt that we generated above on user creation.
- We have the salt now, and the password hash is stored in the database already so we will use bcrypt, or pbkdf2, or scrypt to check the password. (bycrypt i think also generates another salt in some languages automatically so this is another salt that is different from the one that we 'regenerate' each time.)
- Now we're safer because look, no salt was ever stored. And the "magic" will only be known to a few of us in the group so it isn't easy to guess.
"But, why do it this way?"
"We want to do something deliberately different from the typical password schemes to add protection." (sounds like security through obscurity to me but I can understand this part. It's an unorthodox approach using algorithms that are considered secure already.
Well, so my question is: is there any merit to NOT storing the salt and instead regenerating it each time? If so, what would be a reasonable way of regenerating the salt? If not, is it because it doesn't add any real security (it's more of security theater or security through obscurity)?
For the sake of simplicity in your answers, lets all limit our answers to the topic of the regenerating the salt each time and not storing it in the database vs storing it in the database and whether this classifies as security through obscurity or security theater or if it's a valid approach.
Here are my views but I would really appreciate your input as well.
Advantages to not storing salt and regenerating it
If attackers accesses just the database, they see that there is no salt. They assume some simple scheme and attack it based on this assumption. They get no results from the attack. They start scratching their head and are stumped. (somewhat, ideal scenario for password protection right?)
Sql injection attacks won't get the salt since it's not in the db, but sql injection is a thing of the past, right? :-) Everyone uses parameterized sql.
Less of a need to encrypt the password hash, even though it's still a good idea. Assuming the somewhat ideal case above.
Disadvantages of regenerating salt
Not really randomized since it has to be based on constant information that we'll store in the database anyway which is virtually like storing the salt.
Relies a bit on secrecy of which user attributes will be used for salt regeneration.
Don't know if 'leaking' the attributes reduces the security of the salt regeneration scheme. I think it does. Say someone is angry and leaves the company and discloses the user attributes being used then an attacker can regenerate the salts themselves which means they can more effectively attack passwords now.
Advantages of storing the salt
Well understood code and less magic to code and test.
Industry standard. As far as I can gather. I guess not many companies come out publicly and say what password schemes they use....do they?
Disadvantages of storing the salt
Visible to attackers. They can more effectively attack each password. (yes, use a pbkdf2 or bcrypt or scrypt for the work factor but at least they have an idea of how to proceed, even if they know it'll take them a while.)