It's generally recommend to use a unique password for each online service, a random password generator to create them and a password manager to store them.

I've started to replace all my online passwords with this technique, but some sites have certain rules regarding the length of a password.

Unfortunately, sometimes, a website will not be programmed to communicate the number of maximum characters allowed and simply delete the overflow if copied into the password field. Because of this, I've already had some trouble getting control of an account back, since I did not know how many characters were saved as the password.

Is there any specific number of characters that will probably work on most sites/backend programs and that is still considered relatively safe for randomly generated passwords, so that I can just use one password generator length setting for as many sites as possible?

  • 3
    I would file it as a bug with the site itself; if your "signup" page cuts off my password after N chars, I think the login page should do so too.
    – ndrix
    Commented Oct 20, 2017 at 23:15
  • 1
    Yeah, I guess I should do that, you're right. Only that I just found out they also store passwords in plain text, too. So a lot to complain with them. Someone reading who I can write to for help, should they get defensive about it? (Not an expert myself..) Commented Oct 21, 2017 at 14:53
  • If you use the password for logins (as opposed to encryption) you do not really have to worry much if you use the password only on one site. If the site gets hacked so a offline attack becomes possible they most likely can access your account without cracking it. If your password is used nowhere else, don’t worry about it beeing bruteforced. So having 64-80 bit Security is for most stuff plenty.
    – eckes
    Commented Oct 24, 2017 at 10:22

4 Answers 4


If your passwords are n characters randomly drawn, with equal probability, from a set of 95 characters (which is about all the ASCII printable characters minus space), then each character gives you about 6.6 bits of entropy, so the strength of a random password with n characters is 6.6 × n. So:

  • A 10 character password gives you about 66-bit strength;
  • A 12 character password gives you about 79-bit strength;
  • A 14 character password gives you about 92-bit strength;
  • A 20 character password gives you about 132-bit strength.

In my judgment, you could sensibly choose any of these lengths depending on the application. For example, if you use a 66-bit password for a low-value online service, your password will still be loads stronger than nearly everybody who uses that service. But if we're talking about a password that's used to derive an encryption key on software that you run on your own hardware, you should certainly consider something stronger.

To add some additional thoughts, it pays to consider two kinds of attack:

  1. An attack targeted at a website (or other password-protected service) that you've enrolled in;
  2. An attack against you specifically.

In scenario #1, the password cracker is going to divide their computational power to cracking as many users' passwords as they can, in the hopes of finding the low-hanging fruit—users who have very weak passwords. I believe a 64- to 80-bit password is plenty to defend your passwords against such attacks.

In scenario #2, the attacker is going to dedicate all their computational power to cracking your password specifically. In that case, a powerful adversary might (or might not!) be able to crack a 66-bit password, and you could therefore justify going as far up as 19-20 characters (to match the 128-bit security strength of most ciphers).

And always keep in mind that if your password is strong enough, that just means the #2 attacker is going to probe a different weakness. Don't bother making your password inconveniently strong if you've got big holes elsewhere.

  • 1
    It is worth noting here that the increase in strength does not continue upwards in a linear fashion. You get to a certain point where you are adding no extra security (note i am saying security not entropy). See here for more detail: security.stackexchange.com/questions/169472/… Commented Oct 21, 2017 at 12:08
  • Unfortunately, the site I was referring to capped below 20 characters. But would you say that a 10 or 12 character password is still super-computer proof for the forseeable future and a good tradeoff or what would be the lowest advisable length/bit-count? Commented Oct 21, 2017 at 15:11
  • @Prototype700: I've edited my answer to account for your comment. Commented Oct 21, 2017 at 18:53
  • Okay, thanks. So for very sensitive data, the more the better, but 12+ would be relatively secure and adding more characters would be more for peace of mind rather than practical security? What was that about "matching the 128-bit security strength of most ciphers"? Mind elaborating that a little? Commented Oct 22, 2017 at 19:15
  • 1
    @Prototype700: If we're talking about a password that's used for generating an encryption key (not just authenticating to a website), then lots of encryption algorithms in common use only provide a 128-bit security level. In that case using a password with more than 20 random characters is just a waste—once you hit 20 characters the weakest link would then be the encryption algorithm, not the password. Commented Oct 23, 2017 at 20:48

I'm going to differ from the other answers (so far) and suggest that if you're generating a unique random password per website, you don't need a really long password at all.

Lets think about the threats to passwords. We'll look at the server-side alone (i.e. we won't take account of things like keystroke logging malware on your PC as password length doesn't help much there)

So basically attacks, for which password length is relevant, fall into two categories. Online brute-force and offline brute-force.

In online brute-force, the attacker tries to guess your password against the website, so they submit one request per attempt. In reality many sites will lock out after a number of incorrect requests, but for this lets assume they don't

Now assume the attacker can make 1000 guesses per second. If you have (for example) chosen a 8 character random password using Upper, Lower and numeric characters there are 62^8 options. At that rate we're talking heat death of the universe before they guess it.

Now someone could say "what if the attacker gets a botnet to guess it, they can go much faster!", I'd suggest that you'd DoS pretty much any site before you make this fast enough to be practical.

Ok lets talk offline brute-force as it's more relevant to password length. Here the atacker has already got a copy of your password hash, so it's likely they've compromised the security of that site pretty thoroughly. Here you can make an argument that you want the password to last long enough for the site to notice they've been pwned and get you to reset your password.

To say exactly how long is kind of tricky as it very much depends on how the site stores their passwords. If they use unsalted MD5 that's a massive difference than if they're using bcrypt with a high work-factor.

However one thing to consider in all this is impact. What's the impact of this password being cracked. Well if you've used a unique random value for every site, then the impact is likely to be quite limited. you'd hope that your high value sites are all using 2FA so password alone doesn't get the attacker far and the low value sites, well what are the consequences of compromise?

All that analysis doesn't really answer your question, but as a rule of thumb I'd suggest if you're even using 10-12 characters with Upper, Lower and numeric and the passwords are really random (that's the important bit) you're a) likely to be fine and b) unlikely to run into problems with any site restrictions.

Per this article on password cracking a 10-char upper, lower, numeric password would take 83 days for a "Super computer or botnet" to crack. What you've got to ask yourself is, is it likely that an attacker will invest that cost to break a single password where they have already compromised the security of the target site to get the hash....

  • Fair points. Since the original question is looking for a "use everywhere" strategy, we should assume worst case (very important password, offline attack, unsalted MD5, nation-state-level resources (~1TH/s)). A 10-char upper/lower/numeric could be cracked in at most 9 days, 12 chars in 3.5 months, and 13 chars in 6342 years (ignoring quantum computing and Moore's Law). Based on that character set, 13 chars would probably be a good "set and forget" compromise. But that character set will run afoul of sites that require special characters, so I think there's more room for a best answer here. Commented Oct 21, 2017 at 23:22
  • Also note that the calculation that you mentioned would be 62^8, not 8^62. Commented Oct 21, 2017 at 23:38
  • 1
    The things is, for the use case of the original poster, Nation state is very unlikely to be a valid threat. If your opponent is a nation state they'll just drop 0-day malware on your machine or (if they're your nation state) serve a warrant for your computer. I think advice should match likely threat model, and for that where the impact is access to a single website and it requires the attacker to have already compromised that site's security to get the hashed password, 10 characters is entirely reasonable for most users. Commented Oct 22, 2017 at 9:53
  • @RoyceWilliams: "But that character set will run afoul of sites that require special characters": in my experience there will always be websites with odd rules requiring a per-website exception to your common password generation generation rule (special characters either mandated or forbidden, not more than 6 or 8 characters, only numbers, etc.) expressed sometimes in an unclear way ("Invalid value"). For them, your password manager should offer a note functionality so you can remind yourself the specific rules when renewing the password, the 99% other websites using your usual rule. Commented Oct 22, 2017 at 11:01
  • Only concerned with the mere length at the moment. There are always sites that demand special rules when entering a password. (Even here on Stackexchange, starting with an upper-case character and including symbols or something?) - So that's another issue, but can usually be manually accomodated, because the site will complain about it or display checkboxes. As this didn't happen to me once regarding the length and some sites do have a max-length, I was looking for the shortest secure value. 10-chars seems potentially risky in the absolute worst case, but 3+ months should be plenty of time. Commented Oct 22, 2017 at 19:33

From my personal ad-hoc use and testing, I've found 20 random characters, using upper/lower/digits plus a few carefully-selected specials (@#$._ not including the parenthesis), to be a nice mix:

  • Good length - less likely to be silently truncated (once you get above 20, more sites either start silently truncating -- just as you've seen -- or else they reject them as "too long" - 20 used to be too big for this purpose, but the landscape has shifted in the past few years)
  • Very good keyspace size ((26+26+10+5)^20 = 3.32x10^36) - admittedly overkill even for nation-state time-travelers from the near future, but intended to cover almost all potential threat models (including consideration of Moore's Law and nation-state-level resources) for just about everybody, without being unmanageably long
  • Meets most naive/legacy complexity requirements (including requiring at least one special character)
  • Meets many "non-complexity" requirements (forbidden characters)

In other words, this is an approach that I think would fit most threat models and use cases.

I have no formal data to support this claim other than my own experimentation with my own logins over the years, but that's my take. You may have to tinker with the list of specials over time, but you get the idea.

Edit to add an example command line:

echo $(tr -d -c 'A-Za-z0-9@#$._' </dev/urandom | head -c 20)
  • What generator are you using? I use pwgen and am not aware of an option to exclude parenthesis specifically. (Other than to manually choose a generated password without them.) Commented Oct 21, 2017 at 14:57
  • I'm using a shell script. Though I would expect most generators to allow you to define an explicit character set. Commented Oct 21, 2017 at 23:14
  • And by "not including the parenthesis", I meant "don't include the parenthesis in my sentence as part of my short suggested list of specials") :) Commented Oct 21, 2017 at 23:25
  • 1
    I've encountered 12-character limitations, before, which is plenty long for random characters. Commented Oct 22, 2017 at 18:29
  • @Royce Williams: Oh, okay, I understand! I thought you meant specifically not to include parenthesis {}[]() in the password at all. Although that doesn't change much about your recommendation, anyway. The command you added prints 20 characters from the header of /dev/urandom according to the specified set of characters and symbols? Commented Oct 22, 2017 at 18:52

Sadly, there are no standards for permissible passwords, nor any similarities between web sites. Developers put in whatever restrictions they imagine might help with security, others put in restrictions based on external (but also completely arbitrary) rules. This means that if you figured out that 14 character passwords hit the sweet spot, you'll still have other incompatible rules to contend with: some number of upper case, lower case, digits, or symbols, and you'll have restricted character sets that aren't compatible with each other. Some sites permit only a very few special characters (or none at all) in hopes of avoiding SQL injection attacks; others require different special characters because they incorrectly think a broader character set improves security.

Your best bet is to make your generator configurable, and to view each site as an independent source of rules.

  • I think the original poster is looking for a "best effort" baseline, from which he can depart on a site-by-site basis as needed. Commented Oct 21, 2017 at 23:34
  • Yes, he is. There will always be a website that demands (not) to use certain characters. However, there will usually be some kind of hint on what needs to be contained in the password and the site won't just automatically delete invalid characters out of the entered password and save it like that without telling the user, or at least I haven't observed such a behaviour before. However, I have experienced this with the length of the password, so I thought maybe there's a common consideration for a good length that can safely be used everywhere. Commented Oct 22, 2017 at 18:56
  • A nice feature for a password manager would be to have the password rules for each site built into the system. When a user adds a new site, the rules are discovered: since most rules are stored in the Javascript of the site, it's possible to scrape this info. At the very least, a staff member could have the boring yet useful job of digging through the JS. Commented Oct 24, 2017 at 6:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .