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".

George Alfaro
  • 357
  • 2
  • 6
  • 33
    There are still some banks in my country that require passwords *no longer than 12 characters*. Let's start with those :P – Mike Ounsworth Jan 09 '21 at 15:32
  • 22
    Note to self: don't open a bank account wherever Mike lives – George Alfaro Jan 09 '21 at 15:49
  • 1
    A good read, if you've missed it: https://security.stackexchange.com/q/33470/90657 – multithr3at3d Jan 09 '21 at 16:03
  • 3
    Almost a duplicate of [Passphrase vs. password entropy](https://security.stackexchange.com/q/178015/3365) – gowenfawr Jan 09 '21 at 16:07
  • 1
    Does this answer your question? [Passphrase vs. password entropy](https://security.stackexchange.com/questions/178015/passphrase-vs-password-entropy) – kelalaka Jan 09 '21 at 17:41
  • 4
    @GeorgeAlfaro In the interest of naming&shaming, it was [this Tim Horton's credit card through the Canadian bank CIBC](https://www.cibc.com/ca/doubledoublecard/index.html). I refused to create an online account with those password rules, and forced them to send me everything by paper mail. – Mike Ounsworth Jan 09 '21 at 23:27
  • 3
    Does this answer your question? [What technical reasons are there to have low maximum password lengths?](https://security.stackexchange.com/questions/33470/what-technical-reasons-are-there-to-have-low-maximum-password-lengths) – IMSoP Jan 10 '21 at 14:12
  • A few years ago I was setting up online banking for a business account at a local bank. The required me to specify two separate passwords, each subject to a string of password requirements. And each _exactly_ 8 characters long. Which in combination with the overly stringent rules meant that the dictionary of allowable passwords was greatly reduced. I used a different bank – Mohirl Jan 11 '21 at 13:40

2 Answers2

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.

  • 1
    An excellent, [John Frum](https://en.wikipedia.org/wiki/John_Frum) ;-) – Mawg says reinstate Monica Jan 10 '21 at 09: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 Jan 10 '21 at 14:12
  • Diceware for the big win – Joshua Jan 10 '21 at 19:11
  • 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 Jan 10 '21 at 19:12
  • @Joshua That would be completely inappropriate for an implementation of bcrypt itself, as opposed to a wrapper that uses bcrypt internally. At the low level, there are only two options: truncate, or raise an error; and raising an error in a safe and portable way isn't always trivial either. – IMSoP Jan 10 '21 at 21:05
  • [Obligatory xkcd](https://xkcd.com/936/) – SuperStormer Jan 10 '21 at 21:47
  • @Joshua Note also that mixing hash functions in arbitrary ways means you're basically inventing your own algorithm; that may or may not lead to weaknesses (it sounds logically reasonable, but do you have the maths knowledge to prove it?) and certainly makes your wrapper non-portable (you couldn't store the hash with a standard prefix like `$2$` and have it processed by other tools any more). You could start a movement to make the combination standard, but at that point you could just switch to a newer hash function, like one of the Argon variants. – IMSoP Jan 10 '21 at 21:59
  • 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. –  Jan 10 '21 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 Jan 10 '21 at 23:35
  • horse: that's a battery staple me: correct! – qiu Jan 11 '21 at 03:28
  • 1
    @IMSoP bcrypt isn't a hash function, it's a key derivation function. A hash function like MD5 or SHA-1 can take arbitrarily long input. –  Jan 11 '21 at 11:46
  • @MechMK1 [The paper which introduced it](https://www.usenix.org/legacy/events/usenix99/provos/provos_html/node1.html) disagrees: "Section 5 introduces the variable-cost bcrypt password hashing function". It is an algorithm specifically designed for directly storing the derived hash, not using it as a key in some other operation (unlike e.g. PBKDF2). If the site allowed, I would edit "some modern hashing algorithms" to "some modern password hashing algorithms", but I remain unconvinced that "accepts arbitrary length input" is a necessary condition for the label "hashing function". – IMSoP Jan 11 '21 at 12:02
  • @IMSoP That's actually an interesting point of debate. I'll ask on [crypto.se] –  Jan 11 '21 at 13:41
  • While I think that "cargo cult" is useful and descriptive term, I am not sure about the evidence for the original cargo cults. – Carsten S Jan 11 '21 at 13:55
  • @CarstenS Given that the origins of real-life cargo cults are only tangentially related to the question and only serve to illustrate the concept of imitation without understanding, I did want to keep it as brief as possible. Real life cargo cults are of course a much wider topic. I decided to leave it up to the reader to go down this rabbit hole. –  Jan 11 '21 at 15:10
  • I just had a brief glance at the Wikipedia page, and it seems that something like described in the answer actually occurred. I had been concerned that repeating the origin of the term in an uncritical way might lead to stereotyping the involved cultures. Seems ok, though. – Carsten S Jan 11 '21 at 16:01
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.)

gowenfawr
  • 72,355
  • 17
  • 162
  • 199
  • 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 Jan 10 '21 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 Jan 10 '21 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 Jan 10 '21 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 Jan 10 '21 at 16:34