There are some websites and even programs that I use that have ridiculous password restrictions. Lots of forums for instance restrict passwords to ~32 characters. Others enforce a restricted charset.

What would cause a developer to put in such restrictions? As long as you do the initial hashing of a password on the client, there is no load on the server for having to calculate the hash of enormous auto-generated passwords. There seems to be no benefit of using such restrictions

  • Since my first question missed the mark, I provide a separate answer. The primary reason is that limits are required. Although the concern regarding the storage space and the marginal load of calculating the hash of an arbitrary length chunk of data is accurate, there are some issues.
    – ygjb
    Jan 10, 2011 at 1:25
  • 3
    You don't do the initial hash on the client side. If you did, it would mean that a bad client could just use the hash as the password, thus reducing the password strength down to whatever your hash size is :)
    – Bill Weiss
    Jan 10, 2011 at 1:49
  • @Bill I was thinking more of securing the password when https isn't available, then adding your salt on the server. But thats off topic.
    – TheLQ
    Jan 10, 2011 at 2:34

5 Answers 5


I think the reason is the same as for any other input validation; to make sure it doesn't cause any problems during processing and storage. Now, for passwords this is of course completely misguided since they should be hashed and therefore neither stored nor really processed in cleartext.

I'd take any such limitations as an indication that the developers don't know what they're doing securitywise, and are probably going to store the password in cleartext. Stay away.

  • +1, my thoughts exactly. However, it is also possible that they are symmetrically-encrypting the password (instead of hashing it), in which case it would still be limited, by some arbitrary long-but-not-long-enough size of field. Also, limitations on characters are also a misguided attempt to simplify comparisons.
    – AviD
    Jan 10, 2011 at 1:23
  • 2
    Symmetrically encrypting the password is most often a sign to stay the hell away from somewhere. Yes, there are times it's required or even a good way to go, but they're rare.
    – Bill Weiss
    Jan 10, 2011 at 1:50
  • @Bill, oh I agree. Just pointing out that there are times where its not hashed, and yet still have the restriction. Also, symmetric encrypted passwords are not as bad as plaintext, but it is (usually, as you said there are times when its right) a good sign the developers are misguided.
    – AviD
    Jan 10, 2011 at 5:47

I'm going to go with: the same old reasons people do strange things.

  • Because it seemed like a good idea at the time. Developers might be well-intentioned but poorly informed. There's no need to limit password length, but maybe developers aren't aware of that. Maybe developers didn't even think about it.

  • Because it was easier than the alternatives. Maybe they are using an API that can't handle arbitrary-length passwords; that might make it easier to just limit password length than to use a better API. Maybe they have SQL injection flaws in their database, and rather than coding things properly to avoid the SQL injection flaw, it's easier to just blacklist some characters (e.g., forbid users from including single quotes in their passwords). Maybe for some reason it was easier to use a fixed-length array than a variable-length string. Who knows.

Bottom line: there's no really good justification for such limits. I'm sure we're used to the fact that commercially available software often contains all sorts of strange design misfeatures. It happens. It's a fact of life. It's a consequence of the fact that "good-enough" is a lot cheaper than "perfect".

  • But no reason to allow really long passwords. There are so many useful alternatives that offer more security, less chance of errors etc.
    – Rory Alsop
    Jan 10, 2011 at 8:19

A rational reason for limiting password length and possible charset is to prompt the user into applying proper password management techniques. In plain words, if a password is huge or full of weird characters, then this increases the likelihood that the user will write the password down on some piece of paper (traditionally glued under the keyboard) and/or reuse the same password into several systems.

Conceptually, how the user manages his own passwords are his responsibility, and none of the website business. But, in practice, users are security-wise clueless and cannot be bored with anything which does not have an immediate retribution (especially when users are potential customers). So it is up to the website to try to do what it can in order to protect the user.

Note that I do not claim that trying to enforce good password management is the reason why any given site limits password length; it is just a reason why I would envision a password length limitation on my own site (if I were to manage a website with user passwords).

Another rationale for limited allowed charset is to promote interoperability: preferably, the user should be able to type his password on a wide range of input devices. Non-ASCII characters are not good for anything which looks like a US keyboard (it is possible to type non-ASCII letters on a US keyboard, I do it all the time, but methods vary depending on the operating system and configuration, and do not work well with blind typing as is customary with password entry). Smartphones have even greater restrictions. There again, interoperability is (in my view) a good reason to enforce a limited charset, but many websites will have such a restriction for bad reasons (e.g. so that the password can be carelessly dumped into a SQL request without proper string escaping, something which can only be described as sloppy engineering).

  • There are good reasons to encourage or even enforce strong passwords, but I think nine times out of ten what happens is people invent a strong password, and then write it down on a post-it. A weaker password that they then memorized would arguable be more secure. Apr 16, 2014 at 6:45
  • 2
    @Shadur I don't necessarily agree. Though writing down a password is less secure than memorizing it, it is not always feasible to acquire such written passwords. In high security contexts this might be true but for public websites with a huge Userbase it is less likely that such a password will be searched for and stolen. Her a weak password is worse than a written password. Dec 19, 2014 at 18:31
  • In plain words, if a password is huge or full of weird characters, then this increases the likelihood that the user will write the password down on some piece of paper (traditionally glued under the keyboard) and/or reuse the same password into several systems. – (Almost) all my password are long, site-specific ASCII-fied hashes (which I did not write down but generate when I need them). Imposing restrictions keeps me from using those safe passwords.
    – Wrzlprmft
    Jul 13, 2016 at 9:05

I thought we had a question like this but either my search-fu is weak tonight or it was on another site.

Basically, in most applications or databases it makes sense to define useful limits on input strings. This lets you stop input once the limit is reached (which can avoid overflows etc) and also ensures you can predict code performance.

Also you may need temporary storage while validating passwords before they are hashed - again, allowing arbitrarily long input can cause problems.

As to why 32? A reasonable figure for the majority of purposes - the entropy in 32 chars is huge. Of course in some environments this will not be enough, but for many of them a cert or 2nd factor (such as a token) may be more appropriate anyway.

  • While I agree that their should be some limits to prevent people from generating 10,000 character monsters, restricting to 32 characters and blocking certain characters serves no purpose. Unless your at a extremely active site, 100 of all characters (including unicode) adds little computational overhead.
    – TheLQ
    Jan 10, 2011 at 2:32
  • I think this answer is circular. The questioner asks, "why are there limits?". You reply, "Because it makes sense to have limits." But that just begs the question, "Why does it make sense to have limits?". Personally, I doubt very much that developers thoughtfully weighed the alternatives at length and, after deep contemplation, decided that a 32-character limit is ideal and superior to all alternatives. I suspect it's more likely that the developers were more focused on other things and a 32-character limit is mostly an accident.
    – D.W.
    Jan 10, 2011 at 4:23
  • I totally agree this is almost certainly not a calculated figure. That isn't what I meant. You absolutely would not want people to have to put in very long passwords - above 30-odd it makes no sense to have a password as you just leave yourself open to mistakes in typing etc. For the extra security, use something more suited to the job, like a cert or token, as I mentioned. Makes much more sense than typing in a 200 char passwords for example.
    – Rory Alsop
    Jan 10, 2011 at 8:18
  • @Rory, but why would it make sense to put any limit on the password length? it all gets hashed down to the same length, and if a user WANTS to punish himself in order to get "more" security, why not? Don't forget that he might not be typing it in himself - there are plenty of clientside tools (e.g. PassSafe) that do it for you.
    – AviD
    Jan 11, 2011 at 6:50
  • @AviD - my thinking is on the stages that occur prior to hashing, you need to handle the string in a controlled manner. Agree with you on PassSafe though - I do use it for holding some logon credentials where the application doesn't allow certs or tokens.
    – Rory Alsop
    Jan 11, 2011 at 8:30

Since my first question missed the mark, I provide a separate answer. The primary reason is that limits are required. Although the concern regarding the storage space and achunk of data is accurate, there are some issues.

First, if you read my original answer below you will see that one of the recommendations is iterative hashing (i.e. pbkdf). This requires a large number of iterations in order to be truly effective. If a user is able to submit a large string, then the cost of computing this iterative hash value quickly becomes more expensive than expected for a simple authentication function.

Any single computationally expensive task on a server, especially one that is explicitly available for an unauthenticated user, is subject to abuse by a malicious user to perform a denial of service attack.

Second, by implementing a fixed length password it provides an opportunity to terminate early if an extremely long request is submitted. If the parameters in the request are outside of the expected length it is simple to issue an error message and close the connection.

The reason that password complexity requirements are enforced on many sites is to prevent users from choosing a weak password. There are numerous examples in recent history which show that most users will select weak, easy to enter, easy to remember passwords over complex passwords. When this occurs, the owner of the site is placing themselves at risk as users will invariably blame the site if a password is stolen or cracked, and whatever outcome that may have to both the site and the affected user.

By implementing strong password requirements, it reduces the likelihood that an attacker can easily guess the password. Passwords also need to be protected against two different attack paths. The first, online attacks, requires that a site developer have a policy that will prevent brute force attacks from succeeding. This is accomplished by requiring that a user select a suitably long, complex password, and restricting the number of failed logon attempts before slowing (i.e. temporary lockouts, captchas, etc) or stopping attempts to login (permanent lockouts, mandatory password reset, account confirmations, etc).

The second attack is an offline attack, where an attacker will acquire a copy of a password database, and attempt to use a rainbow table or offline password cracker to crack multiple accounts. This type of attack is prevented by using a strong hashing algorithm in conjunction with a per-user salt, and preferably pbkdf2 or bcrypt/scrypt style rehashing to increase the computational cost of offline cracking.

Ultimately, both of these techniques fail if sites don't encourage users to select a unique password for their various accounts. Many users will select the same passwords for multiple account, and when that password is exposed, especially with their email account, it is possible for an attacker to use that credential on another service. For this reason it is best to generate unique, strong passwords for each site, or at least different groups of sites and use a secure password manager to store all of the different passwords.

  • 2
    think the OP was wondering why the password was restricted to such a short length, rather than letting him input a much longer password.
    – Rory Alsop
    Jan 10, 2011 at 1:07
  • Hmm.. re-reading the question, you might be correct. Either way, hopefully my answer is useful to someone ;)
    – ygjb
    Jan 10, 2011 at 1:12
  • Baloney. Long passwords are not going to be an effective DOS attack. I don't buy this answer at all.
    – D.W.
    Jan 10, 2011 at 4:20
  • 1
    Though I agree that long passwords will not contribute to DOS - hash is extremely efficient, even with moderately long strings. Okay, hashing War and Peace might cause a performance hit, but anything reasonable - even hundred characters - would be negligible. Furthermore, as far as repeated hashing (pbkdf) goes - after the first hash, you will always have the same length output....
    – AviD
    Jan 10, 2011 at 5:53
  • 2
    @ygjb, it you're doing a thousand hash iterations for each password, you're doing the same thousand iterations, no matter how long the password is. Except for the first iteration, ALL the other iterations work on the same amount of data: the output of the previous iteration. E.g. 512b (for SHA-512). The length of the original data is relevant only in the first iteration, after that you're dealing only with hash outputs (which are identical in length).
    – AviD
    Jan 11, 2011 at 6:53

You must log in to answer this question.

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