Hacker News Reader

Comment by laurencei | Hacker News Reader

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.

View on HN

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-simplifyi...

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.

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.

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.

> 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".

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.

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.

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.

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.

Reply on news.ycombinator.com