23

I do not quite understand why it is common practice to require a difficult to remember password with alphanumeric and special character requirements, while also having an upper limit of 32 characters. Wouldn't it be easier for everyone to remember the password if the lower character requirement was 32 and there was no requirement for special characters, numbers, and capitalization?

The fact that dictionary attacks exist means that the different character requirements are mostly useless anyways; many people just prepend or append a number or special character to a short password, or use substitutions such as "leet speak".

8

2 Answers 2

49

Cargo Cult

It is no secret that a lot of people who are tasked to design security for systems know very little about information security and are ill equipped for the task. As a source for that claim, I will take years of personal experience as pentester, and the absolute bewilderment for the things I have seen people develop over the years. Not because the developers are bad developers - on the contrary - but because information security has different requirements than normal software development. It's like asking a painter to paint a blueprint of a house.

As such, developers who lack the understanding of what is required of a system that handles authentication and authorization often fall back to the most primitive form of learning: Imitation. We see other people do things, and without understanding why these things are done, we imitate them. "After all, it's done that way for a reason." This process has a name: Cargo Cult Programming.

Originally, cargo cults were cults of tribespeople, who saw modern soldiers receive air cargo with supplies. They thought that this air cargo was a gift from a divine entity, and that the activities of the soldiers were a ritual to summon said entity to bring gifts. As a result, after the soldiers had left, the tribespeople began to immitate their activities to the best of their understanding, making makeshift uniforms and marching up and down, in hopes that this would summon some divine favour.

Cargo Cult Programming is a similar process, in which some developer does something in a particular way, due to some circumstance. The other programmers then blindly implement their solution in the same way, without understanding why the solution was implemented in said way, and what problem it aimed to solve.

About Password Lengths

For example, "DES crypt" would only allow for a maximum of 8 bytes for password length due to export restrictions - which was primarily a legal problem. So any system that used DES crypt would require a maximum character length of 8. Someone who saw this implemented may not know the reason why 8 was chosen for this, and may blindly copy this implementation, possibly not even using DES crypt in the background. So they are not limited by a maximum password length of 8, yet still arbitrarily impose it, simply because they have seen someone else do the same thing.

Misinformation

As for why companies require short, complex passwords rather than long, easy-to-remember phrases? That one is unfortunately on us. For a very long time, security experts tried to get people to make "better" passwords. And in a sense, it's true: <3BZg2Ck is a better password than ILoveNYC.

However, security experts are not infallible and we too learn painful lessons, such as AviD's Rule of Usability:

Security at the expense of usability comes at the expense of security.

Short, highly complex passwords are really difficult to remember for people, and people started to use "systems to make good passwords", like tGbHuJm! (I'll leave it up to the reader to figure out why this is a bad password). Experts changed their advice, instead advocating for long passphrases, like It's monday again and the coffee still tastes like wet socks, but "common wisdom" is difficult to change. When people hear that passphrases should be complex, they see the half-truth how a complex password is better than a simple one, and urge their users to make passwords as complex as possible.

Recommendation

In a system that requires passwords, users should be urged to use a password manager to create a safe, new password. A sufficiently long, randomly generated password will always beat any long, easy-to-remember passphrase, and it's more easily usable too if the browser automatically fills it in for the user.

If that is not a possibility, users should be urged to make long passphrases. Phrases are generally easier to remember for people, and length is king when it comes to strength. However, users can stick to phrases that are publicly known and not secure at all, such as In the beginning God created the heaven and the earth. - any automated check will tell you that this is an amazing password, but my wordlist on my cracking machine will beg to differ. As such, you can try to generate a memorable sentence for the user, or just believe that they know what they are doing.

Finally, after a user has entered a passphrase, it is recommended to check that passphrase with a database like Have I Been Pwned? to ensure that password isn't already known to be insecure.

16
  • 1
    An excellent, John Frum ;-)
    – Mawg
    Commented Jan 10, 2021 at 9:19
  • 4
    Since it's often overlooked, I would like to point out that some modern hashing algorithms do still have a maximum input length (although much longer than 8 characters!). Most notably, bcrypt has a maximum input of 72 bytes, and many implementations will simply truncate the password at that length.
    – IMSoP
    Commented Jan 10, 2021 at 14:12
  • 2
    @IMSoP: If I found one of those implementations I'd probably file a bug report that reads "Don't trucante passwords. If it's too long, run it through a sha-series has first." Note that even sha1 is plenty here. Nobody's going to be using a preimage attack on a password.
    – Joshua
    Commented Jan 10, 2021 at 19:12
  • 2
    @IMSoP No, a hashing algorithm takes input of arbitrary length. bcrypt sspecifically imposes a 72 character limit. Neither scrypt, nor PBKDF2 impose a character limit. Argon2 imposes 2^32-1 bytes as character limit, which is practically unlimited.
    – user163495
    Commented Jan 10, 2021 at 22:19
  • 1
    @MechMK1 I'm not sure what you're saying "no" to; I said that some hashing algorithms have a maximum input length, and gave bcrypt as an example. You don't seem to disagree that bcrypt has a maximum length, so are you saying bcrypt isn't a hashing algorithm, or ... something else?
    – IMSoP
    Commented Jan 10, 2021 at 23:35
4

I do not quite understand how it is common policy in industries to require a difficult to remember password with different alphanumeric and special characters that also has an upper limit of 32 characters. Wouldn't it be easier for everyone to remember the password if the lower character requirement was 32 and there was no requirement for special characters/numbers/capitalization.

Translation: Why are limited-length passwords favored over lengthy passphrases?

Two reasons:

Software - Companies may be using database or mainframe backends that limit the length of permissible passwords. These may be companies that purchase their software and do not have the resources or the control required to alter it. This sort of situation is especially prevalent in the banking/financial world.

Tradition - For many years "password complexity" has been advertised as the ideal goal. Even recent NIST guidance is biased to discuss passwords instead of passphrases, while openly acknowledging that humans pick poor passwords even with complexity requirements.

NIST guidance has also shifted to encourage use of TOTP or other multifactor solutions, suggesting that passphrases are not considered a sufficient leap beyond passwords on their own. (Incidentally, NIST agrees with you that secret lengths of at least 64 characters should be permitted, to accommodate passphrases.)

4
  • 2
    "NIST agrees with you that secret lengths up to 64 characters should be permitted" -- That wording makes it seem like lengths beyond 64 chars shouldn't be permitted. The actual wording from NIST is "Allow at least 64 characters in length to support the use of passphrases. Encourage users to make memorized secrets as lengthy as they want, using any characters they like (including spaces), thus aiding memorization."
    – JoL
    Commented Jan 10, 2021 at 12:35
  • The Software part of your answer is circular so doesn't fully answer the question. Why do those backend systems limit the length of permissible passwords?
    – thelem
    Commented Jan 10, 2021 at 16:18
  • 2
    @thelem part of the point is that it is a circular problem. As for why, these legacy systems may implement shorter passwords 1) because of technology (e.g., consider des-hashed Unix passwords with their innate limit of 8 characters, which lived long past the introduction of better schemes in the 90s) or 2) because of implementation (when initially implemented, 8 character passwords were considered sufficient, and that software has lived on for many years without that design decision being revisited. Mainframe programs in particular are resistant to change.)
    – gowenfawr
    Commented Jan 10, 2021 at 16:29
  • @JoL I fear that when NIST says "at least X" the world implements exactly X. That being said, you make a valid point and I've updated the wording in the answer to match NIST's wording.
    – gowenfawr
    Commented Jan 10, 2021 at 16:34

Not the answer you're looking for? Browse other questions tagged .