Before anyone attempts to close this question as a duplicate, please read this little blurb that shows up at the bottom of every closed duplicate question:

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

That is what I am doing right now.

There are several questions here pertaining to Stack Exchange's excessively complicated password requirements. They require any combination of at least three of the following:

  • lowercase letters
  • uppercase letters
  • numbers
  • special characters

And at least eight of the characters have to be unique.

What is the reason for this? This has come up recently because myOpenID has been down for well over 48 hours now. After concluding that they are probably down for the count and will not be coming back this time, I decided to look to other OpenID options. Facebook? No, I don't want to link my SE activity to Facebook because they tell me they want to share information. Yahoo! wants to also share information. Google wants to share information. It's just a Q&A site. Why do I have to go through all this?

Ah, I can create a Stack Exchange account! Sweet! But, wait a minute... they make me come up with a password that's sooooo secure that I have to write it down on a Post-it note where it runs the risk of being discovered. That's a really good idea, isn't it?

The most common response I see from commenters here in regard to why this excessively complicated requirement exists is because "It's not just a Q&A site, but an OpenID provider." So what? All the others are OpenID providers, too, but they don't force extreme password requirements on their users. What's the big deal? Can I get a detailed, sensible, and logical answer on this if nothing else?

So I suppose it's obvious that I am hinting at SE to loosen up these requirements a bit (okay, a lot). What's wrong with ditching the uniqueness requirement and simply requiring a mix/match of any two types of characters? For example, a mix/match of lowercase/number, lowercase/special, number/uppercase, etc? As long as the password contains any combination of two of the four types of characters, it passes. What kind of security is SE going for here when the only way someone can remember it is to write it down or store it in a text file on their PC? Can't we just get some simple Stack Exchange-only authentication that has nothing to do with OpenID that has lax password requirements? After all, if my password is aaaa and my account gets hacked, who's fault is that really?

It appears that no one in the other question posts is interested in fielding any further questions on this topic, so I am bringing it up again.

  • 5
    So, you suggest that an open ID provider should use fairly low security passwords that will allow anyone who managed to compromise them access to any other sites that use it?
    – Oded
    Commented Jul 7, 2013 at 19:54
  • 4
    Why not? As I said in the last part of my question, if my password is aaaa, who's fault is it that it gets compromised? Commented Jul 7, 2013 at 19:55
  • 21
    Obligatory: xkcd.com/936
    – user102937
    Commented Jul 7, 2013 at 19:55
  • 1
    @oscilating, security is best implemented in layers. Let the user come up with his own layers, as you say, but also let the program be robust in itself. Commented Jul 7, 2013 at 19:55
  • I knew I should have put nb4 xkcd at the end of my post. Commented Jul 7, 2013 at 19:56
  • 3
    Public opinion may very well blame the provider, not the user. Regardless, when it comes to an authentication scheme that can be used in many websites, you don't want it to be lax.
    – Oded
    Commented Jul 7, 2013 at 19:57
  • 1
    @Oded: Says who? I don't use easily guessable passwords myself, so this is not a problem for me. However, how many SE OpenID accounts do you think their are where the password is abcABC123!@#? Also, public opinion may blame the provider? Are you suggesting the provider could get sued? My bank doesn't even allow special characters in the password. Debit card PINs are only 4 digits. Who's at risk of liability here? Edit: Also see part of my post where I mention SE-only authentication that doesn't rely on OpenID. Commented Jul 7, 2013 at 20:01
  • 3
    It doesn't make sense to me either. I mentioned that here: security.stackexchange.com/a/3914/203 but they decided to go with those crazy requirements anyway. Commented Jul 7, 2013 at 20:06
  • If you consistently used secure passwords, I think you'd quickly find they're a lot easier to remember than you think. Why, just yesterday, I changed my Google password to 🍌 🍌 🍌 🍌 🍌 🍌 🍌 🍌 🍌 🍌 !
    – user206222
    Commented Jul 7, 2013 at 20:15
  • 11
    Please include at least 3 emojis and one instance of Zalgo text in your password
    – Ben Brocka
    Commented Jul 7, 2013 at 20:18
  • I remembered somewhat different criteria and just tried it again and I can't reproduce the rather insane criteria you listed. I only see the requirements for three different character classes and a minimum of 8 characters in the password. Commented Jul 7, 2013 at 20:20
  • 1
    @EmrakultheAeonsTorn pretty neat that SO realises it's your password and blanks it out... 🍌 🍌 🍌 🍌 🍌 🍌 🍌
    – hayd
    Commented Jul 7, 2013 at 20:22
  • Ooh that's awesome! 🍌 🍌 🍌 🍌 🍌 🍌 🍌 🍌 🍌 @hayd
    – Doorknob
    Commented Jul 7, 2013 at 20:25
  • 6
    @Oded Requiring special characters doesn't encourage more secure passwords. Please read our classic question. Commented Jul 7, 2013 at 20:34
  • 3
    @RobertHarvey Obligatory: xkcd.com/538
    – Cole Tobin
    Commented Jul 7, 2013 at 22:16

4 Answers 4


This question has been analyzed, from a technical perspective, over on IT Security.SE: see Appropriate password requirements for a login (OpenID) service/provider/delegate/thing. (See also Recommended policy on password complexity.)

For instance, I'll highlight my answer, where I argue against going overboard on password restrictions, based upon usability considerations. TLDR: If it's not usable, it's not secure, and putting too many restrictions on passwords leaves a system with poor usability.

I also recommend Kyle Cronin's answer, where he points out the unintended consequences of these requirements: they may cause many people to use other providers, which tend to have weaker password restrictions.

In other words, I agree with you that the requirements feel a bit excessive. I elaborate on why in my answer. I can understand why the StackExchange folks are doing it, and I'm sure their hearts are in the right place and they are doing it to protect their users, but nonetheless I think the current password restrictions are probably counter-productive.


I believe you are misinterpreting the requirements. From the post that Kyle Cronin linked in his comment:

  • Must contain 3 of: lower case character, upper case character, number, special character.
  • Cannot contain any public account field.
  • Must have at least 8 unique characters

You seem to think this means a minimum of 3 of each of those character classes. What it actually means is that you must have at least one character in at least three of the four classes. (and, of course, the minimum 8 distinct characters).

Now that you have edited the requirements down to the actual ones, the answer is that they are a fairly industry-standard set of rules, not a particularly strict one (even less strict than many sites I've come across).

  • Hmmmm....yeah. If you had to have 3 characters each from 4 different classes, then you would have to have 12 characters. If so, the 8 character minimum would be meaningless. That should be enough to let the OP figure out that his interpretation of the rules must be off. Commented Jul 7, 2013 at 20:36
  • I wish I took a screencap of whatever it was that was telling me 3 instances of each of the 4 characters. I didn't just make that up I swear. Besides, I edited my question. Still, this answer doesn't address my question as to why the PW requirement has to be so strict. Commented Jul 7, 2013 at 20:37
  • 4
    @oscilatingcretin the question has (or had, at the time I posted this) a false premise, namely that the rules are "so strict." Therefore, showing that the premise is false is a valid answer (potentially the only valid answer).
    – Kevin
    Commented Jul 7, 2013 at 20:42
  • 4
    Except that this doesn't prove that the premise (the rules are insane) is false. It just proves that the rules are different. They are still insane. Commented Jul 8, 2013 at 7:28

You're misinterpreting the requirements, you only need at least one character from three different character classes and not three characters from all four classes. Additionally there is a minimum number of 8 unique characters.

So 1Madscientist would be a valid password for an SE OpenID account. I personally don't find that too bad. For a short 8 character password requiring some diversity in character classes seems reasonable. It's a bit on the high end for something I would not care about, but anything I care about I would protect with a password that strong anyway.

This policy fails for pass phrases though, and that is something that might be nice to allow users more freedom to choose passwords while still encouraging reasonable strong ones. Something like dropping the character class requirements for passwords longer than 14-16 characters should allow for passphrases without actually lowering the standards. The drawback would be that explaining the specific criteria will get rather complicated and it could confuse users.

  • I edited my question. As I said to the other answerer, I swear I didn't just make those up. I swear to all that is good and great that I saw those requirements somewhere here before my very eyes. Still, I edited my answer to show the correct requirements. Commented Jul 7, 2013 at 20:38
  • From experimentation on the reset page: gizmo didn't eat chicken after midnight was accepted as a password, but ε †ζ ˆ;亀捒 popped up a request to add a capital letter, a lower case letter or a digit. Adding a digit didn't change the pop-up. I suspect, now that I know the rules, that 5tack-Exch@nge! would be accepted. (If your browser can't do Chinese, that's what was in my second experiment. I successfully used a Chinese phrase on another site.)
    – WGroleau
    Commented Mar 3, 2014 at 15:49

It needs:

  • At least 8 unique characters total
  • Out of the following categories of characters, pick 3 categories and have at least one character from each:
    • Digit
    • Upper case
    • Lower case
    • Special characters

Here is the relevant portion of the client side validation code (from here -- this code may be proprietary):

var minPasswordLength = 8;

var _hasLowerCase = /[a-z]/;
var _hasUpperCase = /[A-Z]/;
var _hasDigit = /\d/;
var _hasNonWord = /(_|[^\w\d])/;
var enforceRules = function () {

    var pw = password.val().toLowerCase();

    if (pw.length == 0) { return; }

    var hasLower = _hasLowerCase.test(password.val());
    var hasUpper = _hasUpperCase.test(password.val());
    var hasDigit = _hasDigit.test(password.val());
    var hasNonWord = _hasNonWord.test(password.val());
    var charClassCount = 0;

    if (hasLower) charClassCount++;
    if (hasUpper) charClassCount++;
    if (hasDigit) charClassCount++;
    if (hasNonWord) charClassCount++;

    if (charClassCount < 3) {
        var nag = 'Add';
        if (!hasUpper) nag += ' upper case,';
        if (!hasLower) nag += ' lower case,';
        if (!hasDigit) nag += ' numbers,';
        if (!hasNonWord) nag += ' special characters,';

        nag = nag.substr(0, nag.length - 1) + '.';

        nag = nag.replace(/(.*),/, '$1, or');



    var uniqueChars = uniqueCharacters(password.val());

    if (uniqueChars < minPasswordLength) {
        var remaining = minPasswordLength - uniqueChars;

        error.text('Must contain at least ' + remaining + ' more unique characters.');


    // don't bother enforcing this until the password is actually *good*
  • I hope they also validate this on the server. Firebug cough cough Commented Jul 7, 2013 at 20:52
  • @oscilatingcretin Yeah, they do. The code comments specifically call this "client side password validation", and it's only so that they can validate without a new pageload. Also, SE always checks things on the server side. Well, except for one particular type of request, and that is sort of by design. Commented Jul 7, 2013 at 20:55
  • Thanks for that CC-BY-SA proprietary code!
    – Cole Tobin
    Commented Jul 7, 2013 at 22:17
  • @ColeJohnson The code is not licensed. Commented Jul 7, 2013 at 22:19
  • @Manishearth where is that mentioned? From the footer: "user contributions licensed under cc-wiki with attribution required"
    – Cole Tobin
    Commented Jul 7, 2013 at 22:34
  • @ColeJohnson And how is the JS for openid.se a "user contribution"? Commented Jul 7, 2013 at 22:37
  • @ColeJohnson Oh, I see what you mean now. I'll edit it. Commented Jul 7, 2013 at 22:39
  • 7
    @oscilatingcretin we don't validate anything on the server, we totally trust you guys. Commented Jul 8, 2013 at 2:06

You must log in to answer this question.

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