The ChromaHash module I've submitted to the YUI3-Gallery got hit up on Reddit this week, which incidentally is the second time ChromaHash has been discussed there. And this time around, the discussion was just as negative this time around.

First, a lot of people focused too heavily on the fact that the demo screen is a confirm password box, commenting that a simple checkbox confirming the password was the same would be sufficient. Of those who did recognize that this was meant to be used on a login page as well, we got the general reaction we get that since this gives any information about the password, then it's wholly unacceptable, and it completely compromises the password security.

Now, Mattt Thompson, creator of ChromaHash for jQuery (and who's module mine is based off of), has written a pretty good post outlining why this implementation isn't as bad as the reaction we're getting off of certain information security folks, and I'm not planning to reiterate his points (at least, not entirely), since I, as a person with great interest in information security, think that Mattt's post is more than sufficient at making the point.

Instead, I'm going to talk a bit about some of the suggestions that have come out of the Reddit threads.

1. Salt Password with Username

Actually, this is a reasonable option, since it would ensure that users with the same password don't discover that. There are a few implementation-level details, since we'll have to tell chroma-hash where to find the salting value. The initial thought I have is making the salt object optionally take an array, where any element of the array that is a valid CSS selector, then I'll take the value property of the node referred to by the selector and append it to the other elements of the array (as strings) to get the salt value. This does mean I'll be recomputing the salt periodically, but I think there are ways around that (subsribing to the 'change' event for the node, for instance). This suggestion, I think, warrants some more consideration. Though really, password collisions should be pretty rare.

2. Could reconstruct password as user typed it.

This is really only an issue for slow typists, since in my implementation the color shifts take half a second. This ought to be user configurable, and it will be in a new release soon-ish. An alternative, that I'm not as convinced to it's usefulness, would be to set a delay between the last keypress and the animation beginning. I might do this one, but again, I'm not convinced it's useful.

3. Randomly salt password on pageload

Umm, no. This would make this tool completely worthless.

4. People are colorblind.

Yes, approximately 14.5% of the population has some color-related vision problems. But that means 85.5% of the population isn't. And even the people who are color-blind can still glean information from chromahash, even if they're more likely to encounter collisions. Plus, this is a non-essential tool, so it's not like using chromahash prevents the color blind for interacting with your site.

5. Any information about the password is TOO MUCH INFORMATION

Actually, my favorite one of these is a guy who made a bruteforce for chroma-hash. Now, his example is kind of bullshit because he uses a crap password, so of course it's fast, but it completely fails to take into account a few notes:

1. We're using MD5 on the backend, which outputs 32 hexadecimal digits, of which we're only using 6 to 24 (which is configurable by the 'bars' option). The collision space, particularly if you only use one or two bars, is non-trivial.
2. There are very few circumstances where an attacker could get the exact hex values for a chromahash, when they wouldn't have better mechanisms to steal your password (ie, keyloggers). And for those cases where it could be, disabling chromahash (at least, the YUI3 version I wrote) isn't very difficult, and could be wired up to a key event handler, an example of which I'll probably have later.

It's highly unlikely that someone will be able to get enough immediate data from this system to be able to make a reasonable attack on a password, certainly not when there are so many other, easier ways to perform that attack. And ChromaHash is configurable, based on when it goes color as well as how many bars it displays, which both would help this situation.

Ultimately, however, passwords are a failure as a security mechanism. Most people use the same password (or small set of passwords) everywhere, they don't change them very often. Not to mention the fact that a lot of people storing password are doing a poor job of it. I worked at an e-commerce company not too long ago that when I took over their web presence, the passwords were in the database in plaintext, access rights were driven by a cookie. Hacking this site was trivial until I rewrote it, and even then, there are a few things that I didn't do correctly right away, like not salting my MD5 hashes I was storing in the database (or using MD5 as my hashing algorithm in the first place...).

I believe that ChromaHash can improve usability, since it provides immediate feedback to the user that their password is accurate, and given that many people are visual, I think that they'll develop, rather quickly, a gut reaction to the hash colors if they're wrong or not. Will it work for everyone? No, but it could help most people.

We need to move beyond passwords as an authentication mechanism. I'm a big fan of the Yubikey, particualrly when paired with OpenID, though just migrating toward OpenID is a huge improvement. But ChromaHash, as it stands, does not significantly weaken the nature of passwords.