11

Possible Duplicate:
Can Stack Overflow change the password criteria?

The StackExchange account passwords requirements are quite onerous, arbitrary, and undocumented, particularly the requirement of requiring 8 unique characters. Because of this (and other) arbitrary requirements, "Password1" is valid, but "kejkld%&#dswilk" and "h^e2!@^2eKh!e@2" are not. The obvious alternative is to use a different provider (because no other provider has such strict requirements) but then what is the point of even maintaining the Stack Exchange provider? The reason I'd prefer not to is because my provider is Gmail and I have enabled 2 factored authentication which makes it more time consuming to log in and I delete history/cookies every day.

Try it for yourself here.

Note: This is a formal feature request based on this rant.

Improve this question
7
  • 2
    besides this xkcd makes much more sense anyway
    – z -
    Feb 22 '12 at 20:04
  • 2
    It's funny (to me) that you should mention bank security, since I just read this TDWTF a few hours ago.
    – Pops
    Feb 22 '12 at 20:04
  • Banking sites are notoriously insecure; they're not our standard here. Moreover, you seem to be under the misguided assumption that passwords become more secure when you add in more special characters. That's not really the case. Longer passwords ramp up the entropy much more quickly and make cracking exponentially more difficult. The point of the SE provider is for those who want to use it; it was much-requested by the community. If it doesn't fit your needs, then you are not compelled to use it (for example, I use Google). But certainly those who do use it appreciate a focus on security.
    – Cody Gray
    Feb 22 '12 at 20:28
  • 1
    This is not a forum site, and because it's an OpenID provider, it provides (or at least has the potential to) authentication to a number of other sites, some of which you might care about being secure. You seem quite worried about the fact that these password requirements are "non-standard". The reality is, fortunate or not, there is no such thing as a "standard" password complexity requirement. No one has standardized this. So it's hard to tell what you're looking for, other than "there shouldn't be any requirements, I should just be able to use the same password I always do". Which...no.
    – Cody Gray
    Feb 22 '12 at 20:34
  • Actually, "Now go be an ass to him instead." is a very secure passphrase.
    – user1228
    Feb 22 '12 at 21:10
  • 1
    Most of my passwords are randomly generated sequences of lowercase letters, with some digits thrown in if necessary, largely because such passwords are much easier to enter on mobile devices. htqwfgalbdbm is a perfectly good password. The problem (for which I don't offer a solution) is that it's difficult to design a heuristic that rejects Password1 but accepts htqwfgalbdbm. Loose requirements are great for those of us who know what we're doing, and dangerous for those who don't. (And my mother's maiden name is "Bbdoiolholhj".)
    – Keith Thompson
    Feb 22 '12 at 21:52
  • Why not just use Facebook login? eh? eh? See what I did there? ;)
    – Lix
    Mar 7 '12 at 18:55
11

I have to agree. Passwords should be up to the user, and I don't believe that the provider really has any right to force a user to do any certain things with their password. I, myself, implemented a simple check that notifies the user of their weak password choice, but provides a checkbox stating "I understand the system sees my password as weak, but I wish to use it anyways." If the user really wants to use their weak password, that should be their prerogative. Whether or not it's an OpenID provider shouldn't make any difference. They would most likely use the same crappy password on any other site they visit anyways, so forbidding weak ones here doesn't really prevent anything.

As a service, you can always encourage users to find a better password, but preventing them from using their own password is just wrong. How secure they want to be should be up to them. That's what disclaimers are for. The only requirement I see being actively enforceable is a minimum length.

Improve this answer
2
  • 1
    Why not just use one of the other OpenID providers that provides a more lax security model you find more comfortable?
    – Cody Gray
    Feb 22 '12 at 20:31
  • 3
    They also use different colors on their sign in page. What's your point? There's a reason we provide all those different options. You should feel empowered! Instead, you're complaining. Guess you really can't please everyone. Everything they implement for their OpenID provider is going to be an "arbitrary" requirement by definition.
    – Cody Gray
    Feb 22 '12 at 20:38
4

I can't answer the feature-requestness, but -1 to your question for the following reasons (this was too long to post as a comment):

  1. "kejkld%&#dswilk" Message: Add upper case, or numbers.
    If you're going to have a long-length password with arbitrary characters, how is it onerous to require a certain number of numbers, special characters, and upper/lower-cased letters? "kejkld%&#dswilk" is not valid, but "kejkld%&#dswilk1" and "Kejkld%&#dswilk" are both valid.

  2. "h^e2!@^2eKh!e@2" Message: Must contain at least 1 more unique characters.
    Same as bullet #1... if you're putting in a long list of random characters, is it difficult to add more unique characters to your mix? I still don't consider this to be onerous.

  3. The requirements are "undocumented"
    While they may lack a formally-published paper, the form is quite happy to tell you what is wrong with your chosen password:

    1. "a" = Add upper case, numbers, or special characters.
    2. "aA" = Add numbers, or special characters.
    3. "aA1" = Must contain at least 5 more unique characters.
    4. "aA1bB2cC" = no error message

Further to the above, Jeff's blog stated a while back that he prefers passphrases over passwords and the Stack's provider reflects this. "I have only 9 fingers!" is a valid password. "Why don't you have lax password requirements‽" also appears to be valid.

I don't use Gmail's 2-factor authentication so I'm not sure how it impacts the process. Does Gmail force you to use a password that does not meet the requirements? Short of a pure incompatibility, I don't understand how the requirements here are onerous, undocumented, or unnecessarily strict.

Improve this answer
2
  • I think this is an answer to the feature request. Basically, it says "we shouldn't do this because your assumptions are wrong".
    – Cody Gray
    Feb 22 '12 at 20:32
  • @CodyGray I didn't want to seem presumptuous in answering a question that is implicitly directed at the SE team. I'm just an eavesdropper who couldn't keep his mouth shut. =)
    – Farray
    Feb 22 '12 at 20:35

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