Hacker News Reader

Comment by chaosmachine | Hacker News Reader

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 the person is done typing, eliminating the possibility of key by key color analysis.

View on HN

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.

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.

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 harder to guess which keys have been pressed?

If you know the digest after each keypress, the search space for a brute force attack is roughly alphabet size * password length, which is trivial.

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 truncated md5 hash.

Thank-you for the clear explanation.

It strikes me that this reduces password cracking to a game of Mastermind.

Amusement aside, it also allows a cracking attempt to be done without running up against server authentication. Even if the same series of color patterns can occur for multiple passwords, the quantity of attempted server authentications is greatly reduced.

It's actually easier than Mastermind, you only have to guess one character at a time.

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.

It completely doable.

Its unlikely there will be a collision in the first 6 characters of the md5 hash of 'AAAx' where x is [a-zA-Z0-9] and AAA is known. That's only 62 hopes for collision out of a space of 2176782336 (36^6 ... right?)

Think of it this way, if you capture the length of password, and the corresponding 6 hex characters, for every step of the password, that's quite a bit of information!

(a quick check confirms no first 6 character collisions in a-z)

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?

Reply on news.ycombinator.com