In Lotus Notes 6 password dialogs, a small keychain graphic sits on the left. As a user enters their password, the graphic changes, hashing the current password string to a particular keychain graphic. There are dozens of different graphics, each with varying keys and accessories. This feature allows users to get feedback about what they typed without displaying the password.
Users enter their passwords frequently. Overtime the graphic associated with their password will be memorized, even if only at a subconscious level. If a user mistypes their password, the graphic is likely to be different (collisions are possible). If the user notices an unfamiliar graphic, the password can be cleared and entered again. Thus, by capitalizing on human's memory and recognition skills, visual hashes provide a useful way for users to double check what they typed.
Checking passwords often requires a complex algorithm, but computation time is generally small. For users on their local machines, it's insignificant. However, if the password needs to be checked by a remote login server, things become more expensive. Secure connections have be negotiated and databases have to be queried. Throw in a few thousand users and your are looking at a serious load problem. Blizzard's popular World of Warcraft was plagued by login server overloads that kept people out of the under-loaded game-world machines. Because they can be generated client-side without knowledge of the correct password (remote), visual hashes can reduce the burden on login servers by eliminating some unnecessary login attempts.
Visual hashes benefit the user as well. It's possible that people memorize (again, maybe subconsciously) the sequence of graphics that are shown as the password is entered. From my experience, I knew I had made a mistake when an unfamiliar graphic appeared before having fully entered my password. Sometimes I was able to successfully backtrack, successively deleting characters until I saw a graphic that I felt (again, kind of a subconscious thing) was appropriate for my position in the password string. From this point, I could correctly resume entering my password.
It's also worth noting that visual hashes can be useful in any application which uses passwords. The most logical method would be for an operating system or GUI toolkit to provide a combined password plus visual hash component (or even update the existing password component). The component would contain all the logic. From the programmers perspective, it's would be the same as a standard password field. Visually, the component could even look simliar - see the "Random Inline Hash (Password)" demo. Considering the number of website passwords I have to remember, I think this would be very valuable for browsers.
First, I wanted to escape from some prefabricated set of graphics. I knew from the start I wanted something as diverse as a numeric or text hash. I started with the simplest: a 10x10 matrix of boxes that varied in color. The number of combinations was huge. However, humans are good at recognizing shapes; a sequence (or matrix) of colored boxes didn't provide sufficient visual distinction. Another notable method generated particular distributions of various colored shapes (circles, triangles, boxes, etc). This worked fairly well, but was cluttered and unrecognizable at smaller resolutions. Ultimately, I settled on something analogous to a paint stoke. It worked at any scale and had excellent visual variety.
Hash-as-you-go was a twist on hash generation. Rather than creating a totally new and random visual hash as each character was entered, the visual hash grew incrementally, much like a painter adding strokes to a canvas. With each additional character, a new detail is added. The complete password is like a finished piece. The downside is that it is less random, and thus less secure. People can guess the length of your password by the complexity of the visual hash. It is also possible they could determine which keys cause the creation of certain details, and reverse engineer your password. There are ways to complicate this, like having stroke behavior modified by previous characters. The upside to hash-as-you-go is that it is easier to notice a mistake. If at any point during password entry there is a detail that isn't present in the final visual hash, you know there is an error. This can't be done if the visual hash does not contain visual elements from previous states.
Email me for source files.
|© Chris Harrison|