Question about password best practices. Our site just went through pen testing, as part of auditing for PCI compliance.
One thing we got dinged on was that we don't keep a password history, so that the user can't revert to their previous password. The tester's report said, "This, in turn, results in users utilizing a single password for a long period of time, which may result in password disclosure"
It seems to me that this is the opposite of the truth. If I'm keeping a password history, then in the event of a breach, there is that much more data that would leaking, potentially disclosing password data if we made a mistake in the rest of how we handle it (hashing, etc.). And while I'm not a crypto expert at all, it seems to me that if there's a list of salted, hashed passwords, then given that the salt is a constant per user, an attacker would have some leg up in discovering the original password if there were many samples that included the same salt.
If I want to minimize the data I can disclose about users, I ought to minimize the amount of data that I'm storing about them.
It is a risk trade-off: letting the user reuse passwords used in the last X months is seen as less risky than storing the last 12 passwords (assuming the user is made to cycle their password monthly) if you are storing the credentials securely (if anything is plain or reversible, you need to fix that ASAP).
Having 12 strongly salted+hashed password strings is not going to help an attacker much compared to having 1, even if you use the same salt (though I've not doe the maths myself, you'll need to ask a cryto expert for actual risk figures).
You could of course use a different salt per stored password instead of per user, to mitigate this completely.
Remember that password reuse risk flows both ways: if they reuse the password in your application and your application is well written with regard to securely storing credentials, they may be reusing the same password in another application that is less secure so you are more at the mercy of the password data from elsewhere that is storing things plain.
PCI Compliance is kind of arbitrary. I once worked for a company that kept all their passwords in plain text, and still managed to get compliance. I was just an intern at the time, and I still thought that was kind of weird, especially since this was around 2011 and not the mid-90's.
Consider that leaking their past passwords only matters if they reuse them elsewhere.
If they reuse passwords, then chances are you will expose them just as much if you don't force them to rotate passwords, when they end up putting their password into a scam site or run by people who store plain text.
And if you don't check for reuse, you are not forcing them to rotate passwords.
In the face of that, you can't do much better than to make it harder for them to keep reusing passwords on your site so at least a password leak elsewhere won't expose their account with you.
(And re-using the salt is a mistake; don't do that)
One thing we got dinged on was that we don't keep a password history, so that the user can't revert to their previous password. The tester's report said, "This, in turn, results in users utilizing a single password for a long period of time, which may result in password disclosure"
It seems to me that this is the opposite of the truth. If I'm keeping a password history, then in the event of a breach, there is that much more data that would leaking, potentially disclosing password data if we made a mistake in the rest of how we handle it (hashing, etc.). And while I'm not a crypto expert at all, it seems to me that if there's a list of salted, hashed passwords, then given that the salt is a constant per user, an attacker would have some leg up in discovering the original password if there were many samples that included the same salt.
If I want to minimize the data I can disclose about users, I ought to minimize the amount of data that I'm storing about them.