2 replaced http://security.stackexchange.com/ with https://security.stackexchange.com/
source | link

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 debatablewhether 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?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)

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)

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)
1
source | link

Can we simply re-salt password on suspected session hijack?

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)