Why impose limits on passwords?

Last night, I was trying to log into one of my accounts, but I could not manage to remember my password. I clicked on the “forgot password” link, got an email with a link to reset my password, where I attempted to create a new password.

Except, I kept getting error messages: invalid character or too long. For almost ten years, I have been using special characters in my passwords (ever since I had to create a password that required three of four types of characters: lower case alpha, upper case alpha, number, special character, but would not accept any password that had less than four of four types). And I have come to realize that longer passwords are harder to crack.

I finally clicked the link that told what made up an acceptable password – upper/lower case letters, numerals, and ‘-’ and ‘_’. No spaces, no dollar signs, not even an exclamation point!

With all of the companies in the news for having their customer databases hacked, why would any company want to limit their customer’s ability to create ANY password they want by reducing the number of characters allowed in a password or its length? That is forcing your customer (me) to use what your customer (me) believes is a less secure alternative?

I would guess one of two things. 1) Limitations in whatever database the company is using, or 2) they feel their internal security is good enough.

There’s always going to be some hypothetical upper limit on password length, but it shouldn’t be anything a reasonable password would hit. Some people do everything they can to make every database field as small as possible, but I think that fell out of favor when everyone realized that hard drives were crazy cheap.

Special characters might be excluded to prevent SQL injection or something, and if you’re worried about that sort of thing then a whitelist of allowed characters is safer than trying to blacklist the bad ones, but it’s 2016 and it seems ludicrous that anyone would still be dealing with it via input restrictions. I can only assume the site you’re using is ancient and has never been updated.

There really shouldn’t be any character limits on a password. When I see a system having an upper limit to the length or prohibiting certain characters, it suggests to me that the system is not using a current method of hashing their passwords. Maybe they’re using a non-standard hashing process, or maybe (shudder) they’re transmitting or storing passwords in clear text. Either way, it’s probably a sign that their attention to security is not what it should be.

Every bit of data you enter into a computer has limits. The limits are chosen by meatbags.

Yeah, there is going to be some hypothetical upper limit on input length as steronz notes. But since current hashing algorithms can hash an entire hard drive’s worth of data, there should be no real practical limit for password length.

You don’t think there’s some kind of practical performance limitation on verifying a multi-gigabyte password?

A multi-gigabyte password would be longer than every book in the Library of Congress put together. We’re asking for the ability to write at most a sentence-long password. 12-characters is not a reasonable limit. I understand there has to be some limit, but there’s no reason it can’t be 128 or 256 characters rather than 12.

And for that matter, there doesn’t have to be a hard limit at all. Let people make their password as long as they want, and just upgrade your hard drives when you can no longer store new passwords. Like every other digital document. Nobody forces your text files to be 500 words or less, despite the fact that it is technically possible to fill up your hard drive with a single text file.

Probably some arbitrary limit that some IT guy picked (or, more likely, someone was wandering through a menu or GUI and checked or unchecked a box on the parameter without thinking through what it was for). As others have said, there should be no issue with the length, and you SHOULD use special characters in your password (i.e. a ‘strong’ password) to make it more difficult to hack. You should call your customer rep and if that is indeed their policy then consider changing to another vendor (and tell them that), unless they accept all liability for getting hacked with weak password policies.

There is no good reason for limiting a password in the ways described in the OP. The system was probably designed by someone not familiar with password best-practices.

Can I get a cite on that? Thisarticle from 2012 indicates that the size of the Library of Congress’ was 15TB. This article (which includes digital collections) ballparks it somewhere between 235 terabytes and 3 petabytes!

Even if you want to back-of-the envelope it, the first thing you get when you Google “How many books in the library of Congress” is this:

“On January 30, 1815, Congress approved the purchase of Thomas Jefferson’s personal library of 6,487 books for $23,950. Statistics. The Library of Congress is the largest library in the world, with more than 160 million items on approximately 838 miles of bookshelves.”

So if you have 160 million items, you’d have to be able to represent each one with less than 16 bytes in order to avoid taking up “multi-gigabytes” of storage. So I call shenanigans.

Right. For all practical purposes, there should be no upper limit on password length. No one is going to pick a password so incredibly long that they hit a performance limit. If you’re really worried about someone trying to input “Moby Dick” as their password, put a limit of 1000 characters or something. Not 12.

ETA: and the length of the password doesn’t affect the length of the resulting hash. The hash value is fixed length (unless you’re using an uncommon hashing algorithm)

No, because I’m apparently wrong. I was going off a vague memory of something I read once, which could have been written a century ago. Your numbers are certainly more recent and more precise, thank you.

But the point is that no one will be typing multiple gigabytes of text into the password field. Replace “Library of Congress” with “a set of encyclopedias” and the point doesn’t change.

An unlimited length password would allow hackers to quickly fill a server’s hard drive and shut the system down.

But you could allow for passwords in the thousands of bytes range pretty easily. And I suspect that there’s very little value in allowing passwords longer than 50-100 characters.

Right. I’m just trying to write a sentence. I think they’re more memorable and harder to crack, assuming it isn’t something famous like “To be, or not to be; that is the question”. I think a passphrase like “I love all 13 dogs I’ve ever owned – especially Rover!” would be easier to remember than “correcthorsebatterystaple” and even harder to crack. Let alone compared to a standard “complex” password like “P@$$W0rd!!”

Nope. Servers don’t store the password (or, at least, they really really REALLY shouldn’t). Servers store the hash value of a password. Hashing is a function that takes variable-length input and from that generates fixed length (usually) output. Here’s the Wikion hash functions.

Here is a simplified example/explanation (I’m leaving out salting and some other stuff just to be brief)

Let’s say I want to access a system that uses the SHA-512 hash algorithm for passwords. I type in my password, say, “BayardIsAwesome”. My machine shoves that password into the hashing algorithm, and out pops:


That, not the plain text password, is sent to the server. The server compares it to the hash it has stored for me. If they match, I’m let in.

No matter how long my input is, the resulting hash is the same length. You can try it yourself here. Put in the Gettysburg Address (at least this version), and you get:


Put in an entire hard drive’s worth of data (like we do in forensic examinations), and you get the same length of output. So, you can’t (or at least shouldn’t be able to) crash a server be cramming too large a password into it.

I’ve had an idea for a password scheme that would involve the possibility of multiple passwords, that is you could have anywhere from one to N words in your password. So if your username was “bob” and your password was “my dog has fleas” your login sequence would be like this:

User: bob
Pass: my (displayed as asterisks or dots, of course)

Invalid username/password combination

User: bob
Pass: dog

Invalid username/password combination

User: bob
Pass: has

Invalid username/password combination

User: bob
Pass: fleas

Welcome to Joe’s pretty secure bank!

The beauty of it would be that the would-be cracker would have no way of knowing if the password attempted was incorrect, or if there were more to follow.

The password limit I find especially obnoxious is a restriction on characters in sequence. For example, you can’t have more than three lower-case letters on a row, or upper-case, or digits, or special characters. I’m sure they do this to prevent dictionary words. But it also puts a correlation between the letters. I’m no cryptographer, but that seems like something that could be exploited.

Good luck supporting that system with non technical end users; just giving an ‘invalid’ for a valid response is going to cause hassles.

Oh, and on the main topic: Modern secure systems shouldn’t need a lot of limits on passwords. Most of the limits came from older systems where storage was at a premium and special characters did weird things to consoles and as input to programs, and they were often stored as plain text instead of a hash which is just a bad idea for a number of reasons. I have no idea why so many places have weird and arbitrary limits like ‘no special characters’, half-way decent programming should make this unnecessary.

My bad password handling example: At a place I worked years back, we bought a firewall that ran on some flavor of unix and put it in place with pretty much default settings, figuring we’d seriously set it up once we went to a class on how to use it a few weeks later. There wasn’t a password length limit, so for the root account we made a nice long password with what the device is followed by the initials of the company and a slogan and the date one of us replaced his car. Something like firewallCNSDBTL122396 that was long and mostly gibberish, but easy to remember for us. At the class, the instructor casually mentioned that the flavor/version of unix used for the system silently truncated any password to the first eight characters entered, so what we actually had as a password on our firewall was the absolutely uncrackable ‘firewall’.