Hey, go check out the more recent blog post about Chroma-Hash for a better and more up-to-date explanation of everything.

Yesterday, I posted Chroma-Hash, an experiment in how to visualize the live-input of secure fields, such as a password on a login screen. So far, I’ve received a lot of great feedback, as well as a number of questions that I thought deserved a proper response.

Before I go into any details, I invite you to check out the live demo, (if you haven’t seen it already), so you can get a clear idea of what Chroma-Hash does.

The Concept

When you type something into a secure field, each character is displayed as a •. Good news for people who don’t want others to see their password; Bad news for anyone who has a long or difficult password (or is bad at typing). How could we improve the experience of secure text input so that the user entering information could have an idea of what they entered, without anyone else knowing it?

Chroma-Hash approaches this problem using an ambient color representation of the input as it is being typed.

Use Case 1: Login Check

If your password normally is represented as “red, purple, orange”, and after you’ve finished typing you see “pink, green, grey”, you’ll know you mistyped it somewhere along the way. This avoids a potentially long wait for the server to respond with a “failed login” notice.

Use Case 2: Password Confirmation

When you sign up for a web service, you often have to type your password twice to make sure that you entered what you wanted correctly. As in the demo, a user will be able to confirm that two fields are the same visually. There are, of course, many alternatives for live-input validation of password confirmation, but this is another viable use case for Chroma-Hash.

Security Concerns

Under the scrutiny of the sharp minds on proggit and Hacker News, it’s only natural that some really good concerns were raised. As an experiment, this is the best kind of input I could ask for, because it challenges the viability of this as a visual metaphor, and works to improve the usability of the project as a whole.

“It’s Not Non-Reversible”

By all accounts, I would not, in fact, bet on Chroma-Hash being unbreakable. At least in its current iteration.

One of the common arguments is that by showing the colors as you type, one could step through and guess along each way. chaosmachine on Hacker News explained it this way:

Because you can see the color code at each step, it’s easy to compare results very quickly, even by hand. Did I get letter 1 right? Ok, move on to letter two, try each key until the colors match the recording. Do this for each step. At most, you have to try about 64 key presses to crack each letter.

Theoretically, this is definitely a concern. One of the ways I tried to prevent this was to animate transitions between the color sequences as they were being typed, so intermediary colors were never shown. Given a sufficiently slow typist, though, all bets are off in Chroma-Hash’s current state.

Another consideration, however, is how exactly someone would be able to tell what the colors are, at least in common use-cases. As a color expressed in Hex, there are 16,777,215 possible colors for each bar. Eye-balling it wouldn’t be enough to get an exact color value—the difference between #952A08 and #952A09 is nearly imperceptible, but represent an completely different hash input. Unless you get a really good look, it would be pretty hard to tell. And at that point, you might as well be looking at the person typing it instead :)

MD5 is Weak

Another concern was the use of MD5 rather than a stronger hashing algorithm, like SHA-1. For this first release, MD5 was a choice of convenience. MD5 is marginally faster, and with live-validation, I wanted to make sure that the animation was smooth and didn’t interfere with user input.

One of the ideas behind the project was that by using one hashing algorithm, a user could expect the same color on any website that implemented Chroma-Hash. This is not a central concept to this visualization, and may prove to be a bad idea. For the next iteration, I’m considering adding support for SHA-1 as an alternative hashing algorithm that can be passed in as a parameter.

Iterative Improvement

Weighing in these concerns, I believe that this kind of visualization can become a viable UI metaphor—all it would take are a few minor improvements. Here are a few suggestions that I am currently considering for the next version:

Adding A Time Delay To Live Input

To avoid the possibility of exploiting information as the user types their input, a short time delay could be added before the colors are displayed.1 2 3 4 This way, all a potential attacker could know is a portion of the password’s hash, which is not nearly as useful.

Using A Stronger Hashing Algorithm

As stated before, I may add an option to use SHA-1 instead of MD5 in the next version. This is pending research into the potential gains and the concerns of maintaining a fluid user experience.1 2

Using a Salt

A salt “Salt on Wikipedia”) based on other field inputs or a server-defined constant, for instance, would further increase the security of the hashing algorithm. The only downside is that this approach would force the user to remember different color combinations for each site, which as I mentioned above, may not be such a bad thing.

Once again, I’d like to thank everyone who’s given me so much useful feedback and encouragement. I’m really excited to take Chroma-Hash to the next level, and as such, I extend you to continue this conversation on possible uses and security considerations.

Photo Credit: binarycoco