60

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

  • This question seems to have become the canonical question on this site for "how long should my user password be?", but most of the answers seem to focus on the administrator's policies, not what the recommended length is for a user. Can someone with enough clout create a new question addressing the later and fix the duplicate links? I'd ask the question myself but it'd probably get shot down as a duplicate. – Cody P Aug 23 '17 at 23:44
  • The reason such a question is not needed is in this meta post. – NH. Nov 14 '17 at 17:52
  • Minimum password length is NOT a set number. Anyone who provides you a set value today is incorrect tomorrow as processing power increases - 8 has not be a valid minimum for some time now. Max would be determined by implementation of the platform or application. – McMatty Jan 9 at 19:49

11 Answers 11

18

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.

20

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.

  • 4
    This is a comment, not an answer. – Wouter Jan 9 '17 at 13:01
18

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

11

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.

  • 1
    "If you're going to be hashing the password, why set an upper limit?" Perhaps because if it's too long, and if it's randomly generated, its entropy might reveal the quality of your random number generator. – Geremia Jan 20 '16 at 20:30
  • @Geremia If a few hundred bytes of password expose the quality of your RNG, you have bigger problems than password length limits. Setting a lower maximum length really does not help you. – Luc Jan 9 at 19:10
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.

  • 2
    Unless there is a good technical reason. An example being PHP's use of BCRYPT means passwords are truncated past 72 characters. – PaulSkinner Sep 15 '16 at 10:44
3

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.

  • 2
    I wouldn't require mixed case or any other character class. I'd rather use some kind of entropy estimator on the password and then require a minimal value for its output. So users who use fewer character classes need a longer password to compensate. – CodesInChaos Feb 2 '13 at 16:23
  • How about if we abandon the punctuation because some people write down passwords and written semi-colons look like colons, periods look like commas, etc. If they use a software password keeper, some fonts might not be friendly to people with poor eyesight trying to read punctuation. Of course the attackers should go ahead and assume there's punctuation. – H2ONaCl Jan 25 '15 at 9:20
2

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)

  • 1
    Btw, if a server has a restriction on password length, it's usually because of other vulnerabilities: e.g. the password is stored in the clear, and thus the alloted database field is what limits the length. – AviD Nov 12 '10 at 8:55
  • Can you elaborate on firefox's password manager being insecure? – rox0r Nov 20 '10 at 1:23
  • Firefox and other browsers like Chrome and IE have a password manager but the passwords can easily be recovered and read by addon's, plugins and other software on your system. Firefox does have a feature to secure the password manager with a master password. I wonder if AviD or someone else would comment on the security of FF with the master password feature enabled. – Rincewind42 Aug 4 '11 at 7:20
2

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.

  • 5
    Terrible advice, 16 characters are too little if you want to use a combination of space-separated words, which are by far more secure. I don't want to be forced to use any master password feature for my e-mail, and it has 35 characters. – Camilo Martin Mar 20 '12 at 5:42
  • 2
    Granted. I was going for a short, usefull answer. 16 random characters, upper and lower case, and numbers and special characters is a good minimum. Five diceware words is superior to this. – Roger C S Wernersson Mar 21 '12 at 21:07
  • But why is that enough? I like that it's a practical answer, but it should be backed up with an explanation I think. – Luc Jan 9 at 19:08
  • That would be a different question. The answer should be in the Wikipedia article I link to. – Roger C S Wernersson Jan 14 at 14:50
2

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.

  • Sorry, you lost me somewhere. You said "it was impossible to generate a password that can be remembered". That makes sense. But then you say: "In other words, you can take it too far." I understand that you found it annoying, but the question is how strong a password should be. Did you find that this policy caused weaker passwords and therefore reduced security? Or did it significantly harm the productivity of the company? Or was neither the case and was it a really good policy that, in 2010 or earlier, was new to people? – Luc Jan 9 at 19:04
0

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.

  • 1
    The difference is that you must be in physical possession of your phone to try unlocking it. If 10,000 people have a 4 digit password, you'd have a good chance of getting into one of the accounts simply by trying 1 password on each. – AndrolGenhald Jan 9 at 18:11
  • @AndrolGenhald I'd say the difference is that you have a limited number of attempts on a phone or smartcard (such as a bank card or SIM): after three to five attempts, you're locked out or rate-limited. Password recommendations keep in mind that someone might apply online or offline cracking to it, where you can do somewhere between 100 and a few billion attempts every second. There are not that many websites that apply rate limiting, and it's best to assume the database gets stolen at some point. – Luc Jan 9 at 18:52
  • 1
    @CoachDavid See this question why it's not so simple as "4 numbers should be enough for everything": Password strength and banks 4 pin code? – Luc Jan 9 at 19:00
  • @Coach David - you'd do better to ask a question here if you're looking for information – SomeGuy Jan 9 at 20:36
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.