How programmers can easily choose strong passwords

Passwords are part of our lives, especially for us techies. When you think of the consequences of having your password compromised, you get a grasp on how important they are: the effects vary from discomfort and frustration to stolen money to stolen identity. Anything is scary enough to prompt us to be wary.

The possible attack scenarios that result in having our password compromised are very different, here are some examples:

• Phishing can trick you into giving away your credentials
• Trojans, viruses and other exploits could compromise your machine and grab what you type
• Man-in-the-middle attacks on the network could read your secrets sent on unencrypted (or poorly encrypted) channel
• Website security could be physically compromised, and the private data stolen
• Log-ins to websites could be discovered by brute force attacks
• Encrypted content could be decrypted with offline brute force attacks

In order to defend ourselves from some of these attacks (mainly the last ones), a strong password is required. But what is a strong password? Most guidelines tell us that:

• It should be long enough
• It must not be a “dictionary” word
• It shouldn’t contain “weak” patterns
• It should be composed of different character sets (letters, numbers, special characters)

The problem with these guidelines is that they clash with our brain’s ability to remember, because some of the things that makes a word stick in our brain are:

• Be short enough
• Be meaningful (like an existing word)
• Contain some sort of way to help remember it from other things (patterns)
• Phonetic (alphabetic)

For this reason, choosing a password is always a trade-off between security and usability. Sometimes websites enforce these policies, sometimes they give you a hard-to-remember password themselves. The famous webcomic XKCD tackled the problem in this strip, suggesting a simple method for common people to choose strong pass phrases. But in my opinion things can be even easier for a particular subset of people.

I assume most of my readers are programmers. We have a very peculiar job, we type stuff on our keyboards that doesn’t have any sense for the common people, but for us it sure has. We type so much that the muscles of our hands memorized the motions, together with the position of some unusual characters such as the “[ ]” square brackets, and we can type without even looking. Sometimes, especially after we debug an ugly problem, we examined a particular snippet of code so much that we can write it immediately off the top of our heads.

I believe programmers develop throughout the years a familiar way to remember and write strong passwords which are harder for computers to guess than the norm. If you’re a programmer, this is what you can do:

1. Pick a language that you are experienced with,
2. write a short piece of code,
3. insert letters, numbers, and special characters,
4. insert some kind of information related to the website (if it’s an online password) or the date (if the password expires regularly)

For example, I created one of the simplest examples I could think of:

 W = printf("93\n");

I am experienced in C programming, and inserted a “W” in the code to hint to WordPress site. How easy is it to remember? Easy (I print 93 and put the number of characters in “W“). How easy is it to write? Easy (if I don’t forget the semicolon). How hard is it to guess? Let’s see… I used the following online calculators to get their “opinion” on the strength of this password:

• Password Strength Test – Rumkin.com – Rumkin.com
• GRC’s | Password Haystacks: How Well Hidden is Your Needle?
• Password Strength Estimator

The results are that my 19-character password is strong, the character set is about 93 to 95 characters (between letters, numbers and specials, depending on how you divide them),  and the entropy is between 84 and 125 bits. To make some comparisons using the XKCD examples, the password “Tr0ub4dor&3” is 11 characters, a charset of 72 to 95, and an entropy of 51 to 72 bits. The password “correct horse battery staple” is 28 characters long, with a charset of 27 to 59 characters, and an entropy of 104 to 165 bits.

Using a method similar to XKCD I say that, knowing that the password is a piece of code, we have:

• Something like 20 possible common programming languages
• A hundred possible patterns (very conservative)
• Something like 5 different coding conventions (such as where to put the space)
• One function name/keyword, chosen from hundreds of possibilities
• Two short common variable names/strings, composed of up to four characters
• Each has a charset of size 64 (lowercase, uppercase, numbers, underscore and dot)

It results in this number of possibilities:

20*100*5*100*((64^4)^2) = 2.8*10^20

This number translates roughly into 68 bits of entropy.

I can think of some of the “cons” of choosing a line of code as a password:

• Many programmers are used to look at the screen while writing, to have a feedback that the code they’re writing is correct. With passwords you can’t see what you are typing.
• If you use an existing line of an open source software you are working on, then you could theoretically be more vulnerable to a dictionary attack tailored for you.
• Code written in a language obeys to common patterns derived from the syntax.
• If you are on a different PC, the language of the keyboard may impede the correct typing of the special characters.

In the end, I am not saying that if you are a programmer you have to use a line of code as a password because it’s the best way. I’m suggesting that this choice has many benefits for the common programmers, because it exploit some qualities of the programming work to shift the compromise between security and usability. But in the end it boils down to finding the place in this compromise where you personally feel comfortable.

Tagged: brute force, code, dictionary, encryption, entropy, hacker, password, password strength, programming, protection, xkcd

Posted in: Security