Password complexity check: different from the last X passwords

Question

Most services, programs, etc. have various password complexity checks. Without delving into the effectiveness of such checks , I thought about what might be interesting, but also potentially problematic:

"The new password must be Y characters other than the last X passwords."

This will prevent users from using passwords like Password1! Password2! etc. But if this is done, you cannot use the hash previously used password - they would be encrypted at best ... Correct?

For a small Y and a fairly short password, you probably still have the hash and bruteforce all Y letter options for the new password, but this becomes impossible like Y , and the password is longer.

My original idea is this: because when you change the password, you must specify your original password, hash the new password and store it, and the old one in encrypted form. Now it is reversible.

So, if the active password is always hashed, is there a better way to do this? And also does this increase or decrease the security of the application?

Answer 1

I tried to put this in a comment, but I think it is important enough to respond.

The circuit proposed by the OP is not necessarily a violation of CWE-257. The proposal does not allow the system administrator (say) to recover old passwords.

The suggestion is to use the new password as the encryption key for all old passwords. If you can live with a “new password check” residing on the client and not on the server, then this is no less secure than encrypting everything else with a password.

Thus, the "change password" gadget will be the client code. The server will send an encrypted list of earlier passwords that the client can decrypt with the current user password, and then re-encrypt with the new user password. The server does not have enough information to determine any of the passwords, whether old or new. Only the client has this information, but in any case it matters ... The difference is that the attacker who learned your current password could also know your old passwords. Since learning your current password is already a disaster, it does not affect me, as it is much worse.

True, this does not protect against an “attack” of an employee who writes his own utility for changing a password in order to circumvent password restrictions, since verification is not performed on the server side. But this is in no way a violation of the CWE-257, in my opinion.

This is actually a reasonable idea.

Answer 2

The Oracle requirement that you specify says that password n ​​should be very different from password n-1, and not that password n ​​should be different from all previous passwords. Typically, to change the password, the user enters the current password as part of this. Thus, you have everything you need to implement this requirement, and you do not need to store passwords in a reversible mode (encryption, forced formatting, etc.).

I understand that this does not directly concern the requirement as originally set (different from the last X-passwords), but I feel that this is a fictitious requirement. Reversible passwords will be required for your requirement (the mechanism does not matter), and most experts will agree that this is incorrect. I believe that you simply misinterpreted Oracle's requirements if that is really what caused the question.

EDIT:

OK, I just thought about how to implement what you ask for without reversible passwords. I still think that you are interpreting the Oracle requirement incorrectly, and I would not do what I am going to describe myself, but it will meet the requirements without reversible passwords.

• Select a reserved character that is not allowed to appear in the real password. For discussion, suppose this is a backslash.
• List all possible ways to replace at most Y backslashes in a password, hashing the result each time.
• Support only the latest X hash sets generated in this way.
• When the user selects a new password, repeat the procedure on the tender password and compare its individual hashes with individual recent hashes.

Goofy, but that should meet the requirement.

Answer 3

Password encryption is a clear violation of the CWE-257 where it should never be . However, in the case of an expired password, the user has just logged in to save the plain text of this password. Then force the user to change the password and calculate the hamming distance between them. As soon as the user provides a password that is different from another, hash this new password and throw away the plain text.

EDIT: You can save the salt + hash of all old passwords to make sure that the user does not select the password that he had in the past. But provided that the password is N letters, different from all passwords , weakens the system as a whole and is expensive, as this will require a comparison of o (n).