I've come across quite a few sites that either limit the length they allow passwords to be and/or disallow certain characters. That's limiting to me as I want to widen and lengthen the search space of my password. It also gives me an uncomfortable sense that they might not be hashing.

Are there good reasons for either setting an upper length or excluding characters in passwords?


11 Answers 11


Limiting the length can be a measure to limit the execution time of the hashing as well as limiting bandwidth (and both of those are really marginal anyway). Other than that, there is no good reason, especially from a security point of view.

One could say: “People will forget longer passwords more easily” – but that’s really a stupid statement and doesn’t get to the point at all.

As for characters, as long as you are aware of potential encoding issues with data transfer and/or migration in the future (e.g. you will switch from ASCII to UTF-8 in 2 years) allowing more characters can only be good for passwords strengths.

  • 5
    Given the overhead of any modern protocol length can absolutely not be a good reason -- other than a high limit like 1K just to prevent certain attacks/nonsense. Jun 27, 2011 at 16:23
  • 3
    Limiting the execution time of hashing is generally bad. The longer it takes to calculate a hash, the longer it takes to brute-force it.
    – tdammers
    Jun 27, 2011 at 19:50
  • Although that’s right it’s always a trade-off. You don’t want to always calculate the best hash which takes the longest. Hence asymmetric handshake vs symmetric data stream in VPN etc.
    – Kissaki
    Jun 29, 2011 at 10:27


There are no good reasons.

EDIT: I cannot prove that there are no good reasons, because one cannot prove a negative. I can think of no good reasons for this - as others pointed out, the hash will be the same size regardless of the size of the input, and eliminating valid characters (from the question context) just reduces the state-space. The answer seems obvious on its face: there are no good reasons. There may be a large number of reasons that sound good or that seem good, but they aren't. If they were, someone would have posted them here already, or if not here then certainly on security.stackexchange.com, and this answer would not have been so heavily upvoted.

  • 3
    I agree, but the comment Kissaki makes about encoding is valid. Some stacks/programmers just can't seem to get the encoding correct, for them limiting to ASCII is a cheap hack to make it work. Jun 27, 2011 at 16:24
  • 10
    Could you at least try to elaborate? Either you don't know this for a fact, or you have reason to believe that common/existing reasons aren't valid. Giving you the benefit of the doubt and assuming the latter, you should be explaining why those reasons are not valid.
    – Aaronaught
    Jun 27, 2011 at 21:31
  • 10
    -1 - I can think of several good reasons for limiting passwords to a given character set. Likewise, having to support touch-tone phone passwords as well as ones you type via a keyboard is also a situation you have to keep in mind.
    – rjzii
    Jun 27, 2011 at 22:47
  • 10
    -1. No justification, just opinion. If you're going to make a blanket statement, back it up.
    – Michael K
    Jun 27, 2011 at 23:10
  • 4
    This is now being discussed on our meta-discussion site: it would be helpful to understand why a single-word answer is so popular and what we can do to improve the quality of answers like this.
    – user8
    Jun 27, 2011 at 23:21

Yes, there is a reason for special characters.

Disallowing special characters is more of a usability thing, rather than security related. First of all they might get mangled by encoding problems. Second, even if you'd guarantee to always use same encoding, there is still the problem of input device. You'd be depending on having full keyboard (which eliminates most mobile devices), with same keyboard layout. Later differ not only between languages, but also between OSs, layouts for Windows, Linux and OSX may be a bit different. So I see good reason not to allow password like: √Ω≈ç∫∞§…¬å∑±.

  • 4
    unless you are providing a password to your users, that is, if they are the ones entering the password themselves then if they so choose to use some strange math symbol is really their business. now i do agree with the encoding issue here though find it more of an excuse to pass below the radar incompetence than a actual good reason to prevent certain characters arbitrarily.
    – Newtopian
    Jun 28, 2011 at 2:38
  • 2
    @new: it's not their business. If they shoot themselves in the foot, they will still perceive as problem with your application and call your support.
    – vartec
    Jun 28, 2011 at 7:14
  • 8
    @Newtopian: I hate it when I, as a user, get circumscribed by reason of ignorance (such as not be able to specify a "+" in my email address). Sometimes, however, it's a good idea not to give the users to much rope with which to hang themselves. I think this is such an occasion. It's not about "arbitrarily" preventing certain characters.
    – Zano
    Jun 28, 2011 at 7:28
  • 3
    So you're advocating Greeks, Arabs, Chinese and others all use US-ASCII?
    – l0b0
    Jun 28, 2011 at 13:34
  • @l0: no, I'm advocating that they use normal, commonly used characters in their languages, rather than some special characters, which may be absent in some layouts.
    – vartec
    Jun 28, 2011 at 13:43

There was a bit of a controversy in the security world a few years back when Chase customers discovered that their passwords were case-insensitive. It turned out their webpage was just a frontend to some 30-year-old OS/400 backend system, which had a technical limitation that it ignored case. Fixing this would apparently cost millions of dollars.

The point is, there may be expensive legacy reasons for not allowing passwords over a certain length.
(Note that I'm not condoning this excuse...)

  • 1
    insofar this is the only good reason to limit password in any way... only if the underlying system will hold such limitations in the first place.
    – Newtopian
    Jun 28, 2011 at 2:41

Most banks, IT departments, etc. Who enforce maximum password restrictions don't do so for technical reasons. They are perfectly aware of how password hashing works, and how to store complex passwords. They impose these limitations because it reduces the number of calls to support for people who have forgotten their passwords. Is this a good reason to impose that kind of limitation? By no means. But, nevertheless, it is the main reason.

  • 1
    I see reducing support calls as a valid Business reason (Personally I don't actually believe that there is a correlation) Jun 27, 2011 at 17:10
  • 2
    Well, there are other ways of going about resetting passwords, or educating users on how to choose sufficiently complex passwords that are easy to remember. My last few passwords at work have been > 25 characters, and I've had no trouble remembering them. Also, presumably, people who have trouble remembering their long passwords will still pick shorter passwords, though I have no clue how often that's actually true. Reducing support calls does seem like a valid business reason on the surface, but it's still a lousy reason to restrict password length. Jun 27, 2011 at 17:12
  • 1
    I think my (and many people) would find accurately typing (not just remembering) 25 characters without seeing the output almost impossible. I have so far fixed 5 typos while typing this!
    – Gerry
    Jun 28, 2011 at 4:25
  • Well, remembering isn't the same as typing. Remembering long passwords is very easy if you know how to choose them; simply pick lines from stories or plays, or parts of poems or song lyrics. As long as you change one or two things in there (intentional misspellings, change one word to another that sounds like it or means the same thing, etc), it's quite easy and extremely secure. True, typing it may be harder, but it's no excuse for banks to force you to type less than 8/10/12 characters. Jun 28, 2011 at 6:55
  • try typing that 25-letters password on a mobile device
    – Lie Ryan
    Jul 13, 2011 at 6:40

Are there good reasons for either setting an upper length or excluding characters in passwords?

I'm going to make a guess and say that some of these restrictions are due to character filtering on their website (& < > #) to keep hackers out. While others are the bone-headed ideas that come out of committees of pointy haired bosses.

I've come across a number of really stupid (in my opinion) "security" decisions. As an example, one large investment company handles my IRA accounts as well as my pension. In order to do any contact with the pension requires me to type in my password on the telephone (you cannot reach them otherwise). My brokerage/IRA account uses letters (upper and lower case) as well as some punctuation - none of these characters appear on a telephone number pad. If you can't log in with the password over the phone, it lets you reset your brokerage account's password to something you can type in over the phone.

My payroll system (for the consulting company I work for) requires numbers, and only numbers - this lets them use the same database whether the user calls in (I've never done this) or uses the web interface (I only use this).

That being said, it is time to change my password at the office. They have such crazy restrictions that I estimate it will take about half a day to find a password acceptable to the system: at least 2 upper case letters, at least 2 lower case letters, at least 2 digits (which cannot be +/- 1 from the previous password's), at least 2 non-alpha/non-numeric characters, cannot match any of the last 24 passwords, cannot contain any string (forwards or backwards) that is a word (3 or more letters long) in English (also a couple other languages I don't have clearance to know). I think the minimum length is like 10-11 characters.

  • Yep I've seen those characters on the no-list.
    – chris
    Jun 27, 2011 at 18:13
  • 6
    Simple attack: find sticky notes under keyboards because no one can remember their password.
    – JeffO
    Jun 27, 2011 at 20:04
  • @Jeff, that is correct. If I leave my notebook at home, the passwords are too complicated to remember, so I'm unable to log in. And on the payroll system, I put the username and password as part of the bookmark.
    – Tangurena
    Jun 27, 2011 at 20:38
  • "cannot contain any string (forwards or backwards) that is a word (3 or more letters long) in English" This was the one that got me. Dictionary attacks aren't effective if the password contains whole words, but rather if the whole password consists of nothing but full words... Well really one full word or very common phrases. The most secure passwords that are practical to use without writing down are passphrases that come from books, poems, song lyrics, etc -- change a few letters into numbers, misspell something, and capitalize unpredictably and no one is going to crack that password. Jun 27, 2011 at 21:29
  • 2
    Character filtering is a sure sign of untested garbage code in the background. Developers need to learn to escape strings.
    – l0b0
    Jun 28, 2011 at 13:32

Not all input devices (hardware-wise) often have all characters a full keyboard has, or likewise. If one is not using a password manager, one could find oneself in trouble entering such password, no? And Unicode is still a far way (far far way) from being a standard.

  • 2
    Usually the people entering passwords will use the same hardware (or hardware class) for creating them and authenticating them. I do not see how this is an argument in limiting character sets or length. As for Unicode, when building the server-side (the authenticating part) why would you limit the size or character sets ? any system requiring a password to enter should be able to control how this password is entered in the system, thus, if you require unicode for your client then so be it !
    – Newtopian
    Jun 27, 2011 at 20:11
  • @Newtopian You're assuming you don't have to interface with legacy systems, or systems outside your control. Jun 27, 2011 at 20:34
  • 2
    they asked for a good reason, this isn't a good reason
    – user7519
    Jun 27, 2011 at 22:59
  • 2
    @Jarrod - Not being able to enter a password is not a good reason?! In any case, I didn't see you come up with a better one (or any at all).
    – Rook
    Jun 27, 2011 at 23:02
  • 4
    @Rook you should not have used those characters if you knew you could not pick them from a device, that doesn't make it a good reason to limit them for everyone, it makes it a good reason for you personally not to use them.
    – user7519
    Jun 28, 2011 at 1:22

One reason for limiting characters would be due to how the password is then input.

Several banks for example, with their Internet Banking websites, ask for specific characters from a password, and you select the appropriate characters via a drop-down box.

They do this, presumably, so that keyloggers cannot detect the keypress, and thus know [characters from] your password. While I know that there are many other ways such measures could be circumvented e.g. screencapture; it is still effective against keyloggers.

If they had to allow all characters, then the length of the dropdown box would become cumbersome, and also allow for confusion between similar looking characters.

  • 1
    Surely (technical) people would just key in the letter anyway?
    – Gerry
    Jun 28, 2011 at 4:30
  • @Gerry - that's a browser specific behaviour rather than an absolute standard and it's also dependent on user knowledge to make it workable. Jun 28, 2011 at 8:46
  • My bank used a popup applet of a keyboard for a similar reason. But it was too difficult to use and got a lot of criticism for being inaccessible (didn't work for screen readers, alternate input etc)
    – jqa
    Jun 28, 2011 at 13:24
  • 1
    @Jon - I did say technical people, and I don't know of any windows browsers that don't implement at least first character matching, as it is standard Windows behaviour - can't speak for Mac and *nix
    – Gerry
    Jun 28, 2011 at 20:50
  • 1
    @Gerry The browser on my Android phone doesn't allow this. I expect it's the same for a lot of mobile devices.
    – RoundTower
    Jul 1, 2011 at 19:18

Disallowing special chars like tab would be valid. You can logon or change your password with a tab char in text mode but you can't use it in a GUI or web environment. A backslash char will also present some cross-platform issues.

btw long passwords are not passwords - they are passphrases. Your average user cannot remember 2Z8d!%g#x but they can remember 'the name of my pet is fido the dog'. Longer text is harder to crack via brute force and is far less likely to be written on a note attached to the screen.


When people type they make mistakes, called "typos". Normally people see their mistakes and correct them. For password entry usually you can't see what you've typed and therefore you can't correct your typos. You make mistakes without realising it, submit your password, and it comes back as "password invalid". Then you try again. Then you try again.

You can think of it as "3 minor little typos and then you're indistinguishable from a brute force attack". How do systems defend against brute force attacks? An explicit "Too many attempts, go away, you won't be able to log in even if you do get it right" response? Exponentially increasing delays on password entry leading to browser time-outs when the delay is too long, making it impossible to try to log in again? Approaches vary, but there's always a consequence in a well designed system.

You can think of it as "3 minor little typos and then you get some kind of denial of service".

As password length increases the risk of typos (and therefore the risk of denying an authorised person's access) increases. Anything longer than about 20 characters is going to be mistyped frequently (unless the user is smart/lazy and stores their password somewhere so they can "copy and paste" without worrying about typos, like a nice plain text file on their desktop called "passwords.txt").


It prevents the user from reusing passwords.

The user has a 20-character-long password with symbols like * and # (which are accessible on all keyboards, even phone call keyboards). But this user thinks this psasword is so safe, and nobody could have hacked it even if he gets pwned on some other website he uses the same password with (assuming the website uses a proper hashing algorithm).

Now he comes to this website that only allows [A-Za-z0-9]{8,16}. He can't use this password anymore. He is forced to choose another password. This ends the era of his 20-character-long star-hash-everywhere password. Now he is safe even if he uses the password on a site that does not hash the password.

Disclaimer: the user is me.

  • Being actively hostile towards the user barely makes for good security practice, in this case as well. Users will start appending numbers and letters instead of special characters and you will be left with the reduced entropy
    – user313675
    Jan 20, 2020 at 4:52

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