1

I was forced to changed my password to an account (large institution) and it had a rule that the new password cannot contains a series of 4 consecutive characters that were in 10 previously used passwords. For example, if my current password had the sequence "abcd", the next 10 passwords cannot contain "abcd".

My first guess is that the institution is storing 10 previous passwords in a decodable manner. My question is thus: is there any way they could be doing such a procedure in a secure manner?

In another question we have a comparison to the current password which would be provided by the user, but it doesn't deal with 10 (!) previous passwords.

3

Yes this can be implemented securely through the use of an HSM. there's an existing question on this here

  • 1
    Might be worth adding that queries to the HSM must also be limited - which it presumably is, possibly by rate-limiting inside the HSM itself. Otherwise, the logic in Sjoerd's answer still works (that they could brute-force four-character subsequences and reconstruct). – cloudfeet Mar 23 '17 at 15:33
  • 1
    Well the question specifically related to changing passwords, not login. Change password is usually only offered after the user has provided a correct initial authentication (or been through some other validation process such as password reset), so if an attacker has got to that point, they can just reset to a password of their choosing, no need to go guessing it. Usually in banks the HSM will be a couple of layers back and any account lockout would be handled at the front-end app. server layer. – Rory McCune Mar 23 '17 at 15:57
1

This can not be implemented securely.

If they can check if four characters are present in the passwords, an attacker can too. Instead of brute-forcing your whole password, an attacker can now guess four characters at a time.

  • With an HSM (used by a lot of larger organization like banks) it's possible to do partial password checks securely. – Rory McCune Mar 23 '17 at 15:23
1

Well a simple and almost secure way is to only register an old password at the moment the user declares his new password - it is possible because most way of entering a new password first require the old one.

That way, even if the old passwords list was compromised, an attacker could not use it to connect the system on behalf of you because the old password are guaranteed per the policy not be be active. I could bet a coin that it is actually used in some organizations without an HSM...

Unfortunately in a real world with human users, this is still not a harmless way, because if a user uses a rolling list of 11 passwords, the attacker should simply wait a month or two, and he should get the password in no more than 10 tries... Even if the policy has been respected!

Anyway, IMHO the highest problem if that few users are able to create 10 different good passwords and remember them. So the risk that a user writes down his own list of eleven password is high, and the weakest place in the security chain is no longer the secure storage for the old passwords list (HSM have good enough reputation for that) but more simply the desk drawer that contains the list...

Security that comes at the expense of useability comes at the expense of security...

1

Obviously, they know your current as well as what you'd like your new password to be.

In my old shop, we created a custom PAM module to implement strong passwords. How we handled historical passwords was by saving the crypt'd hash from the shadow table for the last N cases. We'd then generate new crypt'd password hashes by manipulating the new password to see if it matched any of the last N hashes.

Granted the above wouldn't easily handle the complexity of the check you're noting. So there are probably some ways to see a users historic passwords, but we have to hope their solution is secure enough.

Not the answer you're looking for? Browse other questions tagged or ask your own question.