The Chroma Hash effect | Hacker News Reader

The Chroma Hash effect

dy-verse.blogspot.com

15 pointsaxemclion19 comments

Password entry can be frustrating, especially with long or difficult passwords. On a webpage, secure fields obscure your input with •'s, so others can't read it. Unfortunately, neither can you—you can't tell if you got your password right until you click "Log In".

Chroma-Hash displays a series of colored bars at the end of field inputs so you can instantly see if your password is right. Chroma-Hash takes an MD5 hash of your input and uses that to compute the colors in the visualization. The MD5 hash is non-reversible, so no one could know what your password just from the colors. Your password will display the same sequence each time, so you can learn to expect "blue, red, pink", for instance; if you instead see "green, purple, yellow", you'll know you typed it wrong. The visualization also includes a user defined salt to prevent guessing passwords. The visualization is also salted with the domain name, trying out site to user authentication as an experiment.

Open articleView on HN

Am I the only person that doesn't want passwords echoed to the screen, to any extent, ever?

If I have to do a password confirmation I'd rather submit a form and have it tell me my passwords didn't match than to have immediate feedback with a visualization that isn't accessible.

No. These password visualizers are startlingly unsafe and largely useless responses to what is mostly a non-problem.

How are they startling unsafe?

If you watch someone type their password, you can get a visual cue that you retyped it correctly without submitting it to the server?

For me, this is like syntax highlighting. It is not necessary, but it's nice to have that colored visual cue so that your brain quickly knows that you got it right.

When you watch someone type their password into a PASSWORD input field, the only feedback you get is a dot on the screen.

When you watch someone type their password into one of these password-visualizing fields, you get a visualization of an hash of however many characters they've entered. If you have any ability to capture that hash, you can dictionary the password to a set of candidates.

If the person hesitates typing just long enough to get an interim visualization, you can probably narrow it down to a hand-guessable subset of passwords.

This isn't a reasonable security concession for the value of eliminating a server roundtrip to confirm a password, especially given the fact that less than 2% of your user base will ever use the visualization, but 100% of your user base is exposed to the liability.

This is a greasemonkey script that the user chooses to use himself.

No, it's a jQuery extension that has (among other things) been ported to Greasemonkey. What you do with your browser is your business; it's still a bad idea --- if you can do visualization with Greasemonkey, you can also do a password manager --- but if it's not in the actual web application, who cares?

I didn't look into how it works on the backend, but fetching the images means all the intermediate hashes are being sent out, right?

No, it's not fetching images for each of the hashes; it's a pure-JS MD5 which selects CSS background-colors for DOM elements.

The actual demo of the fork that the article author is discussing seems to be here: http://axemclion.github.com/Chroma-Hash/

(not sure why this is not mentioned in his article)

Is there a bug? I don't see the effect with Image. "a", "b", "logop" and "logo" all seemed to give the same Image

If you aren't groking what this is about the example given in article is awesome. http://mattt.github.com/Chroma-Hash/

Mattt-triple-t was our intern at the Yahoo! Developer Network last year and sent us this a couple of weeks ago. It's a really solid example implementation. You should play with it.

One thing that's weird in the example is that there's a confirm password box. The only utility I can see for Chroma Hash is in removing the need to confirm passwords. You'd need widespread use for people to remember their hashes though.

In some of our internal apps we have the data entry folks double key information into password fields (i.e. bank account, social security number). This would give them an opportunity to see if they mis-keyed something before submission and validation. I like it.

What makes this "really solid"?

If you mean, as an example of JS interactivity design, then yes. I agree. It's slick and it works as advertised.

If you mean, as an example of a safe extension to the most security-critical part of your application, then no. It's the opposite of solid. It's essentially publishing information that can be used to recover your password to the world.

I'm mystified as to how people could think this is a win.

This is the least of your worries when you aren't submitting your password over SSL anyway.

Also, I doubt my cat really cares about guessing my password.

I think what makes these bad-idea visualizers palatable to people is that they assume the applications that use them will only be used by a couple hundred people in their bedrooms or home offices. I think what makes them so repellent to me is the thought that one of those applications might become the next Twitter.

SSL vs. password visualization, which is worse? Depends on your threat model, I guess. It's academic to me. You should be using SSL also.

I meant the User Experience rather than the code.

I'm not sure I agree with your security analysis though. The concept is to provide a visual cue for the password that's hard to manually reverse engineer.

See elsewhere in the comments for how to break the hash.

It aids shoulder-surfing, but not significantly.

Reply on news.ycombinator.com