Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chroma-Hash: a sexy, non-reversible, live visualization of password field input

mattt.github.com

Post reply on HN
Print view View original

61–70 of 70 posts

Re: Chroma-Hash: a sexy, non-reversible, live visualization of password field input

#61

Post by jonshea »

chaosmachine wrote: post #11

This is pretty, but non-reversible it isn't. The colors update with every keystroke, making it easy to determine letter by letter, which keys are being pressed. This is a significant hole in many situations (screencasts, recorded presentations, or anywhere someone can point a camera at your screen). Simple fix: Wait for 300ms of keyboard inactivity before computing the colors. This way you only get the colors when th…

It seems risky even if an attacker only had access to the final password hash, and not to the hash for every intermediate substring. In this ca the hacker could dictionary attack the hash while bypassing server side limits on failed password attempts.

Re: Chroma-Hash: a sexy, non-reversible, live visualization of password field input

#62

Post by beyondkaoru »

chaosmachine wrote: post #25
Torn wrote: post #22

Earlier quoted context omitted.

I don't see how this follows -- the colours are changing with each keypress (just as an md5 digest would change if you added a letter to the message) but surely you cannot know the key pressed without brute-forcing / breaking the hash, which is computationally impractical? He's also scraping the hash for a run of 6 hex characters, so surely there's quite a few colour collisions for different hashes, making it even ha…

Because you can see the color code at each step, it's easy to compare results very quickly, even by hand. Did I get letter 1 right? Ok, move on to letter two, try each key until the colors match the recording. Do this for each step. At most, you have to try about 64 key presses to crack each letter. Also, because each step is only 1 character different, it's very unlikely that you will get collisions, even with a tru…

This sounds like it would be easily fixed using a this-page-only salt for your hashing function. I.e., when someone else visits the login page, they get a different salt and thus can't use that attack. This could be done on the server (if you use a dynamically generated page) or on the client (with some javascript).

Re: Chroma-Hash: a sexy, non-reversible, live visualization of password field input

#63

Post by [deleted] »

ja27 wrote: post #44
chaosmachine wrote: post #11

This is pretty, but non-reversible it isn't. The colors update with every keystroke, making it easy to determine letter by letter, which keys are being pressed. This is a significant hole in many situations (screencasts, recorded presentations, or anywhere someone can point a camera at your screen). Simple fix: Wait for 300ms of keyboard inactivity before computing the colors. This way you only get the colors when th…

This is similar to the attack on Lotus Notes' hieroglyphics: http://www.securityfocus.com/bid/4324/discuss

[deleted]

Re: Chroma-Hash: a sexy, non-reversible, live visualization of password field input

#64

Post by rawr »

ja27 wrote: post #44
chaosmachine wrote: post #11

This is pretty, but non-reversible it isn't. The colors update with every keystroke, making it easy to determine letter by letter, which keys are being pressed. This is a significant hole in many situations (screencasts, recorded presentations, or anywhere someone can point a camera at your screen). Simple fix: Wait for 300ms of keyboard inactivity before computing the colors. This way you only get the colors when th…

This is similar to the attack on Lotus Notes' hieroglyphics: http://www.securityfocus.com/bid/4324/discuss

The difference is that Lotus Notes doesn't give you the result halfway through typing your password.

This color scheme would work fine if they waited until the password was entered and then showed you the colors, but to do it at each keystroke is insecure.

Re: Chroma-Hash: a sexy, non-reversible, live visualization of password field input

#65

Post by calambrac »

beyondkaoru wrote: post #62
chaosmachine wrote: post #25

Earlier quoted context omitted.

Because you can see the color code at each step, it's easy to compare results very quickly, even by hand. Did I get letter 1 right? Ok, move on to letter two, try each key until the colors match the recording. Do this for each step. At most, you have to try about 64 key presses to crack each letter. Also, because each step is only 1 character different, it's very unlikely that you will get collisions, even with a tru…

This sounds like it would be easily fixed using a this-page-only salt for your hashing function. I.e., when someone else visits the login page, they get a different salt and thus can't use that attack. This could be done on the server (if you use a dynamically generated page) or on the client (with some javascript).

How do you know it's "someone else"? It's the login page, you don't know who you're displaying the page to yet.

And if you mean a different salt every time the page gets loaded: doesn't that completely skip the supposed point, which is to give the user a recognizable visual cue that they typed the right password?

Re: Chroma-Hash: a sexy, non-reversible, live visualization of password field input

#66

Post by calambrac »

michaelfairley wrote: post #60

What if this only displayed one color instead? It would be much more secure against snooping, but will still provide a large portion of the benefit. Sure, the number of false collisions would go up a ton, but the odds of trying to type the same thing and accidentally typing do different things that collide would be relatively small.

The attack is based on being able to watch how the badge changes with each keystroke. Changing the number of colors displayed doesn't really help.

Re: Chroma-Hash: a sexy, non-reversible, live visualization of password field input

#67

Post by calambrac »

matttthompson wrote: post #49

Thanks for all of your feedback so far! I just posted a bit of explanation and a response on my blog: http://mattt.me/2009/07/chroma-hash-a-belated-introduction/

Another consideration, however, is how exactly someone would be able to tell what the colors are, at least in common use-cases.

You seem to be bringing this up as an argument that the security concern isn't really that important, that because a snooper wouldn't be able make fine-grained distinctions between colors, the attack is more difficult.

First, that's not true, it just means you have to be a little more robust to fuzziness. In your current 3 bar configuration, the subtle differences between the possible exact values of a given single color bar are usually dwarfed by the not subtle differences between the 3. Further, you get an even bigger shift when the next letter gets typed.

Second, even if we did grant that point, doesn't it simultaneously undermine the very purpose the tool is trying to serve? If it's hard for an attacker to verify the colors, isn't it equally difficult for the user who is supposed to be using this to check that they've typed their password correctly?

It looks cool, I will definitely grant that. But it's just not a good idea, and I really hope I never see it used by any sites I frequent.

Re: Chroma-Hash: a sexy, non-reversible, live visualization of password field input

#68

Post by Meatshoes »

calambrac wrote: post #65
beyondkaoru wrote: post #62

Earlier quoted context omitted.

This sounds like it would be easily fixed using a this-page-only salt for your hashing function. I.e., when someone else visits the login page, they get a different salt and thus can't use that attack. This could be done on the server (if you use a dynamically generated page) or on the client (with some javascript).

How do you know it's "someone else"? It's the login page, you don't know who you're displaying the page to yet. And if you mean a different salt every time the page gets loaded: doesn't that completely skip the supposed point, which is to give the user a recognizable visual cue that they typed the right password?

The demo seems to highlight its use as a visual cue that your confirmed password is the same as the original. Not that useful in my opinion, as one attempt at creating an account with non-matching passwords will tell you they don't match anyway, and you (usually) only create an account once.

Still, pretty cool demo and very nice colour schemes.

Re: Chroma-Hash: a sexy, non-reversible, live visualization of password field input

#69

Post by Meatshoes »

chaosmachine wrote: post #11

This is pretty, but non-reversible it isn't. The colors update with every keystroke, making it easy to determine letter by letter, which keys are being pressed. This is a significant hole in many situations (screencasts, recorded presentations, or anywhere someone can point a camera at your screen). Simple fix: Wait for 300ms of keyboard inactivity before computing the colors. This way you only get the colors when th…

The keyboard delay would be a little annoying in my opinion. The password is usually the last thing you type into a login form and as such immediately hit enter after typing. Having to wait 300ms for it to update would likely result in me not using the colour-hash.

Perhaps a timer that decreases as more characters are entered, so that once 8+ characters have already been typed the hash is updated almost instantly?

Re: Chroma-Hash: a sexy, non-reversible, live visualization of password field input

#70

Post by zackattack »

calambrac wrote: post #55
zackattack wrote: post #51

Earlier quoted context omitted.

This has been a big deal around the net as well as HN recently. Your sarcasm is both inappropriate as well as indicative of ignorance. Parent should be upvoted despite the superfluous comment of "didn't have time to read the source", because at first, I didn't perceive why this was useful.

Yeah, ignorance. I read the Jakob Nielsen article and all the responses, don't worry. At least with his proposal, you got a checkbox to enable the feature, and you knew explicitly without having to understand how hashes work that you were giving away your password if you typed it in view of other people.

I'm sorry. Thanks for clarifying.
Post reply on HN