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
    Jul 7 '13 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? Jul 7 '13 at 19:55
  • 21
    Obligatory: xkcd.com/936
    – user102937
    Jul 7 '13 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. Jul 7 '13 at 19:55
  • I knew I should have put nb4 xkcd at the end of my post. Jul 7 '13 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
    Jul 7 '13 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. Jul 7 '13 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. Jul 7 '13 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
    Jul 7 '13 at 20:15
  • 11
    Please include at least 3 emojis and one instance of Zalgo text in your password
    – Ben Brocka
    Jul 7 '13 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. Jul 7 '13 at 20:20
  • 1
    @EmrakultheAeonsTorn pretty neat that SO realises it's your password and blanks it out... 🍌 🍌 🍌 🍌 🍌 🍌 🍌
    – hayd
    Jul 7 '13 at 20:22
  • Ooh that's awesome! 🍌 🍌 🍌 🍌 🍌 🍌 🍌 🍌 🍌 @hayd
    – Doorknob
    Jul 7 '13 at 20:25
  • 6
    @Oded Requiring special characters doesn't encourage more secure passwords. Please read our classic question. Jul 7 '13 at 20:34
  • 3
    @RobertHarvey Obligatory: xkcd.com/538 Jul 7 '13 at 22:16

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. Jul 7 '13 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. Jul 7 '13 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
    Jul 7 '13 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. Jul 8 '13 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. Jul 7 '13 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
    Mar 3 '14 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 Jul 7 '13 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. Jul 7 '13 at 20:55
  • Thanks for that CC-BY-SA proprietary code! Jul 7 '13 at 22:17
  • @ColeJohnson The code is not licensed. Jul 7 '13 at 22:19
  • @Manishearth where is that mentioned? From the footer: "user contributions licensed under cc-wiki with attribution required" Jul 7 '13 at 22:34
  • @ColeJohnson And how is the JS for openid.se a "user contribution"? Jul 7 '13 at 22:37
  • @ColeJohnson Oh, I see what you mean now. I'll edit it. Jul 7 '13 at 22:39
  • 7
    @oscilatingcretin we don't validate anything on the server, we totally trust you guys. Jul 8 '13 at 2:06

You must log in to answer this question.

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