Chroma-Hash: a sexy, non-reversible, live visualization of password field input
mattt.github.com
mattt.github.com
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.
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?
Also, because each step is only 1 character different, it's very unlikely that you will get collisions, even with a truncated md5 hash.
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.
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?
Still, pretty cool demo and very nice colour schemes.
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)
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.
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?
OK, so a user makes a mistake, and they notice their n characters in the first field and their n characters in the second field generate different colors.
How does this help them determine which of the two fields has what they intended to enter?
Also since the user types each field at a separate time, how does the character-by-character hashing help? What utility to the user is there from, having typed 'password' into the first field which shows brown and blue, knowing that typing 'p' in the second field made the second field green?
Your average user is going to be completely perplexed by this and have no idea what it's even for. I would argue that this is far less usable for the average user than the old-fashioned implementation of clicking 'Submit', doing a non-AJAX round-trip, and then displaying a message that the passwords don't match.
E.g. If you see the colors of your password everytime you log in, you will probably learn that your password is correctly typed if you see the colours purple-green-olive.
Whenever you spell your password incorrect (and thus see 'blue-pink-black' for instance) you will notice it immediately, without pressing the 'login' button and being presented with a (not so nice) "Invalid username/password" screen.
It helps in that it lets the user know that the password is wrong the instant they've finished typing it, which might be a nice touch if it takes a long time to verify a password. They still don't know where the mistake is though, so they have to retype the entire password.
Wow.
Is there a Nobel Prize for web design yet?
Challenge:
Can someone find a password that describes the colors it makes?
e.g. "redgreenblue" shows red, green, and blue
Not to just be a smart-ass, I tried a few others, but couldn't find any that worked well.
Still trying to find one for all three colours. (This is fun! :P)
"wild blue yonder" produces two blue bars on the left.
I found it by typing in a random password, then using as a password the colors from that password, and repeating until I got the self-referential password. I can't think of a good reason why this should work, though. And you might argue that the third color there is really purple, not pink.
New question: lots of countries have flags which consist of three stripes. Is there a country whose chromahash is its flag?
And if somebody can take video of the screen they could take video of the keyboard too, no?
However, this would mean the hash is different each time, so it would be no good for confirming your password is correct before you login. For the registration case, just show a tick when the fields are equal. Or just wait for the round-trip, it's not that bad.
Frankly, the last month's talk about improving password fields is boring: it doesn't need doing. I type passwords without thinking, about twice the speed I type normally, and I don't make mistakes.
Something I'd like to see a password plugin/script that hashes my password with the site URL, so if they lose my password, its not my password they lose, its a site specific hash - anyone know of one?
So the chromatically-impaired will not lose anything over current functionality, they just won't get the benefit.
I'm not arguing the merits of this concept; I'm just clarifying its intent. There has been a recent wave of design fury over the HTML password input field (the one that obscures keystrokes with dots) Sites with a bajillion users have become concerned about the small percentage of users who get frustrated by failed login attempts and leave. Wanting to avoid turning users away, they have started to experiment with ways to make the field more usable.
Perhaps user disengagement resulting from input type="password", for some, translates to a measurable amount of money. Or maybe it's just a matter of trying to reduce support costs from the volume of "I can't log in" calls.
Either way, it's an interesting problem for UI design specialists.
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.
It seems to me that the simplest fix would be to add something like a seed value to the input or the triplet colors and then randomly generate the seed each time the page is loaded. At that point someone replaying or recording the colors would have no idea what seed would have been generated, but as long as both fields use the same seed the color triplet would be identical for both.
This is just A Bad Idea.
I'd love it if my keyring showed me the color combo for my password at each site --- then if my computer is stolen my passwords don't go with it; but when I get to a site I haven't logged in to for a few months, I don't have to try ten different passwords to remember which one I used.
Neat css trick, though!
This idea, in its current form, sucks. It's not as bad as what you're suggesting, but it comes close - as has been pointed out by many others, if you can watch the colors change with each keystroke, you can pretty much trivially recover the password.
And it's just unnecessary. Password typos are not some huge problem begging for a solution. If you need quick confirmation of matching passwords, just compare the two fields directly, raise a warning icon if they don't match and a checkmark if they do, and be done with it. You'll even save your users a few brain cycles comparing colors.