Welcome to part 2 of my blog on creating unique, unbreakable passwords you can memorize easily. Part 1 discussed what makes passwords easy or difficult to break.

g!@rg#m$rK%mY23147+~

4H7g2^6Oi(Tr%Mn&As

Do you think you can memorize either of these passwords? How about 10 of them? 50? By the end of this article, you’ll be able to create unique passwords with this level of complexity and recall them with ease. Don’t think so? Read on…

None of the characters in the above examples are random. They are unique passwords generated using some very simple rules specific to the person creating them — a set of user-created rules, that work in much the same way that a computer does, to generate passwords.

How computers and humans make ‘random’ passwords
Computers cannot create truly random numbers. What they do is use a ‘seed,’ usually generated from a set of changing parameters, usually based on the current time and date. Using this seed, and a complex math formula, computers can create an unlimited number of new numbers, all of which seem random but are actually firmly governed by the software rules used to create them.

If you ask a person to create a random password, they will pull from past experience and pre-conceived rules as to what they think ‘random’ is in order to create the password. People have so many unique variations that there’s no way to predict with any absolute accuracy what password a human would create, but most of us have a fair amount of overlap as to how we make it. A good example of this is documented in research from the University of South Wales showing that the top 10,000 passwords were used by 98.8% of all users.

Putting those two points together: If I created 5 computers exactly equal, and asked them to generate a random password at the exact same millisecond, they will all return the same password, but that sequence would be complex enough for the number to be considered ‘random’ for the purposes of guessing. However, if I asked 5 people to do the same thing, it would be statistically unlikely that any of them would create the same password as one of the others, but very likely that one or more of them would create a password that would be easily guessable.

Growing passwords from seed
So what I suggest is that you create your own personal and unique ‘seed’ — a set of predictable parameters to create passwords that are unique to you. If you take a bit of time to draw on your own personal uniqueness, you should be able to come up with a simple formula to create seemingly random passwords that you will be able to reconstruct at any time to create, or recall, passwords.

Here’s a few examples of this in action.

Let’s go back to the first example: g!@rg#m$rK%mY23147+~

This is a password for Gmail, and it was created in the following way:

This person is a people person, so they thought of 26 names that are special to them:

A:Amy    B:Boris    C:Carol

And son on.

Then they put three names together representing the first three letters of the website and capitalized the last letter of each word:

georgEmarKamY

Next, they substituted all the vowels with symbols ascending from 1-9 on the qwerty keyboard:

1st=>!    2nd=>@    3^rd=>#

And so on.

g!@rg#m$rK%mY

Finally, they added 5 numbers that were special to them to the end ‘23147’ and two symbols ‘+~’

g!@rg#m$rK%mY23147+~

Using this same method, lets create a password for another site, Bank of America:

BAN => borisamynancy => boriSamYnancY => b!r@S#mYn$ncY => b!r@S#mYn$ncY23147+~

So while the last seven digits do repeat throughout all of their passwords, the first rules ensure that each password has enough uniqueness and entropy to be next to impossible to breach, and almost impossible for anyone to be able to deconstruct and guess your method. Even if they did figure out your algorithm, they would have to know all 26 names you came up with, and that alone would be an almost impossible challenge.

No copying
So what happens when you use more than one bank: Bank of Canada, Bank of America, etc? You don’t want the same password for all banks. In that case, I would suggest modifying the method to use the abbreviation of the name of the institution, if it has an abbreviation, instead of the first three letters of its name. Gmail would still be GMA, but Bank of America would be BOA and Bank of Canada would be BOC, and so on. As long as the rules are consistent for you, you can create any variations you like.

So let’s look at another example:

Here’s a password for the site ‘Hotmail.com’: 4H7g2^6Oi(Tr%Mn&As

In this case, you locate the keys for the first 4 letters of the site name on your keyboard, and then move up the rows to the line of number keys to get four symbols:

h=>^      o=>(      t=>%      m=>&

^(%&

Move up the rows to the line of number keys to get four symbols.

Now, on the keyboard, type each of those first four letters together with the next letter to its left (or right, if it’s on the left edge of the keyboard), and have the first of each letter pair be in caps:

Hg Oi Tr Mn As

Now interleave the letters and symbols together:

Hg^Oi(Tr%Mn&As

Now add the numbers 4726 in every second position:

4H7g2^6Oi(Tr%Mn&As

Using this set of rules, let’s create a password for twitter.com:

twit=>%@*%    =>    Tr%Wq@Iu*Tr%    =>    4T7r%2W6q@Iu*Tr%

This, and the other algorithm above, are just two quick and simple methods I came up with off the top of my head. I wouldn’t recommend using either of these methods verbatim, they’re just examples created from the way I think. Instead, come up with a completely unique set of rules for creating your own passwords.

The key to this method is consistency, once you start following your own rules you’ll be able to create and recall complex passwords with ease. So stop forgetting your passwords and start being safe on the internet!

Standard+Case.

Take a holistic approach to IT from Rob England at his blog, The IT Skeptic, and from his books, including Plus! The Standard+Case Approach. For more information, read Rob’s new white paper on turning undefined Case Management situations into new Standard Response Models, written for xMatters: Standard+Case: How IT Response Models Drive Modern Operations.

Request a demo