Menu
Most services, programs, etc. have various password complexity checks. Without delving into the efficacy of such checks, I thought of one that might be interesting, but also potentially problematic check:
"The new password must be Y characters different from the last X passwords."
This would prevent people from using passwords like Password1!, Password2!, and so on. But if that's done, one cannot hash the previously used password - they would be at best encrypted... Right?
For a small Y and a fairly short password, you could probably still store the hash and bruteforce all Y letter variations of the new password, but this gets unfeasible as Y and the password length grows.
My original idea is this: since when you change the password you must provide your original password, hash the new password and store and the old one in encrypted form. Now it's reversible.
So assuming an active password is always hashed, is there a better way to do this? And also does having this in place increase or decrease the security of the application?
942
In the Local Security Policy console, navigate to Account Policies > Password Policy. On the right pane, double-click Password must meet complexity requirements. Select Disabled > click Apply > click OK and close the Local Security Policy console.
According to guidance offered by the National Institute of Standards and Technology (NIST), password length is more important than password complexity. This actually makes a lot of sense as longer passphrases take longer to crack, and they are easier to remember than a string of meaningless characters.
Password complexity is a measure of how difficult a password is to guess in relation to any number of guessing or cracking methods. In some cases, the term is also used to refer to requirements for password selection that are designed to increase password complexity in the interest of better security.
You can find your current AD password policy for a specific domain either by navigating to Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Account Policies -> Password Policy via the management console, or by using the PowerShell command Get-ADDefaultDomainPasswordPolicy.
I tried to put this in a comment, but I think this is important enough to put in an answer.
The scheme proposed by OP is not necessarily a violation of CWE-257. The proposal does not allow a system administrator (say) to recover the old passwords.
The proposal is to use the new password as the encryption key for all of the old passwords. If you can live with the "new password verification" living on the client and not the server, then this is no less secure than encrypting anything else using the password.
So the "change password" gadget would be client-side code. The server would send the encrypted list of N earlier passwords, which the client could decrypt with the user's current password and then re-encrypt with the user's new password. At no time does the server have enough information to determine any of the passwords, whether old or new. Only the client has this information, but it has that in any case... The difference being that an attacker who learned your current password could also learn your old passwords. Since learning your current password is already a disaster, this does not strike me as all that much worse.
True, this does not guard against the "attack" of an employee writing their own password change utility to get around the password restrictions, since the validation is not done on the server side. But in no way is this a violation of CWE-257, in my opinion.
It is actually a reasonably clever idea.
174
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
