Hashing For Humans 2
In Part I of hashing for humans, my objectives were to create a mental way of…
- Generating unique passwords for web applications using information available to you on the login page
- Generating unique passwords that do not imply each other (somebody finds your password to site A; that somebody cannot guess your password for site B)
Having pondered the topics of password-guess-ability and memorization, I have come up with two more solutions that rely more on the password format/infrastructure, instead of your head. They are quite different approaches to solve a similar problem. These solutions are not new, but it seems that too many web services/applications use forms of authentication that are old and unstandardized to protect their users.
Here are three common scenarios to keep in mind when reading these solutions:
- You are at a library and need to use the library’s computers to check your web email
- You are at a hotel and want to use the hotel’s computers to access your Facebook account
- You are at a friend’s house and want to make a quick purchase on Amazon.com
In each situation, let us assume that the computer is infected with malware that records every keystroke you type (within the web browser as well). How can we minimize the risk of somebody stealing your password and taking over your account?
working on untrusted computers
When working on a computer you don’t trust, you want to minimize the cost to you, should your password be stolen. So let’s use one password for logging in on your home computer and one password for logging in on untrusted computers. The password for untrusted computers will log into your account with less privileges: features such as changing your password/associated email (Facebook, Amazon) and looking at saved credit cards (Amazon)/your current address (Facebook, Amazon) will be unavailable.
Unfortunately, this does not reduce all the risk. Suppose someone learns your less-privileged account password. They will still have access parts of your account and you may never be made aware. So let’s use time-sensitive passwords. You generate a less-privileged password; however, the password will only be valid for an arbitrary amount of time after you have logged in with it for the first time. So if you are going on vacation for 7 days, you can generate a 7-day password that will only be valid for the vacation, assuming you use it on the first day. Yay.
Generating passwords for every account sound like a pain in the ass. How do we standardize this solution to multiple web services/applications? This problem has already been tackled, the most popular implementations being openid and Facebook Connect. Using services like these, users have the ability to login to a site through these authentication services (openid & Facebook connect). Now, if we, as an Internet community, can work to make our services/applications compatible with the previously mentioned services, we have only to remember, at any given time, a normal password and a temporary password.
an alternative to traditional alphabets
I had the pleasure of seeing a demonstration by Authernative, Inc., a company specializing in “user and transaction authentication” at a GTRA conference. One of Authernative’s solutions to authentication was based on remembering shapes, not letters/numbers/symbols.
Instead of choosing a password that meets certain criteria, you choose a shape—a shape that is a sequence of blocks in a grid. In the image above, Figure B shows one such shape for a 3×3 grid, Figure A (yes, I used Adobe Illustrator’s built in symbols). The first block in our shape is the block in the top-left. Every block in our shape is next to its predecessor and successor. The last block in the shape is the bottom-left block. This is what a real login screen from the server would resemble:
To login, all you have to do is look at Figure C, a copy of the grid directly above with our shape overlaid on top. In our shape, the 1st, 3rd, and 4th blocks are 1 (top-left), 3 (center), and 1 (right-center), respectively. Next time you login, they may ask you for the 2nd, 3rd, and 6th blocks in your shape and may use the randomly generated numbers in Figure D instead. Neither people looking over your shoulder nor keylogging software will know your shape because you have only used a subset of all the blocks in the the shape and because each number is in the grid more than once.
Now, for this 3×3 grid, it is not terribly hard to deduce the shape based on a few inputs; however, if the size of the grid were 20×20 or 40×40 and the shape were 10 blocks instead of 7, the time and inputs required to deduce the shape would increase at an increasing rate. What does this curve look like? Well, I’m way too busy/lazy at the moment to do the math, but some day I intend to get around to it.
This last solution is just one solution to authentication that is not traditionally used. There are many untraditional solutions waiting out there to be discovered. The mechanism of authentication often relies on humans; therefore, we must develop methods that better appeal to our lazy, forgetful, stupid minds. People remember shapes and phrases better than they remember random combinations of characters, numbers, and symbols. So security experts and psychologists, figure it the fuck out.
