[pbhjpbhj]

Is that good? They have poor data handling and sunsetting protocols is what you're saying.

UK law requires that personal data is not kept for longer than is necessary and is securely handled and such. So if those passwords in an "ancient DB" had personal data associated with them (real names, say) then they've been breaking the law (for a long time, is the implication).

Surely if you had passwords in old DBs then when you introduce hashing you salt and hash them and sanitise the DB and all backups ... having them still hanging around is a significant failure too. But yes, not as significant as having plaintext passwords in DBs now would be.

[_puk]

Interesting point on the UK laws, but I doubt PII is kept alongside login data, just referenced, and removed as needed without removing a user's login credentials.

Far from an expert, but hasn't flagging an account as needing a password change on next login been used as a way to migrate to properly encrypted passwords in the past?

[throwanem]

Often. But you want to back it up with a blanket invalidation and password deletion after some grace period, to deal with the case where the user just never logs back in - and a password reset process outside the auth flow, to handle anyone who comes back after that.

[xp84]

A strategy that has worked great for me transitioning off of poorly-thought-out legacy password storage schemes is to take the "bad" hash you have for everyone and treat it exactly as you would a plaintext password - in other words, salt and properly hash it the same way the new passwords are done. Then I delete the unsafe hash and flag that account as "use the old hashing scheme on the password first before normal authentication process, then correctly re-hash and salt the password and store it normally."