h3h.net

What is your online banking password? I have 10 to 1 odds that say it sucks. You should probably do something about that. If you like money, that is.

Alex King wrote a couple of posts [1, 2] on using password hashing software to abstract your passwords out of your head, ostensibly increasing the level of security involved with the web sites you entrust your information to.

My Needs

I am a person rooted deeply in efficiency and control, so for me to use an intermediary like the application Alex suggested — PwdHash — it would have to provide some superhuman benefits to supersede those two core needs.

Efficiency

Efficiency means that I only want one step when creating or entering a password for a website, regardless of where I am. This is a non-starter for PwdHash because it requires a browser plugin to achieve seamlessness. Though one could argue that the rare occasions one needs to access PwdHash without the browser plugin are outweighed by the security benefits. I disagree.

Control

Control means that I have complete, unmitigated control over my passwords. If I’m in a dire situation where I need to access my bank account online but pwdhash.com and my mirror password hashing site are both down, blocked or otherwise inaccessible, I simply cannot afford to be dead in the water. I need the control to have my passwords immediately available at all times. This means using only my brain.

Tiers and easy-to-remember passwords (both discussed in Alex’s posts) are entry-level efforts to do something about security, but are poorly planned and executed. It seems interesting to me that with all of this discussion about password hashing applications, no one has explicitly suggested this: hash your passwords in your head.

A hash is just a recombination of several different pieces of information in a unique way. It is entirely possible and even easy for the average person to start using self-made hashes for all passwords. I have a few of my own guidelines for password construction that follow.

Guidelines for Password Construction

1. Part of your hash should involve something that only you know. Everyone knows your social security number, birth date, anniversary, daughter’s first word, city of birth, etc. Don’t be stupid. Use something that has never been spoken aloud, but that recurs inside of your head. Everyone has an enormous amount of information that is never seen or known by the outside world. Example: everyone has the ability to think of a specific object when they hear “yellow” or “fast” (and to recall that same object when the word is heard in the future).

   Remember: that piece of information is only part of the hash, it is never the entire password. You will have to use your creative skills to take the several pieces of your hash, split them up in some non-trivial way and recombine them into a usable data point.

2. Never ever use passwords that are easy to remember. Always use passwords that are easy to type. When is the last time you had to recite your Google password out loud? Don’t do it. One of the most important features of a computer password is its suitability for transport. In this case, transport consists of sending the password from your brain through your keyboard into the computer. That transport process should be as fast, secure, and error-free as possible.

   Some simple methods for finding passwords that are easy to type include: alternating each character between left and right hands as much as possible, using SHIFT+ sequences together instead of breaking them apart, and prefering natural finger movements to awkward contortion. If you use your passwords often enough, they will be pushed out of your conscious memory and flow out of your fingers without even thinking about the characters being typed.

3. Part of the hash should include the resource you are accessing. Complexity builds up when you try to combine too many unrelated pieces of information into your hash, then use it for a specific resource (and create a different hashed result for each resource that you access). For this reason, the resource you are trying to access (in one form or another) should be one of the pieces of information that goes into the hash.

4. Use physical key patterns for filler. Your passwords need to be at least 8 characters long, but longer ones are better for data security reasons, so instead of trying to come up with more and more pieces of information to feed into your hash and increase the length of the resulting password, you can use “filler” pieces.

   Your filler pieces should not be based off of character similarities, but physical similarities when the characters are typed. Example: I may choose to use a right-to-left, right-hand filler in an arch shape. From this description I can start to write fillers: o8u, ;lij, .,jn, etc. These types of fillers have the advantage of being meaningless with respect to character data, easy to type, and can be keyed based off of any other member of the hash. For instance, if one of the pieces of information in my hash is “loser”, my filler can start with l or r.

   There are of course many more filler patterns you can use — from the very simple left-to-right, left-hand in a line (qwer, asdf, zxcv) to the more complex right-handed jiuh.

   Note: It may seem that fillers contradict the advice for “alternating each character between left and right hands as much as possible”, but the main strength of fillers is the speed at which they can be typed, the same driving concern behind alternation in the first place.

5. Use hashing data points that are universal across gateways. This just means that you shouldn’t use things like “name of my representative at the company” or “company’s stock ticker symbol” because not all gateways that require your password will have those properties. You should use data points that are associated with every gateway you need (and may need) to access.

   For instance, all resources you access probably have things like a canonical name, a main location, an organizational type, etc. Your data points can be anything you want, but the more they are tailored to your own knowledge, the more secure they will be. If you’re a professional investor and you know the public/private/corporate status of every gateway you access, that might be a good data point.

An Example

I feel like a lot of this has been abstract and jargon-ridden, so I’ll give one concrete example to help solidify some of the concepts presented.

Our scenario is this: we need to create a password for an account at amazon.com. First we need hashing data points.

We’ll use “main location” as one of our data points. In this case, that is 1200 12th Avenue, Seattle, Washington, United States 98144. We can take any subset of that location, but for simplicity (and knowingly reducing security) we’ll just use Seattle.

Well… “Amazon sells books” –> “when I think of ‘book’ I think The Autobiography of Bertrand Russell (yes, I’m a philosophy nerd). So another data point can be Russell.

Now let’s combine those two points and see what we can come up with. Obviously I could go on and use more data points, but the more you use the longer it will take to do the initial construction of the password. The time spent will probably increase security to a point, but using two data points is much better than not using any.

So we have Seattle and Russell. I start first by examining the physical characteristics of typing the data points. First an analysis of the handedness for Seattle: left, left, left, left left, right, left. It should be obvious that this isn’t optimal because it is cumbersome to type. Instead of using the whole data points, I can extract bits that suit me, so long as I’m consistent. I’ll take the first two letters of each data point, se and ru and use those as the meat of my password. Seattle was first, so my password can start with s, but then I should alternate to my right hand.

In this case r (the first letter of ru) isn’t pressed with my right hand, so I’m going to use a filler instead. The only right-handed letter in my two data points is u, so how about I move up one key to 8 and throw in the SHIFT key: SHIFT + 87y = *&Y. It’s always good to throw in the SHIFT key when dealing with numbers because they get you non-alphanumeric symbols.

Next I’ll alternate back to my left hand and use the next two letters in my data points: er, then alternating back to right, u is the only unused data point so I’ll go with uy to mirror the movement with er.

So far I have: s*&Yeruy. That’s 8 characters long and we could stop there, but why not throw a stylistic filler on the end for complexity’s sake? For that I’ll use a common filler that has nothing to do with my hash data points. I’ll just start at one corner of the keyboard and make a rhythmic stroke across four keys with my four fingers. In this case I should be alternating to my left hand, so I’ll use SHIFT + 1234 = !@#$.

So the final result is: s*&Yeruy!@#$. I must disclaim that I’m not a security expert, nor do I try to crack passwords on a regular basis, but I think it’s relatively safe to say that I’ve come up with a secure password for an account at amazon.com. Microsoft agrees: it’s “strong”.

Conclusion

I realize a lot of this seems unreasonably complex and in-depth for someone who is not used to hashing their own passwords, but all of the effort is really focused on creating the password for the first time — after that the only challenges are remembering it (which should be mitigated by the data points you choose and the wonderful effects of “muscle memory”) and typing it in (and we already know that’s easy).

So there you have it: my completely unfounded, off the cuff proposal for brain-based password hashing so you’ll never have to worry about one password being compromised and affecting others and so you’ll never need to rely on anyone (or anything) but yourself to produce your password when you really need it.