4 ms·
It sounds good in theory, but in practice rotating passwords really doesn't help much. You alluded to it in your last sentence, but if you require password rota
by RcouF1uZ4gsC 6y ago
It sounds good in theory, but in practice rotating passwords really doesn't help much. You alluded to it in your last sentence, but if you require password rotations, say every year, a lot of your users will end up using:
basepassword-2021
which they will change next year to
basepassword-2022
Because password hashing makes it impossible to retrieve the original password, there is no way to guard against people just using a basepassword and appending some type of counter to it.
Thus if there really is a breach where the plaintext password is recovered by an attacker it is trivial to find out what this year's version is.
So all you end up doing is needlessly irritating your users, for not much security.
Multifactor Authentication is a much better solution for the issues of unknown breaches.
- zrail 6y ago> there is no way to guard against people just using a basepassword and appending some type of counter to it. Sure there is. In your update logic, decrement any numbers and check the hash against the existing password. Alternatively, require the existing password in the same form and you don't have to check against hashes, since you have the plaintext password right there.
- glasss 6y agoI don't believe there is any function to perform these checks in Windows Active Directory or Office 365.
- avianlyric 6y agoI think you underestimate people inventiveness when it comes to circumventing these types of systems. People will either keep trying new strategies to embed counters in their passwords (maybe increment a letter, or multiple a number by 10), or they’ll just write the password on a post-it they keep on their laptop. Either way you’ve now got a whole load of complicated code that makes it harder to people to create genuinely strong and memorable passwords, and no additional security.
- josephcsible 6y agoThis wouldn't work either. It would just make users bounce between 2 passwords: foo100 -> bar200 -> foo101 -> bar201 -> foo102, etc.
- banana_giraffe 6y agoThe one system where I saw this implemented in practice used my last x passwords to check. I think "x" was 50 Because it had a fairly short password cycle, I'm sure most users ended up with something like "password1!TwentyFour" then "password1!TwentyFive". Me: I just changed my password 51 times when it was time. I'm not sure what point I was proving, but I was proud of myself.
- josephcsible 6y agoYou can't stop someone's next password from being a variant of their next-to-last one unless you store them unhashed.
- banana_giraffe 6y agoCouldn't you hash some obvious variants of the new password to test against? I always assumed this system did that since it would reject some passwords that were close to old passwords. Of course, it's also possible they stored the clear text password, I have no real way of knowing.
- josephcsible 6y ago> Couldn't you hash some obvious variants of the new password to test against? This is impractical if you're following good password storage practices. Assume the user's new password is 16 characters long, and that only the 95 printable characters are allowed in passwords. Then to test that the Levenshtein distances between it and the user's last 5 passwords are all greater than 1, the server would have to compute (5 * (1 + 95 * 17 + 16 + 94 * 16)) = 15,680 different hashes, which will take quite a while if you picked a secure iteration count for your password hashing function. And even if you did this, it still couldn't detect mypassword100100 -> mypassword101101 -> mypassword102102, etc. (Making sure the Levenshtein distances are greater than 2 would require checking millions of hashes.)
- RcouF1uZ4gsC 6y ago> Alternatively, require the existing password in the same form and you don't have to check against hashes, since you have the plaintext password right there. Presumably, you will also have a forgot password flow that allows you to change your password without entering the old one. People will make things easy for themselves. Coming up with good passwords is hard. Having to rotate passwords just seems like a lot of busywork and people will make it as easy for themselves as possible.
- deleted 6y ago[deleted]
- unionpivo 6y agoSure thaen you have: SomePasswordABC SomePasswordDEF SomePasswordGHI ... Or My1Password! My2Password! My3Password! ... Or MyPasswordUno MyPasswordDue MyPasswordTre
- ajuc 6y ago> Because password hashing makes it impossible to retrieve the original password, there is no way to guard against people just using a basepassword and appending some type of counter to it. Almost all the implementations require the old password when you change it to the new password, so it's trivial to check if they are too similar. def changePassword(login, cleartextOld, cleartextNew): if too_similar(cleartextOld, cleartextNew): return new Error("too similar") hashOld = hash(cleartextOld) hashNew = hash(cleartextNew) if authorized(login, hashOld): setPassword(login, hashNew) return new Ok(); If you're afraid of sending cleartext passwords - do the too_similar check on the client side. The users that can write their own client to bypass client-side checks are exactly the users you don't need to worry about.
- gmfawcett 6y agoA user could defeat this by changing to an intermediary password and then incrementing the original. E.g. sign in with current password "cat100", change it to "dog100", then sign in as "dog100" and change to "cat101".
- tshaddox 6y agoThe system can just store the last n passwords (salted and hashed, of course) for each user. I seem to recall some software I had to use in college wouldn’t let you toggle between passwords like this.
- michaelt 6y agoAh, but one could write a script to change password n+1 times. That's why, to encourage users to assume last month's password was compromised, when my users change their password the old password is automatically posted to twitter /s
- unrealhoang 6y agoStoring salted & hashed passwords can only prevent reuse the exact old password, it can't prevent reuse & increase though.
- garmaine 6y ago> Because password hashing makes it impossible to retrieve the original password, there is no way to guard against people just using a basepassword and appending some type of counter to it. > Thus if there really is a breach where the plaintext password is recovered by an attacker it is trivial to find out what this year's version is. These are contradictory statements.