870

I have always wondered why so many websites have very firm restrictions on password length (exactly 8 characters, up to 8 characters, etc). These tend to be banks or other sites where I actually care about their security.

I understand most people will pick short passwords like "password" and "123456" but are there technical reasons to force this? Using an application like 1Password, almost all my passwords are something like fx9@#^L;UyC4@mE3<P]uzt or other randomly generated long strings of unlikely to guess things.

  • Are there specific reasons why websites enforce strict bounds on password lengths (more like 8 or 10, I understand why 100000000 might be a problem...)?
darkAsPitch
  • 613
  • 5
  • 9
enderland
  • 8,011
  • 3
  • 13
  • 14
  • 94
    I must add that a safe password can also be "correct horse battery staple". There is no reason for this and I can only tell you to contact the sites that still enforce this rule. – HTDutchy Mar 31 '13 at 00:38
  • 46
    @s4uadmin No, "correcthorsebatterystaple" is not safe because it is so wide-known and will probably exist in a dictionary attack. Also, tried using this password on DropBox? – Alvin Wong Mar 31 '13 at 03:47
  • 93
    @AlvinWong I believe s4uadmin provided a well-known example, not the suggestion that somebody actually select "correct horse battery staple" as their own literal password. – Jeff Ferland Mar 31 '13 at 07:23
  • 2
    @JeffFerland Yeah, my comment responsed to s4uadmin *literally* while you responsed *figuratively*. I myself *do* use a long password, not "correcthorsebatterystaple" though... – Alvin Wong Mar 31 '13 at 07:35
  • @s4uadmin: Never heard of a dictionary attack, huh? – user541686 Mar 31 '13 at 16:37
  • 79
    @AlvinWong , from Dropbox's javascript source code, this is an eastern egg: `if (pwd == 'correcthorsebatterystaple' || pwd == 'Tr0ub4dour&3' || pwd == 'Tr0ub4dor&3') { // easteregg [...]` – Francisco Presencia Mar 31 '13 at 19:54
  • 3
    Mehrdad, a dictionary attack will not work here. Unless your dictionary has words like Correcthorsebatterystaple – Rory Alsop Mar 31 '13 at 22:53
  • 57
    Not forgetting that hackers now have 'correct horse battery staple' as the *first* entry on their brute force lists :) – Ryan Apr 01 '13 at 06:28
  • 1
    I don't mean to say I endorse this idea, but I have been asked to use a password that is easy to remember because writing it down is a security risk. This could be a technical / human reason for keeping them short. I disagree because by the time someone has their hands on your written password or on your text document where you might have saved it, then your security measures have already failed. – TecBrat Apr 01 '13 at 13:21
  • 7
    I asked one such institution, which has a short maximum password length, about this a year ago. Their response to me: "When assessing this with our risk management, it was determined that a 10 character maximum password would be sufficient." – Matt Apr 01 '13 at 14:22
  • 2
    In a similar vein, why would a site restrict the types of characters that can be used in a password, for example, no punctuation `!@#%".` etc...? – DGibbs Nov 13 '14 at 16:56
  • 20
    My hypothesis: because the password is stored plaintext in a database column type `varchar(10)` – Colonel Panic Nov 27 '15 at 11:47
  • 2
    @Ryan A "brute force list"... So at least they have to try the word list (dictionary) before. :-D – rugk Jul 18 '16 at 19:56
  • 7
    My University has a 16-character maximum password length limit. So when I arrived, I made a 16-character password. Then I tried logging in to their VPS, and it wouldn't work (just died every time, with no error). IT couldn't figure it out for ages. It finally turned out to be because the Cisco router they were using for the VPS only handled up to 12-character password... So my effective upper limit is now 12 characters, if I want to use the VPS. – naught101 May 15 '17 at 01:40
  • Just tried `correcthorsebatterystaple` as a password on Dropbox, and it actually let me sign up. Sad. – Hashim Aziz Apr 08 '19 at 21:12

14 Answers14

1802

Take five chimpanzees. Put them in a big cage. Suspend some bananas from the roof of the cage. Provide the chimpanzees with a stepladder. BUT also add a proximity detector to the bananas, so that when a chimp goes near the banana, water hoses are triggered and the whole cage is thoroughly soaked.

Soon, the chimps learn that the bananas and the stepladder are best ignored.

Now, remove one chimp, and replace it with a fresh one. That chimp knows nothing of the hoses. He sees the banana, notices the stepladder, and because he is a smart primate, he envisions himself stepping on the stepladder to reach the bananas. He then deftly grabs the stepladder... and the four other chimps spring on him and beat him squarely. He soon learns to ignore the stepladder.

Then, remove another chimp and replace it with a fresh one. The scenario occurs again; when he grabs the stepladder, he gets mauled by the four other chimps -- yes, including the previous "fresh" chimp. He has integrated the notion of "thou shallt not touch the stepladder".

Iterate. After some operations, you have five chimps who are ready to punch any chimp who would dare touch the stepladder -- and none of them knows why.

Originally, some developer, somewhere, was working on an old Unix system from the previous century, which used the old DES-based "crypt", actually a password hashing function derived from the DES block cipher. In that hashing function, only the first eight characters of the password are used (and only the low 7 bits of each character, as well). Subsequent characters are ignored. That's the banana.

The Internet is full of chimpanzees.

learnAsWeGo
  • 103
  • 4
Tom Leek
  • 170,038
  • 29
  • 342
  • 480
  • 273
    Oh, and I thought the bears were taking over the internets... – Rory Alsop Mar 30 '13 at 21:54
  • 175
    I like this story also; never let the facts get in the way of a good morality tale: http://skeptics.stackexchange.com/questions/6828/was-the-experiment-with-five-monkeys-a-ladder-a-banana-and-a-water-spray-condu :) – KutuluMike Mar 31 '13 at 00:08
  • 92
    several chimps were harmed during the making of this answer. ( btw, loved the explanation!) – Lorenzo Von Matterhorn Mar 31 '13 at 00:28
  • 87
    Is there any evidence that this is indeed the reason? E.g. has anyone actually asked someone who designed a system with a max password length why they did it that way? – LarsH Mar 31 '13 at 01:56
  • 1
    By the nature of the answer though, the chimpanzee developer should no longer be there. – Journeyman Geek Mar 31 '13 at 04:38
  • Simple solution... let me set my password to whatever I want and just truncate it when I submit it. At least give me the illusion that I am actually choosing my password. Then again you couldn't enforce numbers and weird character rules (good thing in my opinion) – Joe Phillips Mar 31 '13 at 06:52
  • 5
    @Joe that shakes my confidence in the service. Never store my passwords in plain text. Would you be happy to see this? http://thenextweb.com/microsoft/2012/09/21/this-ridiculous-microsoft-longer-accepts-long-passwords-shortens/ – kush Mar 31 '13 at 08:11
  • 3
    @kush truncation upon submission doesn't prevent hashing, though hashing does remove the point of truncating upon submission. – Jeff Ferland Mar 31 '13 at 08:56
  • 15
    .. That's the banana... i would more state that DES-crypt using first 8 characters is the water hose. For your story to be complete you should remove the water hoses, and see who dare to challenge again... – philippe lhardy Mar 31 '13 at 09:47
  • 6
    In other words, modern algorithms implemented properly and there is absolutely no reason for a maximum password limit, other than to make it not completely insane (lets see, say a 1MB long password?). Old Windows NT LANMAN hashes had similar problems with being a maximum of 14 characters which are split into 2x 7 character passwords and hashed without salting. – ewanm89 Mar 31 '13 at 10:02
  • 13
    That's why you should not document the how but the why. And that goes for all rules. – Arkh Mar 31 '13 at 10:24
  • 8
    I'm with @LarsH. Are we sure that all of this can actually be traced back to the crypt function? – Kevin Mar 31 '13 at 20:51
  • 11
    @LarsH & Kevin, Whaat?! Are you actually _thinking_? No no no, you should blindly upvote and agree. It's a bit ironic, you see, you won't get an answer for that, you're expected to behave much like the chimpanzees in the answer itself. – Adi Apr 02 '13 at 09:49
  • 71
    @LarsH: One day I asked a chimp (level 2 technical support for resetting passords, on the phone) why the passwords had to be 6 digits and no more (no letter), generated by the system and sent via untracked paper mail. The answer was "We are a bank and cannot take any security risks". Gave up the banana. – PPC Apr 02 '13 at 15:59
  • 5
    You can even remove the water hoses, and the chimps will still beat up anyone who touches the stepladder. – Joe Z. Apr 02 '13 at 17:13
  • 10
    "That's the banana." What's the banana, the fact that `crypt()` used to ignore any characters after the first 8? That doesn't seem to fit the analogy, where the banana is the reward everyone can see is desirable, but which chimps have learned by tradition that they shouldn't go after. Seems to me, the banana is something like "higher security by allowing longer passwords". The limitations of legacy `crypt()` might be the *waterhose* rather than the banana. (Correspondence between the analogy and reality is of course hypothetical.) – LarsH Apr 02 '13 at 20:35
  • 3
    @PPC Anecdotal evidence FTW!! – Adi Apr 03 '13 at 06:14
  • 5
    How do the chimps get into the tubes though? – Chad Apr 03 '13 at 15:43
  • 24
    OMG, the net is full of chimps. Just for the record, I am currently working on a project to remove 8 character limit on passwords for a client who has over 40,000 users and a lot of applications. Things are not as simple as many of you would like to think. Yes, the crypt() limit is the basic reason for the 8 character limit. Crypt was required to support legacy apps. The 8 char limit made sense when it was originally imposed (CPU, net, I/O speed). – Tim X Apr 04 '13 at 23:38
  • 17
    I have created my account on this site just to upvote your answer. Awesome explanation! You sir, are a true genius!! – MD Sayem Ahmed Apr 05 '13 at 14:47
  • 11
    b..but, i thought my bank restricts me to 8 characters for my protection – Longpoke Jun 10 '14 at 21:51
  • 8
    @LeoKing This is security.stackexchange, so people don't merely stop at 666, they aim for [Strong Primes](https://en.wikipedia.org/wiki/Strong_prime). – binar Apr 24 '15 at 00:05
  • 2
    Something similar to how religion works. Made me smile. Thanks for the amazing analogy. – Sid Jun 22 '16 at 04:05
  • 4
    +1; Last time I heard this explanation, it ended with "This is what we call <>". – utnapistim Mar 10 '17 at 16:28
  • Thank you for providing this genius answer. I love it. – Ctorres Aug 25 '22 at 14:42
241

These restrictions are often put in place for various reasons:

  • Interaction with legacy systems that do not support long passwords.
  • Convention (i.e. "we've always done it that way")
  • Simple naivety or ignorance.

As far as security goes, there is no need to limit password lengths. They should be hashed anyway, using a key derivation function (KDF) such as bcrypt. To help with performance, it might be worth placing a very large limit (e.g. 512 characters) on the password length, to prevent someone sending you a 1MB password and DoS'ing your server for 10 seconds whilst it computes the hash.

Bernardo Sulzbach
  • 131
  • 7
Polynomial
  • 133,763
  • 43
  • 302
  • 380
  • 67
    For what it's worth, good password hashing functions will not be much impacted by password length. With PBKDF2, used with HMAC, the password is the HMAC _key_, so, by application of HMAC, it is first normalized to a value no longer than one internal block (typically 64 bytes). To get 10 seconds of extra CPU work because of a very long password, that password should be about 1.5 GB long, not a mere megabyte. – Thomas Pornin Mar 30 '13 at 21:59
  • 22
    Yup, would probably DoS the bandwidth long before the CPU – makerofthings7 Mar 30 '13 at 22:54
  • There is no hashing function which makes a password like `asdfhjkl` secure. – Kaz Mar 31 '13 at 01:11
  • 11
    @Kaz Nobody said there was. – Polynomial Mar 31 '13 at 01:46
  • 1
    @Kaz What if you salt it? – Joe Phillips Mar 31 '13 at 06:54
  • @Polynomial bcrypt would only have the password length have any effect on CPU time on the first iteration IIRC and then it's just a single hash of 1MB of data (your server that slow to hash 1MB?). I think bandwidth is a lot more of a problem. – ewanm89 Mar 31 '13 at 10:08
  • 3
    @JoePhilllips: Salting doesn't improve the security of a password inherently, it only protects against offline attacks. Even then, a password like "asdfhjkl", being only eight characters, is quite possible to break so long as you know the salt. Salting doesn't help an individual password much at all, but it protects the whole database enormously by making it impossible to check a single set of passwords in one iteration--you need a check for every single user. The individual passwords are still weak and susceptible to being cracked, but only if they're important enough to bother targeting. – Phoshi Mar 31 '13 at 12:30
  • 3
    with the talks of passwords in Mega and Giga ranges, why don't just use Files as passwords? I believe it is used in some places (truecrypt also does it) – kumarharsh Mar 31 '13 at 12:32
  • 22
    Each character in a password phrase contributes some entropy to the hash. But if the hash is ultimately some N-bit string, then it's superflous if the password phrase has much more than N bits of entropy. Let's make a ridiculous example. Say the hash is 16 bits wide and you use a one megabyte password. The cracker may well find some very short character combination which produces the same hash, and therefore serves in place of your one megabyte password. There is definitely diminishing returns beyond some password length with respect to the strength of the hashing function. – Kaz Mar 31 '13 at 18:12
  • 1
    @Kaz: Your statement "Each character in a password phrase contributes some entropy to the hash" is not always true: because of dictionary attacks, "correct horse battery stapl" is a (less bad) password than if you add the final E – PPC Apr 02 '13 at 16:03
  • 9
    @PPC Password quality != password entropy. Entropy is a purely statistical measure. – Polynomial Apr 02 '13 at 18:53
  • 2
    What - no chimps?! – megaSteve4 Apr 02 '13 at 19:20
  • 2
    You can add "Our customers are too stupid to remember long passwords" to your list of reasons. Not that they are stupid, just perceived that way. – pgs Apr 04 '13 at 01:04
  • 6
    "As far as security goes, there is no need to limit password lengths. They should be hashed anyway, using a KDF such as bcrypt." Note that bcrypt has a 72-character upper bound; it simply ignores anything beyond that. – Xiong Chiamiov Jul 12 '13 at 22:10
  • 2
    @XiongChiamiov And that in itself seems like a fairly good reason to limit passwords to 72 characters if you're using bcrypt by itself. You don't want to let users enter a long password and think they can rely on the entropy in the part that will be ignored. – bdsl Sep 07 '20 at 09:30
88
  1. If they store it in plaintext or encrypted plaintext, then that's probably the maximum value that can be stored in the DB. On the other hand one should get as far as possible from these sites
  2. To avoid DOS attacks. This is usually if they have a very high limit, like 512 or 1024 bytes
  3. To comply with regulations that are actually made by people not knowing anything about IT security
  4. For legacy reasons, as Tom Leek has pointed out

Btw. here is a (historical) list of high ranking sites having maximum password lengths:

http://web.archive.org/web/20130907182806/https://defuse.ca/password-policy-hall-of-shame.htm

Josh
  • 103
  • 4
SztupY
  • 1,021
  • 6
  • 11
  • To build on this: the longer the password, the more expensive it is to hash. This is a horrible argument since hashing a 128 chars with [PBKDF2](https://en.wikipedia.org/wiki/PBKDF2) should only have a negligible cost over hashing 8 chars, nullifying any [DoS](https://en.wikipedia.org/wiki/Denial_of_service_attack) risk (from just pw length). Worse still would be to store the password in plain text, though that might raise storage concerns. I'm all for limiting password length, but I see no reason for that limit to be less than a hundred. – Adam Katz Feb 25 '16 at 22:55
  • As an aside, it's worth pointing out that all passwords are of limited length. Even if the form allows unlimited characters, the web server is almost certainly set up with a maximum POST payload size. Even if the web server isn't configured to reject requests, eventually your browser and/or PC will run out of memory to store the password. Sure, most normal people won't try to enter mega-long passwords, but--especially for a high value target like a bank--a developer worth his salt ought to be able to tell you what that limit is and what happens when it gets hit. – GrandOpener Dec 23 '17 at 06:24
74

I asked this question at Bol.com, one of the biggest webshops in the Netherlands. Their response was to prevent being flooded with support emails about forgotten passwords. They then curiously ignored my inquiry about the password reset feature which just emails you a reset link when you have forgotten your password.

I've concluded that it's most likely a decision from the management team. Alternatively it might be that they don't hash passwords and use this to prevent their database from being flooded (even though you can have a longer username, so this seems unlikely). They also did not respond to a question about whether they hash passwords (you'd think if everything is alright there would be no reason not to reply).

Luc
  • 32,378
  • 8
  • 75
  • 137
43

I would cite an attempt to reduce customer service related issues.

The larger and more complex passwords are, the higher the likelihood for the customer to enter an invalid password, get locked out and then contact customer service tying up that individual's time.

It is amazing how many people are unable to accurately type a normal weak password, let alone a password that is a few characters longer or had to have an extra character or 2 injected for complexity.

Possibly OT but, lengthy passwords are not necessarily a guaranteed true security measure since passwords are straight-out stolen on a fairly common basis nowadays.

Failed login attempts and Tracking geo-distance from normal login usage is far more accurate metric. if an IP belonging to a known high hacking/attack profile country logs into an American bank and that login has never been used from that location before.....

A lot of high profile places such as SF/banks generally have a very low failed login attempts count with resulting system-wide lockdowns. Some such as SF go as far as doing individual IP allocation, which means you can't log in from a new IP address without authorizing it.

Matthew
  • 27,263
  • 7
  • 89
  • 101
MDR
  • 539
  • 3
  • 2
  • 11
    This may be the thinking, but IMHO this line of thinking is deeply flawed. Why take way the option of using long, secure passwords because some users prefer short ones? A password reset doesn't usually involve customer service intervention. Also, if passwords *can* be "straight-out stolen" (e.g. they are stored in plain text) then you are doing it completely wrong. – Anthony Mar 31 '13 at 16:42
  • 6
    From my experience, customers not typing/remembering their password correctly does tie up customer support via e-mail and phone. By Passwords being stolen, I am referring to the millions of zombified computers with trojans/key listeners and the numerous phishing attempts. Symantec posted # a few year back on the # of passwords stolen. – MDR Mar 31 '13 at 20:54
  • 2
    @MDR: If they are not allowed to use longer/stronger passwords, their passwords are easily cracked and again they will come to customer support. And, why should the users come to customer support if they **forget** their password, **if** your web service offers the **forgot my password** feature. – Sai Manoj Kumar Yadlapati Apr 01 '13 at 01:03
  • 7
    Good answers, but in order to please the constituency of "users who will invent long passwords even when they can have short ones, then forget them and call up instead of using the password reset", you shut out the "users who use long passwords in a password manager". Pandering to fools an endless, pointless task, so it's better to educate the forgetful group and enable the sensible group. This is IMHO why small password length limits are a deeply flawed idea. – Anthony Apr 01 '13 at 13:04
  • 4
    @SaiManojKumarYadlapati: if a password can be brute forced there is a flaw in your system. Further more if a password can be stolen through keylogger/zombified computer, which happens on a very regular basis, and access to "critical" information is gained, this also represents a flaw in the system. – MDR Apr 01 '13 at 17:47
  • 4
    @Anthony: You make a good, but what I believe to be theoretical point. I know our company staffs several individuals for "customer relations". I know that the top 2 reasons for customers to call in or email us, that are not related to business specific issues, are all login related. The #1 reason is "they were signed up with the wrong email address" The #2 reason is they can't type their password/don't remember their password. And while I agree 100% with what you are saying my professional experience (at no scale of a large bank) shows that this issue can cost a business owner money. – MDR Apr 01 '13 at 17:52
  • @MDR: System wide lockdowns and individual IP allocation etc. are not features but punishments for genuine users when some one tries to crack their account. Sorry that I lost internet connection before completing my comment previously. – Sai Manoj Kumar Yadlapati Apr 02 '13 at 03:19
  • 2
    Meh. "passwords can't be done securely because users are too stupid" is a council of despair. Shocking to see it at a bank. – Anthony Apr 03 '13 at 07:11
  • 2
    One more question: Supporting users costs money. We know this. But do you know for sure that your costs will go up if you allow longer passwords, or is it just a superstition? What is the evidence? What you are doing is lowering your day-to-day costs (maybe) but also raising the odds that could lose big at the hacker lottery if your password db is penetrated. You have a saving (maybe) but need to weigh it against the other cost, or it is a false economy. – Anthony Apr 05 '13 at 19:48
  • 1
    I've addressed all of these issues in the inline comments. – MDR Apr 12 '13 at 02:46
  • 1
    Surely there'd be no need to reduce the maximum size, though. Just don't set a minimum. The kinds of people who use longer passwords would presumably be able to remember them better (eg, using a password manager or some kind of pattern). I imagine the people with shorter passwords have shorter passwords for the purpose of remembering them better (which does make them very vulnerable to brute force attacks, though). – Kat Dec 18 '14 at 17:47
  • 1
    I don't see how forcing users to not use the memorable password they thought up is going to make passwords easier to remember. – Jon Hanna Apr 01 '15 at 09:05
28

"Interaction with legacy systems that do not support long passwords." as mentioned above is the reason for one company I worked at to enforce a maximum password length.

As a variation on the trope "a group moves as fast as its slowest member" the use of multiple systems which all users had to have access to using the same login credentials meant that any restriction by one of those systems would then have to be applied to all accounts.

So if one application a didn't like ^ then all passwords for all systems couldn't have a ^. If one program didn't like passwords > 8 chars then all accounts had to have passwords < 9 chars. So in a complex environment like BigCo where I worked this might involve a dozen or two dozen different pieces of software; the LCD was what everyone got.

They used IE6 as well.

user2228243
  • 381
  • 2
  • 3
21

A password length limit is reasonable as long as that limit still allows for strong passphrases; e.g., the limit isn't less than 64 characters. A loud limit when setting the password is significantly better than silently truncating the password.

If the application ultimately stores the password with 128 bit (hopefully salted and key-stretched) hash, there's no gain in allowing passwords longer than ~64 characters. E.g., with a diceware passphrase with 5 character words with spaces between them, a 64 character passphrase allows 10 words which would have an entropy of more than 128 bits.

A developer potentially could be worried about SQL injection or buffer overflow attacks injected via the password field -- granted you should use the standard methods to prevent these attacks: always use bound parameters with SQL (versus string manipulation to construct queries) and always properly bounds check your strings (possibly by using a safe programming languages or safe libraries with built in protections). You need to be worried about these attacks on all user input; this is not unique to the password field so the protection gained by a maximum password size is likely negligible.

There could be tangential reasons for limits as well. A bank that gives users ATM cards with a PIN (personal identification number) may choose to force users to use PINs between 4-10 digits in length. Allowing a user to set and use a 50 digit PIN likely would have little security gain in practice over say a 8 digit PIN - when an attacker needs both a user's ATM card (that hasn't been called in as stolen), use a monitored ATM, and gets locked out after 4 wrong attempts. A 50 digit PIN, could be more expensive in human costs for your bank, as it would be forgotten/input incorrectly more frequently - maybe trigger an employee to investigate (e.g., check the ATM video and compare with previous successful transactions) or have an employee walk the customer through some necessarily lengthy password reset mechanism (e.g., the reset mechanism has to be costly so it is not the weakest link). This whole process could lead to poor customer user experience which the bank wants to avoid.

dr jimbob
  • 38,936
  • 8
  • 92
  • 162
20

Another possibility I'd like to address that hasn't already is that passwords are sometimes limited by the length of the field that is used to save them, when saved in plain-text. If your field is a VARCHAR(32), then you can save 32 characters at most.

However, this means something even worse - that the password is saved in plain-text. This is why we accept these sorts of offenses as (lightweight) evidence at plaintextoffenders.com.

Omer van Kloeten
  • 341
  • 1
  • 6
  • 16
    This. If they hashed passwords, they'd all be the same length. Therefore, if a site says "max length X characters", I assume they're either 1) storing plaintext or 2) using a pointless validation. #1 seems more likely. – Nathan Long Apr 02 '13 at 13:42
  • 1
    Is showing the password in the email proof that they're storing it in plain-text? Couldn't they hash and store it after they send the email? Not saying that they are of course, and I think sending the password in an email is probably insecure for another reason, but it doesn't seem like definitive proof at least. – Vadoff Mar 11 '17 at 00:08
  • 1
    Email being an insecure medium by definition, this is ill-advised. Not to mention that people may never delete the email and anyone with access to their mailbox can just look up the word "password" and have instant access to their account. – Omer van Kloeten Mar 11 '17 at 13:59
10

As others have already noted, the big reason that comes up for 8 characters or less is dealing with older systems that don't support anything longer than that.

Then there is the general good idea of placing some upper bound on what is reasonable. Lets say that is 500 characters. It wouldn't be unreasonable to think anyone providing more than 500 characters for a password might be up to no good.

But even if you are using a currently recommended password hashing system there are still limits. Bcrypt, which is widely used and from what I can tell generally considered a good/strong option for hashing passwords, only deals with the first 72 characters. Anything beyond 72 characters is thrown away. If my password is 100 characters long and yours is 150, if they start with the same 72 characters bcrypt will consider them the same.

Given that specific limit in bcrypt, if you are using bcrypt you may want to enforce a 72 character limit to make sure that all unique passwords are actually considered unique by your authentication system.

Matthew
  • 27,263
  • 7
  • 89
  • 101
Joseph Scott
  • 101
  • 2
  • 1
    `to make sure that all unique passwords are actually considered unique by your authentication system.` sorry, but you cannot. That's why we use cryptographically strong hashes. – ch3ka Nov 04 '14 at 01:11
  • 2
    I do not think that there is any reason to enforce a rule that every user should have a unique password. Two different users can very well have the same password. The only disadvantage of bcrypt throwing away everything beyond the first 72 characters is that anyone trying to crack a password only has to try strings of maximum length = 72, i.e. even if I set a password 100 characters long, the extra 28 characters do not give me any additional security. – Ajoy Bhatia Nov 28 '17 at 00:19
  • The problem with throwing away characters is that a dozen users could use the same 80 characters, followed by more characters specific to the user - so everyone has the same password, and they probably all know each other. – gnasher729 Dec 30 '20 at 21:53
8

Many sites think it is not needed to have long password since there is brute-force protection (like limiting number of login attempts per IP), which makes very little difference to have long vs short passwords, in both cases it would take years to try all possible combinations.

The one recomndation would be to use random characters (!@#$%^&*-_=+/\'") a long with a-z A-Z 0-9.

sharp12345
  • 2,009
  • 3
  • 14
  • 23
  • 1
    Depending on RDBMS, some of these additional characters could be used for SQL injections and would hopefully end up being omitted during input parameters sanitization, so I wouldn't really recommend their use without mentioning that the permitted characters can vary, and should be used with caution. – TildalWave Apr 02 '13 at 19:34
6

I'd say there are three main reasons:

  1. Legacy systems not supporting special characters
  2. The desire to keep support overhead down, and use of the system up, by keeping users' passwords actually rememberable. In other words, if you let users make and use paswords they can't remember, they will, and as a result they'll either annoy you about it or stop using the site due to the hassle
  3. Developers not wanting to have to worry about parsing special characters from untrusted users, which could potentially be dangerous

In the past the top reason was probably the lack of ability to support the passwords (#1), and today it's probably the lack of desire to support them--mostly from #2, but partially from #3.

Daniel Miessler
  • 605
  • 4
  • 3
6

Jet another reason is UI design and overall user experience: It's not obvious to many users what is going on when the visible length of the input field is reached as each character is shown as a star or big dot. This can confuse users and cause negative emotions (less likely to buy something, to come back or to recommend the site to a friend). Technical solutions are possible but it is just easier to limit the length, e.g. to 20 characters, so that the cursor never reaches the end of the input field.

Joachim Wagner
  • 171
  • 1
  • 5
3

With additional restrictions (generally, only numbers accepted), it can also be motivated by the fact it allows (or may allow, if some day the need would arise) entering the password through some interface with limited capacities...

That's why many banks have set such restrictions for web access passwords, to allow access through legacy systems which only have numerical keypads (ATMs, phones...)

Christophe Franco
  • 39
  • 1
1

All bank sites I know have a pin like system that locks your account after 3 failed password attempts. This means that long passwords would be counterproductive because they are easier to mistype or forget, especially because you can't see them (and if you could see them security would be even worse).

If you take eg. a pin system for smartphones where you type in 4 numbers, the chances of guessing it right within 3 tries is 0.03%. With 8 digits, the chances of guessing it right (if the sequence is randomly generated and not chosen stupidly) become so small, that if you would try to guess 7 billion peoples passwords, you would only on average guess 209 peoples passwords right. If characters and/or special characters are allowed the chances of guessing get even smaller, multiplied by a factor of 1^-4 or 1^-6 respectively.

Even if users are allowed to choose passwords and would choose them in a semi-predictive manner, within 3 tries it's impossible to crack any particular account and your average wouldn't improve too much, even if you would have a lot of data, like all birthdays in a family and the names of everyone in the family and every friend of the person. And you are also unlikely to have a reliable and comprehensive list of that kind for a large population.

HopefullyHelpful
  • 1,254
  • 1
  • 12
  • 17