3

Could the following password requirements be enforced, without keeping a plaintext/encrypted copy of the current password?

The ######## password requirements are as follows:
    * Passwords must be updated every 90 days.
    * Users may not re-use the previous eight passwords.
    * Passwords must be 8 to 16 characters in length.
    * Passwords must contain at least:
            - One alphabetic character
            - One numeric character
            - One of the following special characters: @, #, $
    * Passwords must contain a non-numeric in the first and last positions.
    * Passwords may not contain two consecutive identical characters.
    * When changing a password, the new password must not contain more than
      three consecutive characters from the previous password.
    * Passwords may not contain a dictionary word or proper noun.
    * Passwords may not be the same as, or contain, the user ID.
    * Passwords are case sensitive.  When you create a password using a mix
      of uppercase and lowercase letters, it must always be entered that way.

The condition "When changing a password, the new password must not contain more than three consecutive characters from the previous password." is the one that I am curious about.

  • Are you sure it's enforced beyond the user instructions? Not all requirements are validated automatically... – dandavis Jul 8 '16 at 17:07
  • I only mention this because my university requires regular password changes, and they too had/have this rule, and i noticed a few years ago that my whole previous password was accepted, but a couple years before that, the same trick was rejected. I assumed they switched methods, but didn't update the guidelines because the rules themselves still makes sense. Those kind of overly-restrictive policies seem to imply that at least at one point, they were worried about brute-forcing. – dandavis Jul 8 '16 at 18:59
4

If the 'change password' form asks for the current (old) as well as the new password (as it should), it doesn't have to keep a plaintext copy around.

It can check that the old password is correct by comparing the hashed versions, and then do the check against the requirement you mentioned and only if it passes, update the password in the database.

(Update - changed "encrypted" to "hashed" to avoid distracting discussion on whether encryption is by definition reversible)

  • Passwords shouldnt be stored at all, not even encrypted. You probably meant "hashed"? – hamena314 Jul 8 '16 at 13:04
  • Well yes. I see hashing as a form of encryption. – Mark Koek Jul 8 '16 at 13:05
  • @MarkKoek Not to split hairs but the two are very different. While they both obfuscate plaintext, encryption implies it can be decoded where hashing is one-way. – DKNUCKLES Jul 8 '16 at 13:10
  • 1
    Hashing != Encrypting. Hashing is taking a cow and making a burger out of it. You cant re-create the cow from the burger. ... Encrypting is pushing a cow 13 times to get "Pbj". If you then step on the other side and push the "Pbj" 13 times back, you again get "Cow" (Caesar-Shift 13 for example). – hamena314 Jul 8 '16 at 13:14
  • Thank you, I am aware of the difference. I think it is largely a semantic discussion not really relevant to the question. Will happily replace "encrypted" with "hashed" in my post above. :) – Mark Koek Jul 8 '16 at 13:22
1

In the context of plain text passwords, here are the most concerning policies:

* Passwords must be 8 to 16 characters in length.

While setting a maximum length of 16 characters may simply be a misguided or misinformed policy, it most likely points to how the system is storing the password and compatibility with legacy systems.

The biggest issue here would be if the database field was set at 16 characters and they are storing the passwords as plain text. If this is the case, the system is completely insecure.

However, they could also be using a hash such as crypt16 that limits the password length to 16 characters, although this is not widely used and less likely the explanation. If this is the case, the system is dangerously insecure.

Another reason could be that they are using MD5 and someone determined that due to collisions there is little to gain by allowing passwords longer than 16 characters. Although this logic is flawed, I have seen it happen. If this is the case, the system is still dangerously insecure.

I think the most likely explanation is that they are encrypting passwords and not hashing them, which means they are storing the encryption key somewhere which is also dangerously insecure.

Hopefully the reason for this has to do with limitations buried somewhere in a massive code base they are afraid to touch and they are actually storing the passwords using SHA256, but unfortunately that is not likely. The most likely problem here is that they are dangerously insecure.

* Users may not re-use the previous eight passwords.

To determine this they must be storing the your previous eight passwords. Seeing that they are most likely using plaintext, a weak hashing algorithm, or reversible encryption, this means that 9 passwords for every user are potentially at risk.

* Passwords must contain at least:
        - One alphabetic character
        - One numeric character
        - One of the following special characters: @, #, $

If the password is hashed or even encrypted, the characters used should not make any difference, as long as they are printable and within the current code page. The fact the they limit this to so few characters strongly indicates that the passwords might be stored in plaintext.

* When changing a password, the new password must not contain more than
  three consecutive characters from the previous password.

This can be compared at the point where passwords are changed, so it is not a strong indicator either way.

This is off topic, but the following policies are misguided and obsolete attempts at making stronger passwords. A higher minimum password length would eliminate the need for all of these.

* Passwords must be updated every 90 days.
* Passwords must contain a non-numeric in the first and last positions.
* Passwords may not contain two consecutive identical characters.
* Passwords may not contain a dictionary word or proper noun.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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