7 ms·

The Chroma Hash effect

15 points by axemclion 17y ago

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.

sh1mmer 17y ago
If you aren't groking what this is about the example given in article is awesome. http://mattt.github.com/Chroma-Hash/ 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.
- didroe 17y ago
  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.
  - phobos 17y ago
    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.
- tptacek 17y ago
  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.
  - jrockway 17y ago
    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.
    - tptacek 17y ago
      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.
  - sh1mmer 17y ago
    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.
    - tptacek 17y ago
      See elsewhere in the comments for how to break the hash.
calcnerd256 17y ago
It aids shoulder-surfing, but not significantly.
brown9-2 17y ago
The actual demo of the fork that the article author is discussing seems to be here: http://axemclion.github.com/Chroma-Hash/ http://axemclion.github.com/Chroma-Hash/ (not sure why this is not mentioned in his article)
- Retric 17y ago
  Is there a bug? I don't see the effect with Image. "a", "b", "logop" and "logo" all seemed to give the same Image
erso 17y ago
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.
- tptacek 17y ago
  No. These password visualizers are startlingly unsafe and largely useless responses to what is mostly a non-problem.
  - jrockway 17y ago
    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.
    - tptacek 17y ago
      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.
      - jrockway 17y ago
        This is a greasemonkey script that the user chooses to use himself.

15 points by axemclion 17y ago

sh1mmer 17y ago

If you aren't groking what this is about the example given in article is awesome. http://mattt.github.com/Chroma-Hash/ 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.

didroe 17y ago
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.
- phobos 17y ago
  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.
tptacek 17y ago
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.
- jrockway 17y ago
  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.
  - tptacek 17y ago
    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.
- sh1mmer 17y ago
  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.
  - tptacek 17y ago
    See elsewhere in the comments for how to break the hash.

calcnerd256 17y ago

It aids shoulder-surfing, but not significantly.

brown9-2 17y ago

The actual demo of the fork that the article author is discussing seems to be here: http://axemclion.github.com/Chroma-Hash/ http://axemclion.github.com/Chroma-Hash/ (not sure why this is not mentioned in his article)

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

erso 17y ago

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.

tptacek 17y ago
No. These password visualizers are startlingly unsafe and largely useless responses to what is mostly a non-problem.
- jrockway 17y ago
  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.
  - tptacek 17y ago
    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.
    - jrockway 17y ago
      This is a greasemonkey script that the user chooses to use himself.