mattt / chroma-hash Goto Github PK

The following will not work.

<input type="password">

The following works

<input id="anything" type="password">

Chroma-Hash is dangerous to use.

I signed up on GitHub so that I could send you this link:

http://www.reddit.com/r/programming/comments/95hxr/chromahash_a_sexy_nonreversible_live/c0bi0s7

A simple solution to the issue of being able to guess someone's password by taking a screenshot of their "hash colors" is to create a random salt in the beginning of the script, then add it to the password before hashing. The end result would be different colors appearing the same password on different page loads, which would totally eliminate the screenshot problem.

Obviously the primary problem with this solution is that the same password would not show the same 3 colors, but that is also the entire point.

sometimes in chrome when typing in a password field too fast the colors are wrong. seems like an "old" calculation overwrites the newer one?

to test this:

• go to: http://jsfiddle.net/kCvaz/1/
• slowly (2 keystrokes per second maximum, just to be sure) enter "asdfgh" in the first field
• slowly enter "asdfgh" in the second field
• now press some key in the second field and instantly press backspace, undoing the change but triggering two onChange events

=> both fields have "asdfgh", but sometimes some bars of the second field remain as if you didn't press backspace.

a workaround would be to trigger all repaints by interval (e.g. 1 second), to clean these racing conditions up, but that wouldn't be very nice.

just to make clear: that doesn't just happen if the racing condition is intentional, but also when typing a well known password fast. e.g. I'm working on a browser game engine, and use chromaHash there, and my alpha test user root has password toor, so when typing that for the 100th time to find some login bug/etc you type the two Os very fast, triggering the error.

Problem: If the password box looses focus before the colors have reached the final state, the colors will be 'stuck' in the intermediate state until the password box regains focus.

Example:

1. Type a password and then delete it and immediately press tab once the password is deleted
2. Type a password quickly (or spam the keyboard) and then press tab. Although the bug isn't as obvious in this situation, it is still apparent.

$.browser is deprecated, so removing that dependency would be great. I'll send you a patch.

Hi,
could you please add the github commit HTTP hook http://cd.nonchip.de/update.php?f=jquery.chroma-hash.js?
that would allow me to deliver bleeding-edge versions of your awesome library using my content delivery system, as github sends the wrong mime headers. nothing really big, but it does some nice caching, and I use it in many of my own web apps, and open it to everyone who wants to use it.
your lib would be available via http://cd.nonchip.de/jquery.chroma-hash.js

It seems like the following color calculation can in some cases produce invalid hex colors (shorter than six digits), which causes a race condition that changes the final chroma-hash depending on how fast the user types:

var color = parseInt(colors[i], 16);
var red = (color >> 16) & 255;
var green = (color >> 8) & 255;
var blue = color & 255;
var hex = $.map([red, green, blue], function(c, i) {
  return ((c >> 4) * 0x10).toString(16);
}).join('');

For example, with the default salt 7be82b35cb0199120eea35a4507c9acf and minimum: 5 (tested in Chrome 32 on Mac), the word "keyboard" produces the following hex values:

//o
Bar 1 f0f0c0
Bar 2 e06090
Bar 3 e00c0 // <-- Invalid color

//a
Bar 1 90f0f0
Bar 2 80a0e0
Bar 3 90f020

//r
Bar 1 20d010
Bar 2 8070e0
Bar 3 e0b010

//d
Bar 1 10c060
Bar 2 b0200 // <-- Invalid color
Bar 3 70f040

When tested directly on http://mattt.github.io/Chroma-Hash/, the middle bar is a dark purple color when the word "keyboard" is typed slowly:

...but is a lighter purple color when "keyboa" is typed slowly, followed by "rd" typed quickly:

I believe this is because in the "fast rd" case, the color from stopping after "a" is retained since the final "d" color for the middle bar b0200 is invalid (not six hex digits,) and typing quickly doesn't give the "r" color 8070e0 a chance to appear.

I'm not sure of the best way to fix this; perhaps hex could be 0-padded if it ends up being less than six digits?

Hey Triple-T,

Was thinking this might be good to get up into the bower/npm registry/registries for optimal versioning & happiness. Thoughts?