1

Looking at people complaining about Yahoo forcing users to change their passwords. We can see that people do not particularly like to change passwords (and whether we change them regularly is an increase in security is debatable). These two cases (yahoo breaches and periodic password changes) deal with the fact that password hashes have been (or might be) stolen.

Yet, that is not the only case in which it is advisable to change a password. The other case is session hijacking.

Assuming a networked and multi-session (say, from different divices at the same time) application, when a user suspects that his session we often advise that he changes his password. This makes sense to some extent because OWASP argues that all current sessions should be invalidated on password change. And moreover, since session tokes are often derivated from the password hash.

Instead of advising this user to change his password, can't we simply re-use the same password and simply re-salt it?

Looking at the old Would re-salting passwords regularly in-/decrease security? I'm thinking whether there are disadvantages in allowing a user to keep their passowrds. To perform the re-salting we need the user to give us the password, so a hijacker would be unable to do it.

So yeah, it is a usability advantage to a user that he can keep using the same password but:

  • Performing the re-salting, would this be more vulnerable (that a simple password change) to an attacker knowing part of the hash (e.g. from the session token)? (I believe that not)
  • Avoiding any information from the password hash leaking into the session token would mitigate it?
  • Providing a list of open sessions to the user instead and allowing him to disable them would be better? (I believe that not since the attacker could do it too)
Community
  • 1
grochmal
  • 5,757
  • 2
  • 19
  • 30
  • What's your vector here? If you use an encrypted connection the session will only really get hijacked if the attacker controls the client machine. If that's the case, then the password is likely compromised anyways. If they forgot to log out on a public computer, I fail to see what re-salting would accomplish. Just incorporate the fingerprint in the session and let the user invalidate specific sessions from an app or something. – guest Feb 20 '17 at 21:21
  • 2
    Your session token should not be related to the password hash in any way or form. If you suspect a session hijack, invalidate the session and re-authenticate the user (force them to re-login). – Jacco Feb 20 '17 at 21:33
  • @guest - if someone forgets to log out on some machine and that session is allowed to kill other sessions then the user will not be able to ever login back (given that the attacker is quick enough to kill sessions). Or you get something like SO, where you can keep a state where the password goes over HTTPS but you can use the session over plain HTTP. – grochmal Feb 20 '17 at 21:33
  • @Jacco - Yeah, I think, you are correct, I'm overcomplicating. Invalidating all sessions and re-authenticating should be enough. No need for more. This should be an answer. – grochmal Feb 20 '17 at 21:52

2 Answers2

2

No, it would not work. You hopefully don't have the password on your database, so you cannot just change the hash without locking out the user. To change the hash, you have to wait the user to authenticate, so you have the password. With the password you create another salt, hash both, save the hash and throw the password away. But that is not what you will want to do.

The sessions may not be tied to the password, but saved on a table somewhere, so it's best to just get rid of all session tokens AND force the user to change the password, by invalidating the current one and send an out of band message (email, sms) with a new one or a link to a change your password page.

ThoriumBR
  • 51,983
  • 13
  • 131
  • 149
  • But ain't the only person who can suspect a session hijack the user himself (I might have not been clear about it, sorry)? In other words, when there is a suspected session hijack is because the user suspects it, so I do have his full attention. And his attention is on the application, sending a message or just giving him a popup should do the same right? – grochmal Feb 20 '17 at 21:50
  • The user probably will not notice. Users don't even notice they are logging in on the wrong site, how can they possibly know someone is using the same session as theirs? Not happening. If you suspect there's a session hijack, invalidate all sessions, invalidate the password and send the out-of-band reset password message. – ThoriumBR Feb 21 '17 at 12:28
  • Good point, I am used to users noticing session hijacks because that is what I encounter most of the time: a user wondering who made changes to his account configuration. Yet, that's certainly biased. And it also is a separate question which I should ask in a separate post (will do that tomorrow probably). – grochmal Feb 22 '17 at 00:37
2

The idea behind the breach is that a hacker now has your password. He got it by using any of a number of attacks (rainbow, dictionary, brute force) on an image of Yahoo's database that he obtained through illicit means.

If he has your password, changing the salt won't do anything. He doesn't need your salt. He doesn't need your hash. All he needs is your password.

When he provides that password on the login page, Yahoo will happily look up the latest salt for him, and will compute the password hash using it. From there he will be logged in with access to your account.

Besides, it is not possible for Yahoo to change the salt and regenerate the password hash, unless they have the password itself in plaintext. The shouldn't. If they do, the hacker still has the password, which hasn't changed, and can still log in as you.

John Wu
  • 9,181
  • 1
  • 29
  • 39