Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

share|improve this question
up vote 17 down vote accepted

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.

share|improve this answer

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.

share|improve this answer

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

share|improve this answer
"many security experts such as Bruce Schneier recommend that people use passwords that are too complicated to memorize, write them down on paper, and keep them in a wallet." -- – David Cary Jun 12 '11 at 2:20

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.

share|improve this answer
"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 at 20:30

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.

share|improve this answer

I'd personally go with using a password generator (like 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 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)

share|improve this answer
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

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.

share|improve this answer
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
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

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.

share|improve this answer

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.

share|improve this answer
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

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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