When to generate New Salt and Hash?

[doubledee]

When a User changes his/her Email Address, should I generate a new Salt and Hash?

 

(I am re-using the code I used for a Password Reset, and during that I generated a new Salt and Hash for security.  I guess it can't hurt...)

 

Thanks,

 

 

Debbie

 

[scootstah]

Is their email part of your salt or hash algorithm?

 

If not, I can't possibly see why you would want to do that.

[doubledee]

Is their email part of your salt or hash algorithm?

 

No.

 

 

If not, I can't possibly see why you would want to do that.

 

Because whenever you change a Password you should update your Salt, so why not when they update their Email?

 

I just figured it was good, pro-active security house-keeping, although I agree it isn't a must.

 

 

Debbie

 

 

[scootstah]

Because whenever you change a Password you should update your Salt, so why not when they update their Email?

 

Because they are completely unrelated and it has no possible benefit.

[doubledee]

Because whenever you change a Password you should update your Salt, so why not when they update their Email?

 

Because they are completely unrelated and it has no possible benefit.

 

Your Tire Pressure and your Oil are unrelated as well, yet when you go to a good mechanic to get your Oil changed, he/she will usually check other things like your Tire Pressure.

 

Why not be proactive and give the User a new Salt when they change something in their account?

 

 

Debbie

 

[scootstah]

Your tire pressure and oil are related in the sense that they are both considered routine maintenance.

 

The user's email has nothing to do with the password hash.

 

Aside from that, you can't just update the hash without knowing their password.

[AyKay47]

Because whenever you change a Password you should update your Salt, so why not when they update their Email?

 

Because they are completely unrelated and it has no possible benefit.

 

Your Tire Pressure and your Oil are unrelated as well, yet when you go to a good mechanic to get your Oil changed, he/she will usually check other things like your Tire Pressure.

 

Why not be proactive and give the User a new Salt when they change something in their account?

 

 

Debbie

 

Because there is nothing proactive about something that is useless and a waste of time.

What the heck do tires and oil have anything to do with the web.

You said somewhere above that a user's email is completely unrelated to the salt and hash algorithm you are using,

so why are you trying to incorporate it as such.

Doesn't make much sense.

[Psycho]

Aside from that, you can't just update the hash without knowing their password.

 

Let's not let things like logic and plain common sense cloud our decisions, that would be silly. All you need to do is store the password in a separate field in plain-text. Then you can update the hash whenever the user changes their email or when they click the "home" tab on the third Tuesday of every month. Yeah, that should work.

[doubledee]

Your tire pressure and oil are related in the sense that they are both considered routine maintenance.

 

The user's email has nothing to do with the password hash.

 

Aside from that, you can't just update the hash without knowing their password.

 

Right, but I won't update the User's Email unless they know their password!!

 

 

Debbie

 

 

[doubledee]

Let's not let things like logic and plain common sense cloud our decisions,

 

Oh, right, I forgot...

 

If Psycho thinks it or does it, then it is "logical", else it is a complete steaming pile.

 

It must be really limiting in life to think it's your way or the highway.

 

I come to PHPFreaks for intelligent conversations, not "I don't agree with you, so you and your idea is stupid."

 

Guess it is an INsecurity issue... 

 

 

Debbie

 

 

[kicken]

Right, but I won't update the User's Email unless they know their password!!

 

So do you plan on making them re-input their password and then checking it when they try and update their email?  Because unless you do that you won't be able to re-generate a hash as you won't have a password to hash. Following that, you can't generate a new salt without re-generating the hash.

 

So either you have to ask for their password again when they input a new email address(kind of silly and unnecessary), or you leave the salt and password alone (nice and easy).

[Psycho]

If Psycho thinks it or does it, then it is "logical", else it is a complete steaming pile.

 

It must be really limiting in life to think it's your way or the highway.

 

I come to PHPFreaks for intelligent conversations, not "I don't agree with you, so you and your idea is stupid."

 

Guess it is an INsecurity issue... 

 

Excuse me for making a tongue in cheek comment, I'm not the one who made a personal attack, so maybe the thin skin remark was simply deflection?

 

Let's back up to the original request. You asked if you "should" update the user's salt/hash when they change their email address. A couple people responded that there was no valid reason for doing so. Creating a new salt and hash doesn't make their data more or less secure than it was before. So, creating a new salt/hash is just performing an unnecessary process. However, it was also stated that IF you are using the email address as part of your salt then you would have to generate a new salt and hash. But, that's not because of a security issue, but because the old one would no longer be valid.

 

So, forgive me for not understanding why you continue to argue for updating the salt and hash in the face of clear information that it serves no purpose.

 

You used the analogy of a mechanic checking your tire pressure when you get your oil changed. Well, a car's tire may lose pressure over time, so it make sense to do that check. A user's salt and hash don't wear out or lose anything over time. It is just as secure/insecure as it was at the time it was created as it ever will be. Recreating a new salt and hash using the same methods only creates a new salt and hash of the exact same level of security/insecurity.

 

Now, if you decide to change the current salt/hash method because you determine it is not secure enough, then you need a process to update the users salts/hashes using the new method. But, that would be done during the login process before they ever get to the change email function anyway.

 

You ask for input, and when it is given, you reject it and make up spurious arguments. So, why ask? If you want to update the user's salt and hash when they change their email address, go for it. No need to ask for anyone's opinion if you've already made up your mind. I'm not trying to be mean, just trying to understand why you ask a question and then reject the answer because it doesn't fit with the solution you already decided on before asking the question.

 

Since you still think that updating the salt and hash when a user updates their email address has benefit, I would be interested in hearing what specific benefits you think it provides. And not just "It's proactive housekeeping" because that doesn't mean anything by itself. Deleting temp logs or old registration requests that were never completed are "housekeeping" tasks that have the benefit of clearing out unused data and storage space.

[l0gic]

Your users email address can only be changed by the owner who has already logged in proving and confirming their credentials, right?

 

If so your system is working fine.

 

If not, and you're worried that the person who has managed to log-in to change said users password may be tempted to do it again in future. Well there's nothing you can do really.

 

If the user has logged in they've already satisfied your script with the correct login name and password, changing the hash won't matter..

 

For example, if my password is "bobbob7" and I log in to your site and change my email address, if you then want to change my salt/hash it isn't going to change my password that I type in, I will still use "bobbob7" next time I log in.

 

I understand you want to be secure but I also believe that what you want to do here is pointless. If you did this, where would your security stop? Next thing you know when a user wants to log in they will have to call you to come over and watch them log in just so you know it's them..?

 

Maybe you can explain your thought process on this some more?