There are plenty of scenarios where someone would be watching you type your password through a camera, but doesn't control placement of the camera. The most common case would be a security guard who is paid to monitor the cameras but had no hand in the design of the surveillance system.
I'm not saying it's a good idea, I'm saying that tptacek is overstating the risk compared to the far easier option of just spying on the keyboard.
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.
Yeah, yeah. I'm waiting to hear how you could conceivably brute force the password from that graph (and only that graph) if it had a random per-user salt.
I like the authentication system where you are guaranteed a nonce-bearing cookie identifying the user, but still forcing them to type their password. You know, just to be sure.
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!
