[impuLsivE]

Original Source: http://www.corvusconsulting.ca/articles/20...rds-part-4-of-4

So far in this series of posts about passwords, I’ve returned to the idea that as a technology, passwords have a both material and methodological aspects. That is, how you use the technology is as important as how advanced its parts are. So far, this discussion of improving passwords has largely focussed on the material side, namely OAuth and OpenID, and password interfaces. These improvements happen at the will and ability of the people making web and desktop applications. As such, users will always be waiting for them to happen if they haven’t already. This post takes things to the methodological side, which is more the user’s domain, by describing the rules I use to make strong yet memorable passwords that are unique for each account.

There’s a disclaimer (there’s always a disclaimer): I’m not a security expert. I’m offering my method as one that works for me, but hasn’t been robustly tested by people who get paid to robustly test these things. However, to bring an objective measuring stick, I’ll use the password assistant in OS X’s Keychain application. This feature is one I didn’t know about for a long time, but I think it’s pretty nifty; take a bow, password assistant:



As discussed in Part 3 on password interfaces, Apple does well in providing tips and warnings to help a person create a strong password. Taking those tips further, the method I describe here uses chunks of retrievable information as constituents of the password. As I describe the parts of the method, or the chunks, I’ll use the password assistant to test the method’s outputs.

My rule for a strong and memorable password practice has three variables or components:

A. Dictionary or Foreign word
B Significant Year, (not a birthday, it’s too obvious)
C. Fragment of the application or website name where the password is being created

A and B don’t change much from one password to the next, and is used in every password the rule generates. Component C, however, does change for every application or website, meaning that each password is only used in one place.

Let’s look at some details of each component and how they build the strength of the password.

A. Dictionary or Foreign Word
When choosing a word, aim for something between 4 and 6 characters. This gives you a wide range to play within, and allows you to pick a word that is personally memorable. There is a great advantage to choosing a word from a foreign language, in that it’s unlikely to be included in dictionary attacks, a basic tool in any password cracker’s toolkit. Don’t know a word from another language? They’re easy to find, and to base it on a word in your native language you can just translate by using the venerable Babelfish. By the way, I owe credit to Tod Maffin, who clued me into using a foreign word as part of a password.

Using both a dictionary word and a foreign word, we get two different measures of strength:



In both cases the password is pretty weak sauce. We’ll add the next piece and see how we do.

B. Significant Year
Obviously, you don’t want to pick your birth-year, unless you really can’t remember any other. Assuming you can, think about a year that is meaningful to you in some way. If you’re a fan of space exploration, like myself, you might use 1969 for the year of the moon landing. You might also use the year you graduated from high school, the year of your first kiss, almost anything will do, but choose something memorable. On its own, using a year as a personally meaningful year as a password would be bad, as in guessable. Stuffing the year into a longer password does the opposite by making an existing password more complicated to guess or crack, but still very easy for you to recall.

Adding the year of the moon landing bumps up the measure on our fledgling secure password:



C. Name Fragment
This part of our method is the most interesting, as it’s the one that keeps your password changing between every application or website that you use. The key is to create a rule that allows you to pick part of the name of an application or website to use as part of the password. I use a syllable-based rule, by picking the first syllable of the name. In the case of ‘Google’, the first syllable is Goo. In the case of ‘flickr’, I would use flick. In the case of ‘Digg’, I’d use Digg since there’s only one syllable.



Notice that I also reflect the capitalization in the syllable, as well. This allows the introduction of an uppercase letter to the password without having to recall where I put it.



While we know that including an uppercase letter is more secure, at this point the quality meter doesn’t differentiate - we’re in iron-tough password country, now.

Extra Spicy Variations
It’s well possible that you’d like an even stronger password. That’s certainly possible by adding one or both of the following to the formula we have going already:
* More mixing of lower and uppercase letters: make the first or last character your Dictionary or Foreign Word uppercase. Whatever you choose, make it rule-based
* Add punctuation characters. As with adding more uppercase characters, there are a number of positional approaches to adding punctuation that will make it easy to remember as part of your overall formula.
* Oscillate between two Dictionary/Foreign Words and/or Significant Years. You’ll likely need to make more attempts if you forget which you used, but you’ll know your range and keep your passwords more mixed up.
* Vary the ordering of formula elements



Wrapping it Up
The method I’ve described here can be summed up as: [Dictionary or Foreign Word] + [4-Digit Year] + [App/Site Name Fragment]

or for even stronger passwords: + [Optional Uppercase Rule] + [Optional Punctuation Rule] + [Optional Oscillation]

The advantages of the method:
* memorable passwords - when the rule is known, any password can be reconstructed on the fly when forgotten
* different password for every site or app
* should satisfy most password requirements you’ll encounter
* sufficient length and character mix to defend against guessing, dictionary and brute force attacks
* the formula (as in the variable names) can be written down without disclosing its entirety to unauthorized eyes

But there are disadvantages, as well. If someone were to guess your formula from one or more instances of the password, all the accounts you protect with passwords based on the formula will be at risk. Also, this method doesn’t play well with password policies that require the password to be changed every so often. But that’s about the extent of the risks and applicability gaps that I can see, excepting a tendency to forget rule-based knowledge.

Combined with OpenID, this password formula loses the need for a uniqueness element, but is less prone to discovery through third-party negligence or unforeseen attacks. Adding to that the OAuth-enabled applications that will soon come online, and that single, strong password will stay close to your chest while it opens doors around the world to you. Hopefully the method I describe here helps you make more secure and humane, i.e. memorable passwords. If you think of risks or improvements not covered here, please add them to the comments.

[Ron Paul]

the best password to use is: password