Alphanumeric passwords with enforced numbers – more “Security Theatre”

Reading through TechCrunch’s Depressing Analysis Of RockYou Hacked Passwords:

According to a study by Imperva, [the most common password is] “123456,” followed by “12345,” “123456789″ and “Password,” in that order. “iloveyou” came in at no. 5.

I generate my passwords with APG, which generates passwords like this:

  • Irikyak6
  • RaypHiam6
  • radsErn2
  • reebrIjLi

As you can tell, these are for all intents and purposes, secure. However, some sites out there insist that the last one on the list is insecure. Why? It doesn’t have a number in it, so it must be terrible. 123456? That’s cool with them, though.

So riddle me this:

I’ve got a one character password. The password has to contain a digit.

What are the chances of guessing my password? Why, 1 in 10. I can’t use A-z, given the rules, so the password has to be a single digit, 0-9.


I’ve got a 1 character alphanumeric password. There are no rules about how many numbers the password must contain.

What are the chances of guessing my password now? Why, A-Z (1 in 26), a-z (another 1 in 26), and 0-9 (1 in 10): So your chances are 1 in 62.

The same thing applies in longer passwords: the more information you give an attacker about the rules associated with a password, the less work they need to do to crack the password.

A better solution? Integrate a library like cracklib and set some reasonable rules about what passwords are, and aren’t allowed. It’ll stop 123456 in it’s tracks.

Oh, and for goodness sake, encrypt your passwords when you store them in the database.

Shared Vocabulary, Problem Solving, and Domain Driven Design

In The Science of Screwing Up, Wired Magazine discusses Kevin Dunbar: “a researcher who studies how scientists study things — how they fail and succeed”.

When Dunbar reviewed the transcripts of [a meeting involving people from numerous disciplines], he found that the intellectual mix generated a distinct type of interaction in which the scientists were forced to rely on metaphors and analogies to express themselves. (That’s because, unlike [his comparison group of specialists,] the E. coli group, the second lab lacked a specialized language that everyone could understand.) These abstractions proved essential for problem-solving, as they encouraged the scientists to reconsider their assumptions. Having to explain the problem to someone else forced them to think, if only for a moment, like an intellectual on the margins, filled with self-skepticism.

Interestingly, the Domain Driven Design book makes a similar plea:

When domain experts use this LANGUAGE in discussions with developers or among themselves, they quickly discover areas where the model is inadequate for their needs or seems wrong to them. The domain experts (with the help of the developers) will also find areas where the precision of the model-based language exposes contradictions or vagueness in their thinking.

However, I find the essence of the two discussions to be slightly different:

  • The Domain Driven Design book encourages developers and architects to move towards one language, that can be shared between the stakeholders.
  • Dunbar found that the process of “working around” the differences in the languages and concepts produced the real results, of finding a common understanding.
  • I think the correct solution lies somewhere between these two extremes.