How long should the maximum password length be?

Question

The minimum password length recommended is about 8 characters, so is there any standard/recommended maximum length of the password?

Answer 1

The answer to this one, like a lot of questions in Security is "it depends".

There's several factors to consider when looking at password length. First up is some of the things that a long password is designed to protect against, which is generally a brute-force of password guessing attack (online or offline).

For online password guessing, if you've got a relatively aggresive lockout policy (eg, 3 incorrect attempts and then an indefinate lockout) then attacks against a single account will be unlikely to succeed unless the attacker has a good idea of what the password is going to be.

If you're looking against attacks on a large population of users with the same lockout policy, where the attacker can work out the usernames (eg web forums), then the most important element is probably that the passwords used aren't any of the really common ones.

As an aside, one thing to watch for on the account lockout side, is that aggresive policies here for on-line applications can make a Denial of service attack quite easy, without additional countermeasures.

If there's a risk of offline brute force then password strength becomes more important. the problem here is that improved processing power and methods of attack make this a moving target in terms of strength. Realistically I'd say that you'd be looking at 10+ characters and strong enforcement that passwords aren't on common dictionary lists (like @andy says passphrases are a good option here).

Another factor to consider here is your user base, and how the application is used. In some cases, I'd say that very strong password requirements can actually lead to a less secure application. If you have an application where the users are in the same place (eg, a lot of corporate applications) and you make the password policy very "strong" (both in terms of password length and rotation requirements) then it's likely that users will start writing down their passwords, which probably defeats one of the goals of security for that application in the first place.

One good source of a lot more information on this is a book called Authentication: From Passwords to Public Keys

Answer 2

Good answers so far, but I would like to suggest another possibility: pass phrases. As StackOverflow's own Jeff Atwood suggests, if you aren't prohibited by technical limitations, you might consider allowing and suggesting pass phrases. You could enforce them, but that would probably alienate some users on most sites. Due to their length, they can be significantly more difficult to crack, and they can also be easier to remember than a password like "A1lUrB@se!" or things like that.

Answer 3

If you're going to be hashing the password, why set an upper limit?

It's not like you need to worry about hitting the max char limit on text fields, web-based or otherwise. So you could conceivably just set a maximum of a few hundred characters just to limit some boundary conditions of whatever text fields you're using.

Of course, if you're talking about generating a password that you'll try to use on multiple sites, then never mind; no one out there seems to agree on it. Even worse, I've found sites that have different max char limits on different input fields, so to log in you have to first type it wrong before being given a different field that happens to allow more characters. Of course, if every site just let it be the minimum expected abilities of a typical text field without trying to artificially limit it, then about 2k characters would be allowed, and you wouldn't have to worry about this at all.

Edited to add: something mentioned in passing here made me pause:

you have to scale the hashing work to what's available and reasonable on your servers or devices. For example, we had a minor denial of service bug in Discourse where we allowed people to enter up to 20,000 character passwords in the login form

It might thus be worth putting a reasonable limit on both setting and attempting passwords if you're hashing things in a way that's meant to be as computationally expensive as possible. A few hundred characters might still keep things from exploding too much, while still being way more than a user might ever try.

Answer 4

Bruce Schneier has a couple of interesting articles on password policies.

Real world passwords - covering password length, complexity and common passwords.

Password advice - some do's and don'ts including:

• DO use a password manager
• DO change passwords frequently. I change mine every six months...
• Don't reuse old passwords.
• DON'T use passwords comprised of dictionary words, birthdays, family and pet names, addresses, or any other personal information.
• DON'T access password-protected accounts over open Wi-Fi networks — or any other network you don't trust — unless the site is secured via https.

and many more

Changing passwords - a detailed discussion on how often you should change based upon usage and threat environment.

Answer 5

There should not be a maximum password length -- if the user accepts to use a very long password, then he should be commended, not blocked.

Software being what it is, several systems will enforce a limit on password size, mainly due to GUI issue, poor programming, or backward compatibility with much older systems. For instance, old Unix systems used a password hashing process which used only the first eight characters, and totally ignored all others. Similarly, old Windows systems had an internal limit to 14 characters. Therefore, it is best if the password, when truncated to its first 14 characters, is still "strong".

However, the only limit on maximum password size should be the user's patience. There is no point in enforcing anything here.

Answer 6

A common minimum today is 12 characters, which is just barely large enough to prevent brute-force cracking by a reasonably well-funded organization within a reasonable amount of time.

As far as maximum length; here are a few thoughts: a password longer than a few hundred bytes is almost certainly malicious (e.g. SQL injection attempt). Also note that if you're hashing your password (and if you're not, you need to start over), then passwords longer than your hash output don't add any more entropy. Note that by "longer" I mean the same number of bits in your keyspace, not the same character length. So while allowing passwords longer than the hash length should be allowed as a point of convenience, it would not make sense from a math point of view for such a thing to be required.

Requiring mixed case doubles the size of your alphabet, which yields huge complexity returns and probably should be required. Requiring numeric characters adds maybe 20% more to your alphabet, which isn't quite as big a deal, and requiring symbols adds maybe 16% to 40% more on top of that (depending on what symbols you count), and again, not quite as significant a return, but certainly shouldn't be disallowed.

Answer 7

I'd personally go with using a password generator (like lastpass.com or 1password) to generate and use passwords of minimum 8 chars and max 32 chars (since not all sites support password length more than 10 or 15 ) and use one master password for authentication.( This again depends on your trust on sites like lastpass.com) or a client side encrypted 1password utility for Mac and Windows) .

It is not advisable to use a set of passwords for all sites. Forums in particular email me passwords in plain text. Some sites have the feature to send in plain password in case you use "Forgot Password" feature.

Usually, the restrictions are set up at the server (for websites) . We need to blame the servers we use to not set restrictions on user passwords.

In short, use different passwords each time. In case you have more than 10-15 passwords to remember, its time to start using a "secure" password manager. (For the record, firefox password manager is not at all secure)

Answer 8

16 characters.

This gives you 96 bits according to Wikipedia, which is well beyond anything crackable according to that article.

Personally I use a password program for my mobile phone, combined with Firefox' Master Password feature. My master password has more than 25 characters and is based on Dice Ware, which makes it fairly easy to remember. Almost all my passwords are randomly renerated, since Firefox remembers them for me anyway.

Answer 9

I was at a client where the security officer was insane. He wanted to use every single password complexity policy possible. (Novell eDirectory has a LOT of password complexity issues, and he wanted to use an additional plugin to add more!)

To the point it would be impossible to ever generate a password that can be remembered. I was expecting the unwashed masses to find him, and tar and feather him after it was implemented.

In other words, you can take it too far.

Answer 10

Advice

In 2019, the randomness required for a secure password/passphrase is:

• 12 randomly generated characters with lowercase, uppercase, and digits; or
• 6 randomly generated words. (Do not choose words yourself! That creates patterns.)

It is impossible to remember twenty of those, so only memorize a few important ones that you use regularly. For example, you could memorize the one for your email account, and the one for your password manager. For everything else, store passwords in a password manager.

Relevant: Does the average user really need a password manager?
The top-voted answer is a clear "yes".

Relevant: How safe are password managers?
From the top answer, by paj28 (emphasis mine):

for most people these risks are acceptable, and I would suggest that the approach of using a password manager [for] most of your passwords is better than using the same password everywhere - which seems to be the main alternative. But I wouldn't store every password in there; make an effort to memorize your most important ones, like online banking.

Commonly mentioned password managers are KeePass(X), 1Password, and LastPass. The one in your browser depends: when you use Firefox with a master password, that is almost as good as using a dedicated one. If your browser does not require a password before you can access the passwords, it is not very secure (but the details depend on the exact implementation, which is a whole topic by itself).

Developers

When you build an application, here are some useful considerations:

How to securely hash passwords?
Summary: use Scrypt or Argon2, as slow as you can go. If those are unavailable, Bcrypt or PBKDF2 are acceptable alternatives. Add both salt and pepper.

Should I have a maximum password length?
Summary: only against DoS attacks, so a few kilobytes or so.

Implement client-side password hashing
Full disclosure: I link to my own answer because I think it's the most complete one. Be sure to also read other people's opinions.

Details

You might wonder "why is my PIN code only 4 digits then? That is enough to keep my bank account secure!" There is a question dedicated to this, but the summary is two things: you need your bank card for access (a second factor of authentication), and the chip locks you out after 3 attempts.

Websites are much more lenient, so an attacker can do more attempts. Furthermore, websites are expected to get hacked sooner or later, after which the attacker can crack your hashed password efficiently.

Most websites store your password with a sort of one-way encryption, which is called hashing. There is no decryption key. By applying the same hashing algorithm again, the system can compare the password (which you just typed) to the stored one (from the database) and know whether they are equal. But with only the database, you cannot know the original password.

In the past, fast hashing methods were common. This also means that an attacker, who has obtained the hash, can have his computer do billions of attempts per second on an average gaming computer. Assuming ten billion attempts per second, an 11-character random password holds out for about 165 years. And that's just one gamer, imagine you have access to company data that some foreign competitors are interested in: with some extra computational power, those 165 years suddenly turn into a few months of cracking. And next year, there will be new CPUs which are faster for the same price, reducing the strength again. That is why twelve characters is the minimum for a strong password: that one extra character adds literally ten thousand years to the cracking time (165 years versus 10 230 years), and is secure for the foreseeable future.

By the way, calculating password strength is easy: variations^length / guesses_per_time. The variations is how many unique elements there are and the length is the number of elements you use. So if you use digits only, there are ten variations (0 through 9). If you use words from a dictionary, it is however many words are in the dictionary. Then, guesses_per_time is just how fast you assume the attacker can crack. A reasonable value is tens of billions per second.
Example: 10^14/10e9/3600 shows you how many hours it would take to crack a code of 14 digits, when you assume 10e9 attempts per second (there are 3600 seconds in an hour, 60*60).

Some websites are smart and use a slow hashing algorithm. We cannot tell which ones those are, because the server does the hashing, so you cannot see it from the outside. If this is the case, then a single guess will take much longer to compute (for the server, but also for an attacker). In a reasonable case, a well-funded attacker can do only fifty thousand guesses per second, in which case a 9-character password would be enough. But 9 random characters are already super hard to memorize for many different accounts, especially if you do not use them all regularly. Therefore, a password manager is required to really have any security in passwords.

But is it really necessary to have unique passwords? Why not re-use strong passwords on a few different sites? Because websites frequently get compromised. It's not an everyday occurrence, but try to enter your email address(es) in haveibeenpwned.com: it definitely happens a lot. This is how accounts are hacked most frequently: password re-use. Compromises of password managers are much less common.

Answer 11

Seems to me that Password length and complexity has gone to far. When paired with good lockout policies, 10 should be more than enough. Currently 4 numbers is enough to secure ATM transactions. Also Phone locks go as low as 4 but often require 6. The lockout policy is the most important part of the formula. If you require a user to contact someone to unlock an account then the size can be smaller. If they lockout is done for a time period then the password should reflect.

Answer 12

The criteria I use for passwords is this:

• Be generated by the website itself, so users cannot use insecure passwords by design.
• Be computer generated, so its pattern is truly chaotic. Human generated passwords have predictable patterns.
• Be made only of lowercase letters, so it's memorable and fast enough to type on any kind of device and keyboard.
• Be 20 characters long. So it has enough entropy to be uncrackable by a botnet when the attempts aren't artificially stretched, like when the police is trying to unencrypt your storage using the Echelon.

When writing the password down I divide it in groups of four, so it's easier to remember. For example:

bxkx osnt spmf jmwz ivyj