Hacker News new | past | comments | ask | show | jobs | submit login

How often do you type your password next to an adversary with a camera?



I did it about 50 times today. I'm a building full of cameras. Tell me, how often do you sweep the surrounding area for cameras before you log in somewhere? Thought so. How many times have you ever logged into something from an airport? Ever hear about the Microsoft Blue Hat talks about the pen testers who collect credentials at Sea-Tac?

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.


Why are you worried about how people with cameras could eventually brute force your password from that tiny, fuzzy smear of colour on the screen, when those same cameras can see your fingers typing the whole damn thing in, in plaintext?


Because those cameras can see my screen easily, and not my fingers typing on the screen? Because my fingers aren't perpendicular to the floor? Because even if I was going to concede that the image of the SHA graph was going to be fuzzy, just getting the vicinity of the color reduces my search space by 1/2^(16..24)?

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?


If someone is trying to learn your password from cameras nearby, they will make sure they can see your keyboard. Of course. If you're in that kind of hostile environment, nothing is safe except biometric or card authentication. Your concern is misplaced.

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.


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.


Salts. The "Hitler" of computer security discussions.


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!


Right, whatever, I was trying to have an actual conversation.


Nah, that'd be one-time pads.


The goal regardless is to not provide a visual clue to an eavesdropper which they could use discover your password.

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: