It wouldn't be retarded if it wasn't expending a lot of effort (and confusing the hell out of users) to get to that bad destination. But that's what it does.
When you consider "solutions" to this "problem", model it against an adversary with a camera.
The author of this post means well, but just masking the password characters, like every secure system has done for the past couple decades, remains the right answer.
A: It only uses the first 20 bytes of the hash. You could narrow it down from this if you were really determined, but you'd not be able to reverse it.
B: The visualization of the sparkline doesn't have the fidelity to determine between characters 6 and 7. So you'd have a range of possible characters.
C: The alternative being suggested by Jakob Nielsen is no masking at all ( http://www.useit.com/alertbox/passwords.html ) - which is less secure? I know this isn't the best argument, but it still is -an- argument.
With that out of the way, my paranoid mind agrees with you in this context: just masking the passwords is the more secure solution. But that doesn't mean that experiments to provide a more usable approach with (arguably) equal security should be avoided.
(b) The goal of the attack isn't to magically conjure the password; it's to magically conjure a searchlist of several tens of passwords, which is a game-changing improvement over a searchlist of, say, 72^8 passwords, or even tens of thousands of dictionary words.
(c) The alternative suggested by Jakob Nielson is manifestly and categorically asinine.
Good on you for a finding an application for visualizing a SHA1 hash. You score maximum points for cleverness. But now you should retire this idea.
Fidelity of the graphs wouldn't matter at this point, you would just take the closest match and backtrack if necessary.
Which can record your hands? :)
I figure that the offline dictionary attack could be foiled if this was a Firefox extension that generated a random salt on installation. (of course, this doesn't work if you want to play WOW on an Internet Cafe)
My main reaction to the experiment is that I don't know many people who touch type (at least when it comes to their password): I've had people accidentally type their password on the username field in front of me countless times because they weren't even looking at the screen.
I don't see why I should worry about big brother FUD when I could embarrass myself any time by accidentally pressing caps lock instead of tab.
People just like memes. They're fun to talk about. I promise you there are 1,000 better problems for you to tackle in your app than the suboptimality of password masking. This guy managed not only to waste time, but also to promote an actively evil security extension.
I actually don't think the idea of this is all that terrible, just that the implementation isn't right. For example, I can't think of a reason why the representation needs to be unique -- the user would only need a clue if their password is the wrong length or if they likely have a typo. Also, the specific representation used is too resource-intensive; three colored boxes would work just as well.
Still, even if the system returned hundreds of possible passwords for a given hash, and even if it wasn't resource-intensive, it's still providing clues to a third party, which you don't generally want to do. You're still dramatically decreasing their search space.
EDIT: On second thought, there might be a way to make this a little less horrible. If you assume that the user will generally be very close to correct in typing their password, then you could tune a function that would produce dramatically different results for similar passwords, and similar results for dramatically different passwords -- a kind of inverted hash function. Such a function probably already exists, I'm just not familiar with it. If you did that, and completely obscured what the user was typing, so that an eavesdropper couldn't tell the length of the password, then you might be increasing the search space compared to simply displaying asterisks.
Kudos for imagination.
Back to the initial problem, after successive attempts you may remember the shape and colors, problem is, most business complain new users can't remember their passwords after registering, so there won't be a second time.
The only way of better remembering something is by viewing it.
I just find it interesting to observe the discrepancies between perception of security and actual math-backed security.
(b) Obviously. Still extraordinarily difficult given this implementation IMO. But I take your point genuinely.
(c) Agreed.
If you weren't so friggin inflammatory I'd think we could come to a conclusion here. I could definitely be using a more lossy visualization to be more secure. This is something I'll look into, even though I'm sure you'll still consider it 'retarded' even if it helps your grandma login to her googles more often, making you get less phone calls to fix it as a result. She's got that palsy you know.
You get full props for grandma, her googles, and the palsy, although anything you could do to allow either of my grandmothers to log into the googles would qualify you for much more than HN props. I'm sorry you think I'm inflammatory, except you and I both know I'm not.
I love "cameras could eventually brute force" in your sentence, as if we were actually talking about some crazy hard feat of image analysis and cryptography, rather than running a dictionary through SHA1 and comparing colors.
Got any more arguments, sho?
You should have raised the scenario of, say, spying on a screen through a window from the other side of the street. That's a much better example and in that one, you might actually have a point, although I understand it's against the rules in many organisations to allow a screen to face a window. But the "in the same building" one was ridiculous. Why bother brute forcing your squiggly coloured blotch when they can just put a tiny camera in every light, or whatever?
No, no further arguments. I agree it's a bad idea, of course.
And c'mon, no common security camera could pick up a usable copy of that little graph thing. Half the time they're not even colour. It would take specialised equipment. I was thinking more like thieves going to some rich person's house, finding a computer screen near a window, attaching a high-res camera and waiting for them to log on to internet banking, or something. Sure, in that situation, very bad risk. But geeze, if you're sitting in the Chinese embassy and logging on to the CIA web site using your fingers on a keyboard, tiny coloured graphs of your password hash are the least of your problems.
It is an interesting idea though. I don't like how much information is in the graph, but if it was reduced to just, say, a block of 16-bit colour, that might still be a useful hint to users. Probably more useful actually; the detailed graph is just confusing. And I don't think even tptacek would claim 16 bits of colour is much of a hint brute-forcing a 256 bit hash.
Taking that idea and running with it a little - you could even "salt" the colour randomly for each user, feeding the salt value into the JS. In fact, implementing a per-user salt for the system as proposed would eliminate all of tptacek's concerns. It wouldn't be the same across sites, but it would be consistent per site. I might suggest this as an improvement.
update: duh, the system wouldn't know which salt to load before the user logged in .. forget that idea. Unless it was stored in a cookie of course. Or could be loaded via AJAX when focus shifted out of the username field.
But I have an improvement on your system. Instead of a 16 bit salt, use a FIVE HUNDRED TWELVE bit salt. That's 32 times the saltiness! But just to trip evil hackers up, why don't you call that salt "PHPSESSIONID". I think that scheme is so salty that you only have to have users type their password just once!