• United States




Winning the Password Probability Game-Reader Feedback

Feb 03, 20066 mins
Data and Information SecuritySecurity

Here is some of the feedback to my Password Probability column: ------------ Roger, Regarding your "Winning the password-probability game" article, I have been very disappointed with the number of financial institutions that prohibit special characters for use in passwords with which to access account information at their web site. Sincerely, Tom Kustner -------------------- You left out "keyboard" passwords. Pa

Here is some of the feedback to my Password Probability column:



Regarding your “Winning the password-probability game” article, I have been very disappointed with the number of financial institutions that prohibit special characters for use in passwords with which to access account information at their web site.


Tom Kustner


You left out “keyboard” passwords. Passwords based on the position of the keys. Some of these would include “qwerty”, “qwerty12”, “z1x2c3v4”, etc,

Another good source is ham radio call signs, i.e. KB8JNR.

Richard Fink


One thing that I have noticed people using for passwords are

keyboard patterns, such as wertsdfg or uiiphjkl. This is particularly

true with operating systems other than windows that aren’t

case-sensitive, like VMS.

Robert Gardner


Hi Roger,

Short version:

With regards to your recent article in Infoworld, you might take a look at John the Ripper and read about its Wordlist and Incremental modes of cracking. Of the password-cracking tools that I’ve looked at, it’s the only one I’ve seen that 1) allows you to create customized rules to intelligently attack passwords (wordlist mode), and 2) has functionality out-of-the-box to attack passwords with characters (like the number of 40 different characters or symbols you mention in your article) that are most likely to appear in passwords (incremental mode).A longer version than you probably wanted:

Note: My knowledge of John the Ripper (John) may be a bit outdated. I last worked with John version 1.6.36 and I see they have jumped from 1.6.40 to 1.7. Anyway, John has three cracking modes: single-crack, wordlist, and incremental. If you take a look at John’s config file, you’ll see the many predefined rules for its Wordlist mode with helpful comments that explain what each rule is doing, eg. taking a dictionary word and capitalizing the first letter or taking a dictionary word and appending the number 1 to the end of it. You’re also free to add your own rules if you like. John’s incremental mode uses something called frequency tables. My interpretation of that (which may not be entirely

correct) is to take the 95 normal keyboard characters (26 upper-case letters, 26 lower-case letters, 10 digits, and 33 special characters including space) and arrange them in order from most frequently used to least frequently used. So, for instance, take the 25 most common characters and try all possible 7-character passwords.

Once that completes, add the next character in the list to look for all possibly 7-character passwords with 26 characters instead of 25. John’s log file in versions above 1.6 is really helpful with its verbosity and timestamp for every entry. Just my opinion, of course.

Unsolicited feedback:

Two other factors that have significant bearing on the speed at which passwords can be attacked are 1) how computationally intensive the password hashing algorithm is, and 2) any weaknesses in the hashing algorithm (eg.

Lanman hashes convert all letters to uppercase before hashing and also split the password into two chunks of 7 bytes before hashing each chunk separately). I’m happy to discuss further if you have interest, but will leave it at that for now.Then you could consider a followup article along the lines of “You don’t need to guess intelligently when you can precompute all the password hashes”

and talk about Rainbow Crack and hashes that don’t use salts, like SHA-1, Lanman, and NTLM. All you need is lots of computing power, time, and lots of disk space.

Thanks for listening.

A Reader


Hi RogerI enjoyed your article about brute force password cracking. Someone’s probably thought of this before, but I’ve never seen this

idea proposed: Why not have a minimum login response time in order to foil brute force attacks. If every login attempt has to wait 3 seconds before a response it will certainly foil alot of brute force attacks.

Taking the idea further – the length of time for a response could be

inversely proportional to the complexity of the password – the password “tiger” would take 10 seconds to respond whereas “g%v#1wqp#$90n” would get a response in microseconds. Response time would the same for any password regardless of it’s validity.

This scheme encourages users to choose complex passwords – they are

rewarded with faster logins. On the other hand occasional users may

choose easier to remember passwords and put up with the login delay –

hopefully avoiding the post-it-note vulnerability.

Thanks for many interesting columns.

Todd Weiler,

Ragged Creek Software.

——————-This was an interesting article. I am confused, though, as to how

your suggestions differ from the practice of using Muffett’s crack

(possibly with custom rules) combined with wordlists of actual passwords.Using a tool such as uniq, multiple wordlists can be combined into one removing duplicates. Crack has had number/letter and generic x/y

substitution since at least the ’80s. It also knows how to reverse,

cap words and so forth.The only rule I am not sure how to implement is the second half of

rule 3 “caps near the beginning”. Yes, wordlists should be sorted in order of frequency of use, and that should not be too difficult to do, given a large number of wordlists of actual passwords.

Muffett’s crack is the cracking software used on UNIX, etc. For some time. It has rules allowing testing for 3->e, @->a and so forth. You can write your own rules. Uniq is a *nix tool that removes duplicate lines from files. So to get a list of unique words, concatenate some wordlists, sort the combination, and filter through uniq so only one copy of each word is in the file.

So maybe I’m confused. Maybe your suggestions are different than

those implemented by crack (and related tools), but I’m not sure how. Perhaps in a subsequent article you could compare the two approaches.



John McDermott, CCP

Writer, Educator, Consultant


1. The exec that comes up with the demand that we “make sure that our network and computers are fully protected” is usually the exec that

A) uses a password that hasn’t changed since university

B) uses no password at all as that is an inconvenience

2. If you set the policy to blank the username out whenever a computer is restarted or someone logs off users are much less likely to forget who they are. You won’t get the support call that starts “My password doesn’t work anymore”, followed by, “I don’t know what my username is, I just type in my password”

Peter MacEwen

MacEwen Consulting



Good article! It will be interesting to find out if your article stirs

up information on an existing product, or inspires someone to create just such a tool.

Another password construction habit which should be considered for the probability tool is “Key Proximity or Geometry”: i.e., cdfv1452, xzaq1369, or perhaps “corners” like: qpzm1793.


Mark R. Everhart



Roger A. Grimes is a contributing editor. Roger holds more than 40 computer certifications and has authored ten books on computer security. He has been fighting malware and malicious hackers since 1987, beginning with disassembling early DOS viruses. He specializes in protecting host computers from hackers and malware, and consults to companies from the Fortune 100 to small businesses. A frequent industry speaker and educator, Roger currently works for KnowBe4 as the Data-Driven Defense Evangelist and is the author of Cryptography Apocalypse.

More from this author