6 ms·
> 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 an
by 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