Hello,
I would like to implement a password change to users after a certain amount of time. When the user is requested to change its password I would like to prevent him/her from using the current password or a list of previously used password.
How would you do this ?
Currently I did :
Accounts._hashPassword(plainTextPassword) on the client
Send this to the server
On the server I compare the hashed password hashedPassword.digest with the current
password that is stored in the db in bcrypt.
The problem is that they do not look the same. I may be missing some understanding about this bcrypt stuff.
There might be another approach but I do not know how to implement it :
Before updating to the new password, try to login with this new password.
If the login is successful, it means that your new password is the same as your previous password.
First of all, it will annoy the users. I have actual dealings with users subject to such a scheme and they’re all bitching about it. And rightfully so, because:
It’s cargo cult security.
It does not make your system any more secure. In fact, it does the complete opposite!
There’s actual research on this where scientists got legal access to two university’s password databases (about 20,000 passwords each). One university had a mandatory password change after three month, the other university just checked for security once.
Turns out that the passwords with the three months lifespan were less secure on average.
And I can tell you why, exactly: Because nearly everyone of my colleagues will use a scheme where the first part of the password is easy to remember and the second part will be a number.
Which they will increment after each mandatory change.
Which in turn means that not only is the password easier to crack but also the second argument for mandatory changes falls apart:
Because the thinking is that, yes, the passwords may be cracked but the change every three months will then render the cracked password invalid.
But you remember the part where nearly everyone will simply affix a number at the end? Which means that any non-braindead hacker will know exactly what the next password will likely look like.
In summary:
It introduces a hassle for the users
It does not gain you any security
It does even weaken security
I understand that this may be unwelcome because it looks so appealing and makes sense at first glance. However, this is also something where someone must ask: Does this actually work the way you think it works? Which is a very important question regarding security - sometimes things really are counterintuitive (Parts of my studies included psychology - you’d be amazed how many instances there are where common sense goes awry).
Thanks for your answer.
I completely agree with you. I was also incrementing a number after my usual password when I was asked to change my password.
We are adding it as an option for some customers where their internal security policy request it (IT governance).
Eliminate intermittent password change requirements, unless due to a security breach or by user choice
In case you want the original text, it’s in section 5.1.1.2
Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.
Emphasis mine.
There’s some other interesting stuff in there. Like password complexity rules being moderately useless
