"Poo-tee-weet?"
November 5 ⎨2009⎬

Chroma-Hash, Revisited

Based on a resurgence of interest in Chroma-Hash (hi reddit!), I thought it’d be useful to revisit this oft-misunderstood project.

If you haven’t already seen it already, you should check it out. Even if you have, you might want to play around with it again to see if any new insights come to mind (go ahead, it’ll only take a minute).

Chroma-Hash has been a particularly interesting project because of the controversy it creates in discussions. Some people won’t understand how it could ever be useful, while it couldn’t be any clearer to others. There’s often a back-and-forth about the potential security risks of the system and the pragmatics of how those risks are insignificant.

I’ve learned a lot from reading through these various threads, and I wanted to share some of my thoughts to help bring light to the discussion. Or maybe just fuel the fire, perhaps.

Alright, let’s get right to it then:

So what’s The Point?

Good question! It started out as a simple UI experiment, but it soon developed into something that I think could be really useful. Here are some of the use cases that emerged from various feedback and iterations:

Use Case #1: Password Confirmation

Perhaps the most obvious use case from the demo, Chroma-Hash allows you to quickly compare the contents of two secure text fields. It’s common for a signup flow to ask you to type your password twice (to make sure you didn’t mistype it). With this visualization, a user can instantly check to see if what she typed was the same each time, without having to submit the form.

In a similar vein to password confirmation at signup, Chroma-Hash can be helpful when logging in from day-to-day. Whenever you log into your webmail or your favorite social network, you could expect to see your signature color combination. If not, you’d know that you somehow fudged it along the way. Especially for sites with 3 strike lockouts, Chroma-Hash could save a lot of needless frustration.

Use Case #2: Anti-Phishing Mechanism

As you might have caught on from the last use-case, Chroma-Hash could be effective in mitigating the risk of a phishing attack. Similar to the account-specific images that online banking systems recently added, your password becomes a visual signature that you can look for. Websites can securely serve unique color signatures by issuing a hash salt through a browser cookie, for instance.

Let’s say you go to a site that you think is PayPal. If you start to type your password and you’re getting unfamiliar colors (or no colors show up at all, for that matter), you’ll know something’s fishy.

Use Case #3: Password Strength Feedback

Let’s think back to signup flow: When creating a Google account, for instance, you’ll get visual feedback of the strength of your password as you type it in. Stop after 5 characters, and a partially-filled red bar will accompany a message telling you to pick something stronger.

Similarly, Chroma-Hash has a parameter to specify the minimum number of characters before colors start to display. Until that threshold is reached, all the user will see are boring, gray bars. It’s more implicit than using strong colors and words, but there’s something to be said about ambient feedback, no?

Use Case #4: Clipped or Constrained Input Feedback

Let’s say you’re like me, and you go a little over-the-top with passwords. Although it’s a bit of an edge case, Chroma-Hash can be useful for providing visual feedback when a user types beyond the boundaries of a field.

Conversely, if there is a cap on the maximum amount of input, the lack of visual feedback, in that colors stop changing even though you keep typing, can just as well provide a cue to stop.

Objections, Concerns, and Questions

Reading through various threads on reddit and Hacker News gave me a much deeper insight into everything from aesthetics and usability to security and information theory. A lot of feedback was immensely useful, and helped take Chroma-Hash to that next level.

There may still be some legitimate usability or security concerns, but after several iterations, I’m confident that Chroma-Hash is a robust UI component. That said, I’d love to be proven wrong so I can continue to improve it even more.

For your consideration, here are some common concerns that are raised, along with my response to them.

“MD5 Is Weak”

From my understanding, a weak hash function is exactly what makes something like MD5 well-suited to this application. Usually, a hashing function is rated on its aversion to collision. For instance, if you are taking a checksum of a file, you’d want to be confident two files with the same checksum have the same content—otherwise, no collisions.

In the case of Chroma-Hash, collisions add security. If passwords have the same checksum, it makes it harder to isolate which one a checksum represents. Collisions are good for the purposes of the visualization. Collisions are what make security possible with Chroma-Hash.

“Knowing the Colors is Knowing the Password”

Although Chroma-Hash seems to cover the entire spectrum, it’s actually constrained to a limited palette. Small palette means more collisions, which means that it’s more secure. Here are two techniques that are used to minimize the use of colors:

  • Grayscale Threshold - As mentioned in Use Case #3, colors don’t show up below a specified number of characters (by default, 6). Instead, the bars display in 4-bit monochrome. Not only are the colors difficult to differentiate based on plain eyesight, but within that range, you are nearly guaranteed to have collisions. Bump up the minimum, and it becomes exponentially more difficult to trace through to the final password.

  • Least-Place Crushing - Above the grayscale threshold, the range of colors are still constrained. Based on a great insight by Ian Young, the least place of a hexadecimal color can be rounded down without compromising aesthetics. For instance, the color #CE2029 is nearly the same as #C02020, but the latter could be any one of 3375 colors. Since humans can’t perceive these slight differences, the extra (leaky) detail is removed without cost. Your password still looks like “Red Green Purple” with or without that extra place.

This naturally brings us to…

“What About Colorblind People?”

Consider the last points about grayscale and constrained palettes. Although I’m not colorblind myself, I would suppose that having some form of colorblindness is comparable to these two examples. In an extreme case, in which someone could not differentiate any color at all—everything is grayscale—you could still use Chroma-Hash.

The only snag is that without perceiving the additional color information, they have a greater chance of colliding, as you see it. Because one-off input is unlikely to be consistently similar one could imagine this system as still somewhat useful (expected dark gray, black, white; got light gray, white, black: no match).

“Chroma-Evangelism” OR “The Many Colors of Chroma-Hash”

Last but not least, I wanted to point out some of the awesome contributions other developers have made to this whole experiment. They took the ideas behind Chroma-Hash and ported it to their favorite libraries and languages, and added so much more along the way. I’m truly humbled by your contributions.

Also, an Objective-C port and sound-based version by me:

Interested? Feel free to fork Chroma-Hash and make something even cooler!

Finally, a Shout-Out

I would be remiss without mentioning the main inspiration behind Chroma-Hash, HashMask by Chris Dary of Arc90. Cheers, Chris!

“Chroma-Hash, Revisited” was published on November 5, 2009, and filed under Programming.

You may also enjoy Gears, BrowserPlus, and Web 3.0, baby, I Want My MTV API!, and Y! Music Battle of the APIs in the Key of Ruby.