4 ms·

In the same spirit, can we please do away with the idea of expiring passwords -- and then enforcing that we can't even re-use our last X number of passwords. It

by dvcc 10y ago

In the same spirit, can we please do away with the idea of expiring passwords -- and then enforcing that we can't even re-use our last X number of passwords. It just causes locked out accounts, written down passwords or adding on one more of whatever character was at the end.

teaearlgraycold 10y ago
Sites with such strict rules should be enforcing 2FA instead.
laurencei 10y ago
There is a specific reason for having "cant reuse last X number of passwords" combined with having an "expiring password" rule. The idea is that if someone was silently in your account, and doing a "stealth" attack - then they could change your password, then change it back to your original password, thus "resetting" your expiring password timer, giving them more time in the system - and you would not know that the password was reset. Preventing old passwords prevents this. Note: The only flaw I never understand with the above is cant the attacker just change the password like 10-15 times in 5mins, and thus "flush" out the old password? Note 2: I dont personally agree with expiring passwords - but it helps understand the reason why it exists.
- tetrep 10y ago
  > The only flaw I never understand with the above is cant the attacker just change the password like 10-15 times in 5mins, and thus "flush" out the old password? In systems where you have the "can't use previous N passwords" when changing it, you also pair that with a "can't change password more than X times a time increment".
- dvcc 10y ago
  That thought requires the users to actually use new and unique passwords on every reset. If the attacker knows that your password is "Password1!!!!", it's pretty easy to guess that the next time it asks you for a password it will be "Password1!!!!!". We're all computationally lazy after all. I feel like the notifications that X device was recently used to login from Y IP/location solve that problem in a much easier way.
- raesene6 10y ago
  err in that attack how do they know your original password to change it back? and if they know your password to change it back why bother changing it in the first place, why not just log in as you? AFAIK the reason for password history is where periodic password change is enforced, to prevent a user from just alternating between two passwords. enforced periodic password change is (in the general case) not great for security, luckily we're starting to see official guidance which recognizes this https://www.ncsc.gov.uk/guidance/password-guidance-simplifying-your-approach https://www.ncsc.gov.uk/guidance/password-guidance-simplifyi...
  - neohaven 10y ago
    Let's say a service does not require you to change the password. You are then "compromised once, compromised forever", at least until you change the password. Let's say it requires you to change it every month. You are compromised at max for a month, right? If the attacker changes the password, you will notice, and make a different password, which will lock them out since they don't know the new one. So they won't change it, but they will lose access next month. This is good... Except if you allow repetitions of old passwords. In this case, the attacker can change your original password to 'aaaaaaaa' for a moment and re-change it back to the original one, which will reset the "one month" timer, leaving them with access. Until you change it, but the platform won't bother you with it since the timer never expires.
    - raesene6 10y ago
      I've done many password audits over the years and all monthly password changes does it make people use sequence passwords (e.g. MyPass1!, MyPass2!, MyPass3!) which are easily guessed by the attacker once they have one instance of the sequence, so really monthly changes add very little in exchange for the hassle they introduce. The more sensible approach is not to force periodic change and only change where there is a suspicion of breach.
- makecheck 10y ago
  Although, a lot of accounts send immediately E-mail on changes (e.g. bank says “the password on your account was changed” so you would know if someone was changing it and changing it back). It actually seems pretty reasonable to send E-mails on every single account update, as some sites do.
  - jlgaddis 10y ago
    Perhaps you would notice. The average user, however, would probably then try to log in to their bank (with their usual password), get in just fine, and then think something along the lines of "oh, the bank's system must be screwed up again" and forget about it.
- jlgaddis 10y ago
  WRT your note, some security policies (I don't remember which of them do it off the top of my head, but things like DoD STIG, PCI-DSS, NIST, CJIS, etc.), require a minimum time (e.g. 1 day) between password changes to prevent exactly this. It doesn't seem that common in the corporate world or typical web apps, though.
  - Bartweiss 10y ago
    This seems extra-terrible for web apps, though. There's a not-uncommon pattern where someone gets an account compromised and starts a password tug-of-war. The attacker gets entry, and possibly changes the password, but doesn't own the recovery account, so the user finds the problem and uses email reset to change the password again. In this case, it's good to block the old (compromised) password, and bad to set a lockout that gives the attacker more time. Of course, a lot went wrong in that story. Forcing email confirmation of all password resets can help, mandating re-typing of the old password for a change can help (against session hijacking, mostly), and any corporate or user-focused solution should probably have a response scheme for reporting and locking compromised accounts anyway. But for social media style sites where the recovery system is "use your email recovery to fight for control", the reset time does seem like a threat.

by dvcc 10y ago

teaearlgraycold 10y ago

Sites with such strict rules should be enforcing 2FA instead.

laurencei 10y ago

There is a specific reason for having "cant reuse last X number of passwords" combined with having an "expiring password" rule. The idea is that if someone was silently in your account, and doing a "stealth" attack - then they could change your password, then change it back to your original password, thus "resetting" your expiring password timer, giving them more time in the system - and you would not know that the password was reset. Preventing old passwords prevents this. Note: The only flaw I never understand with the above is cant the attacker just change the password like 10-15 times in 5mins, and thus "flush" out the old password? Note 2: I dont personally agree with expiring passwords - but it helps understand the reason why it exists.

tetrep 10y ago
> The only flaw I never understand with the above is cant the attacker just change the password like 10-15 times in 5mins, and thus "flush" out the old password? In systems where you have the "can't use previous N passwords" when changing it, you also pair that with a "can't change password more than X times a time increment".
dvcc 10y ago
That thought requires the users to actually use new and unique passwords on every reset. If the attacker knows that your password is "Password1!!!!", it's pretty easy to guess that the next time it asks you for a password it will be "Password1!!!!!". We're all computationally lazy after all. I feel like the notifications that X device was recently used to login from Y IP/location solve that problem in a much easier way.
raesene6 10y ago
err in that attack how do they know your original password to change it back? and if they know your password to change it back why bother changing it in the first place, why not just log in as you? AFAIK the reason for password history is where periodic password change is enforced, to prevent a user from just alternating between two passwords. enforced periodic password change is (in the general case) not great for security, luckily we're starting to see official guidance which recognizes this https://www.ncsc.gov.uk/guidance/password-guidance-simplifying-your-approach https://www.ncsc.gov.uk/guidance/password-guidance-simplifyi...
- neohaven 10y ago
  Let's say a service does not require you to change the password. You are then "compromised once, compromised forever", at least until you change the password. Let's say it requires you to change it every month. You are compromised at max for a month, right? If the attacker changes the password, you will notice, and make a different password, which will lock them out since they don't know the new one. So they won't change it, but they will lose access next month. This is good... Except if you allow repetitions of old passwords. In this case, the attacker can change your original password to 'aaaaaaaa' for a moment and re-change it back to the original one, which will reset the "one month" timer, leaving them with access. Until you change it, but the platform won't bother you with it since the timer never expires.
  - raesene6 10y ago
    I've done many password audits over the years and all monthly password changes does it make people use sequence passwords (e.g. MyPass1!, MyPass2!, MyPass3!) which are easily guessed by the attacker once they have one instance of the sequence, so really monthly changes add very little in exchange for the hassle they introduce. The more sensible approach is not to force periodic change and only change where there is a suspicion of breach.
makecheck 10y ago
Although, a lot of accounts send immediately E-mail on changes (e.g. bank says “the password on your account was changed” so you would know if someone was changing it and changing it back). It actually seems pretty reasonable to send E-mails on every single account update, as some sites do.
- jlgaddis 10y ago
  Perhaps you would notice. The average user, however, would probably then try to log in to their bank (with their usual password), get in just fine, and then think something along the lines of "oh, the bank's system must be screwed up again" and forget about it.
jlgaddis 10y ago
WRT your note, some security policies (I don't remember which of them do it off the top of my head, but things like DoD STIG, PCI-DSS, NIST, CJIS, etc.), require a minimum time (e.g. 1 day) between password changes to prevent exactly this. It doesn't seem that common in the corporate world or typical web apps, though.
- Bartweiss 10y ago
  This seems extra-terrible for web apps, though. There's a not-uncommon pattern where someone gets an account compromised and starts a password tug-of-war. The attacker gets entry, and possibly changes the password, but doesn't own the recovery account, so the user finds the problem and uses email reset to change the password again. In this case, it's good to block the old (compromised) password, and bad to set a lockout that gives the attacker more time. Of course, a lot went wrong in that story. Forcing email confirmation of all password resets can help, mandating re-typing of the old password for a change can help (against session hijacking, mostly), and any corporate or user-focused solution should probably have a response scheme for reporting and locking compromised accounts anyway. But for social media style sites where the recovery system is "use your email recovery to fight for control", the reset time does seem like a threat.