I run CloudCracker, so I can add some color. 'English' dictionary jobs use dynamic models built by password compromises from english speaking users, augmented by the results of our own jobs (as well as occasional brute force jobs we run against a sample of handshakes which didn't crack).

The smaller 'English' dictionaries focus tightly on that. The larger 'English' dictionaries include the longer curve of those passwords, but also start to mix in the hot spots from other models, such as valid NANP numbers (which is what got this example).

Look at it this way. Lets say I give you 5 characters to create a password. If you use all numbers then each value can be anywhere between 0 to 9. That's only 10 values! So that's 10 to the power of 5. That's only 100,000 permutations.

With letters, assuming standard English, you get 26 per value. Or 52 when we include case. That's a big difference. So lets say I only give you 4 lowercase characters. That's 4 to the power of 26. 456k permutations. So almost 5x more secure with less characters!

Your offline password cracker can crack numeric only passwords with ease. Heck, if you know who supplied the access point, you can narrow your search. For example I have uverse and I got a 10 number password by default, just like all uverse customers. So if you know its a uverse customer you can tell your cracker to focus on 10 digit permutations. There's only 10 billion permutations there. With 10 lowercase letters its 141 trillion.

Sounds a lot like my bank. 5 characters of 0-9 is exactly what they validate their passwords on. Luckily that validation is done only in Javascript, so disabling the check allows you to use any password you want. That doesn't help the average person though.

So you actually tricked the server into setting a password it usually wouldn't accept? Uh oh, hope they don't "fix the problem" by adding similar validation on the server side later :P

I would ask "Why are they still your bank?" but I know that most online banking is similarly awful.

Most likely all the numbers up to 10 digits long were in the dictionary.

tl;dr of this article: don't use stupid passwords.

Edit: the article mentions it was a phone number, so that narrows it down a lot.

I'm assuming the ten character all numerical password was a phone number. Phone numbers have discernable patterns, like area codes.

Yes. The exchange (middle three for US numbers) also has patterns. More on the allowed codes is here:

http://en.wikipedia.org/wiki/North_American_Numbering_Plan

although, in practice, many of the allowed codes are not occupied. For instance, no exchange around LA would be 213, and no exchange near SF would be 415.

Surprising considering that the latter has less than 2 bits more entropy.

By my math, a 10 byte sequence of decimal numbers has 33.2 bits of entropy, while a 8 byte sequence of lower case numerals and decimals has 41.3 bits. That's almost 300x as hard to crack.

There's also the issue of pattern heuristics. Number-only passwords seem like they'd be common, and thus a reasonable pattern to try out to ~35 bits or so (something that corresponds roughtly to "can be tried in a perceptively short time"), but it's not as clear that there's a significant fraction of passwords in the wild that use alphanumerics but no capitals. So they wouldn't try the passwords from the 36-character alphabet, more likely using a slower heuristic like things where the leading alpha character might be capital, or there might be punctuation between "words", etc...

All-number passwords are default on several ISPs so they're much more likely to succeed than a full keyspace search.