A three-digit password is not "too long."

October 20, 2009 3:46 PM

The Blurst.com registration page tells me my (12-character) password is too long, while a string of 100 A's is OK. FFF is a fine password, but 777 is too long. What gives? (Somewhat long but delightfully pattern-y description follows)

Let's say my chosen password is 99clobdatz47. This, it tells me, is too long. 99clob47, which is only eight characters, is also deemed too long. I then try just clobdatz, another eight-character password, but this time I'm told it's OK! In fact, clobdatz4799 is OK as well. Testing my hunch that it's those leading 9's causing the problem, I discovered some interesting patterns.

First off, passwords must be at least three characters. Two-character passwords are too short, and three-character passwords are OK, with the exception of passwords beginning with two numbers. For these, the following rules apply:
- Any three-digit permutation of the numbers 1-9 (0 is exempt) is too long. For example,
3: too short
33: too short
333: too long, and

4: too short
47: too short
479: too long, but

000: OK. (00 is still too short, but there's no commentary at all on a single 0) This has held up for every set of three numbers I've tried.

- Any two numbers followed by a letter will be "too long," UNLESS the first number is a 1, in which case it's OK regardless of the second number, e.g.

23b: too long
75x: too long
94d: too long, but

11k: OK
17a: OK
14m: OK. 111 is still too long.

- When you start messing around with zeros, things get extra screwy. For "number-number-letter" passwords, a 0 in the second place acts as any other digit would, making the final result "too long," unless the first digit is a 1 or 2. It makes no difference in "number-number-number" passwords.

30k: too long
90d: too long

10g: OK
20z: OK

100: too long
206: too long, and so forth. For numbers beginning with 0, a (non-zero) number in the second and third places will make it too long, unless the second number is 1, in which case the third can be any number, or if the second number is 2 followed by a zero. Any number can be in the second place if a letter is in the third. If the first two numbers are zeros, any number or letter can be in the third. A number followed by two zeros is still too long.

064: too long
053: too long
030: too long

017: OK
011: OK
019: OK

020: OK
025: too long
028: too long

07s: OK
03m: OK
02w: OK

003: OK
008: OK
00t: OK

900: too long
600: too long

- Finally, there doesn't seem to be any password that actually is too long, provided it doesn't start with two digits. 100 A's in a row was fine, as was the letter B followed by several dozen 8's.

So my question to you is simply, "Why?" It seems unlikely that these patterns were intentionally implemented, so how could they have arisen? If no password is in actuality too long, why use that as a reason for limiting passwords at all? Why are 1 and 2 special? Why any of it?

I'm open to both informed answers from knowledgeable sources and wild mass guessing. Thanks, all.

posted by Captain Cardanthian! to Computers & Internet (14 answers total)

Response by poster: Yay! Thank you, modfairy!
posted by Captain Cardanthian! at 3:55 PM on October 20, 2009

Sounds to me like whoever implemented their password rules mixed up error messages, or lazily never corrected them. It's incorrectly saying "too long" when it really means "too uniform" (i.e., not enough variation) or something. Obviously I'm only guessing.
posted by axiom at 3:56 PM on October 20, 2009

This sounds like a job for StackOverflow, they're good at this sort of thing.
posted by nomad at 4:16 PM on October 20, 2009

I think axiom's right about the "too long" being a function of that being the only error message other than "too short". As for why it considers some of those erroneous, and some not... well, I have some speculation that I can't consider likely, but the behavior is so weird, whatever the answer is would probably seem unlikely.

Maybe some programmer(s) acting on a series of half-clever ideas are hashing the candidate passwords according to some homemade hash algorithm. Then they compare the hashed result to their own rainbow table of the results of applying their homemade hash algorithm to some large lexicon. If they find a match, they reject the password, reporting an error, in this case, "too long." The intent is to reject over-obvious passwords. But because of some inherent stupidity in their homemade hash algorithm, they disproportionately find such matches with passwords that begin with numerals.

(If any of this is right, it would qualify for the Daily WTF several times over.)
posted by Zed at 4:16 PM on October 20, 2009

Best answer: I think the reason it's failing is because the maximum password length is 20 characters, and the code is incorrectly parsing the actual string, rather than the length of the string.

I'm guessing the code has something like

if ( $password > 20 ) {
print "too long"
}

Instead of

if ( length($password) > 20 ) {
print "too long"
}

The language that the site is written in probably allows this comparison as long as the string starts with an integer. So if you enter "900blabla", the code will make a comparison with "900". But if you enter "abcdefg900", then the code probably will probably compare against 0 or perhaps always fail.
posted by helios at 4:26 PM on October 20, 2009 [2 favorites]

Best answer: Hmm. I'd guess that maybe they're doing something like accidentally assigning the value of what you type to the variable instead of simply incrementing the variable by one each time you type a letter. And then it's doing a comparison that is supposed to be "Is this variable greater than 20?". But it's comparing a string instead of a number, so it turns into a weird alphabetically greater than 20 check, hence the strange results.
posted by team lowkey at 4:29 PM on October 20, 2009

Yeah, that's a much better explanation.
posted by Zed at 4:32 PM on October 20, 2009

Yeah, that sounds typical of the validation idiocies that regularly turn up at the Daily WTF.

Why? Probably because the person responsible for coding the password validator is about as competent as the person responsible for designing the look of that site. Yeurgh.
posted by flabdablet at 4:34 PM on October 20, 2009

Response by poster: Ah, that makes sense. Or at least it makes no sense in a way that makes sense.
posted by Captain Cardanthian! at 4:40 PM on October 20, 2009

Best answer: Wha? Trying again on the code paste, this time with character codes for greater/less than symbols to avoid Metafilter stripping...

if(empty($password))
    result('password', 'Pick a password.', 0);

if(strlen($password) < 3)
    result('password', 'Too short.');
    
if(strlen($password > 20))
    result('password', 'Too long.');

posted by matthewwegner at 5:17 PM on October 20, 2009

To be clear, that's the actual code from Blurst's registration check (at least for the website--we have a different pathway when you register from within Unity content, which most people do). The theories on rainbow table hash lookups and the like are greatly over-complicating things; it was a typo ;)
posted by matthewwegner at 8:46 PM on October 20, 2009

Response by poster: And now it's fixed! Thanks, matthewwegner.
posted by Captain Cardanthian! at 9:10 PM on October 20, 2009

Might I ask why the form in question now has:

 input type="hidden" name="destination" value="http://ask.metafilter.com/135998/A-threedigit-password-is-not-too-long"

posted by signal at 11:25 AM on October 21, 2009

@signal: If something doesn't pass in a destination URL we use the referrer. I suppose I could limit that to within blurst.com, to avoid weird bounces back to other sites, but we never really expected anyone to link to it for any reason.
posted by matthewwegner at 4:11 PM on October 21, 2009