2010–09–14 The “Perfect Password” Keyword: Modularity

Originally posted on landoblog.com [now deprecated] on September 14th, 2010. Retrieved courtesy of Wayback Machine — Internet Archive.

Passwords suck.

There are so many to remember, you have to change them, and they’re hard to remember. OAuth aside, wouldn’t it be nice if everyone just trusted each other and you didn’t need passwords for authentication? Unfortunately, passwords are an old-school thought process and they’re not going away until The Borg complete their assimilation (it’s futile). So, in a process to reduce the frustration, I came up with the “Perfect Password”.

What doe this entail? It must be easily memorable, different for every site/service I use, relatively unbreakable, and work for every site without any kind of plug in or memory bank tool. There have been some good attempts, but most fall short of all of these requirements. Nic Wolff built a handy password generator that is highly secure, but requires a tool to translate, unwieldy when used without a password dictionary like eWallet from Ilium Software.

My solution is this: Modular Passwords.

As many websites have different password character set/length combinations, I set out to develop one that I could use for ALL websites, through the concept of password modularity. I have since developed a “master password” that works with more than 95% of websites I use. The concept is simple, the use of “variable elements” allows the password “prototype” to remain the same across all sites/services, but as the user only types the final string in, the prototype is not able to be compromised in the event one password string is leaked/service is hacked/etc… The full-length password is considered to be “very strong”, but for sites with forced lower requirements (limited characters or character set) the password will still work when truncated.

A variable element is a lowercase or uppercase character or a number. An example might be “g”, but only for google.com, as the variable character is simple the first letter of the top level domain name. Another example could be “el” for backwards-last two characters of a domain name. Another might be “6”, as that is the number of characters in the name. Another example is a classification system such as “f” for financial related, “w” for web related and “o” for other things. This process allows for every site to have a different password, yet allow the user to remember only one.

The first 8 characters of a password must be only letters and numbers, but must contain a mix of uppercase, lowercase, numbers, and two types of variable elements. Many sites with limits on lengths also limit the character set to a-z, A-Z and 0–9. This allows the user to simply type in the first 8 if a password field will not take special characters.

The additional six characters of the password (for a total of 14) must be non-alphamaneuric, such as “^”, “#”, or “”, and should contain another variable element type.

Be aware that you may need to type your password on devices with a non-standard keyboard, so a method to accomplish this must be possible. One example might be a numeric pin code for an ATM card. This could be done by using the translation of characters in your prototype to numbers on a DTMF phone pad.