[WEB SECURITY] Jakob Nielsen's Stop Password Masking
Michael.Vance at salliemae.com
Wed Jul 15 14:24:04 EDT 2009
If there's a video camera that can get the resolution and frame rate needed to figure out the password from the hashmask, the attacker would be better off aiming it at the keyboard. The implementation in the experiment didn't display anything until there was a brief pause, so someone typing their password quickly (as most of us do once we get past those first few days after we're forced to change it) would provide less information than someone going keystroke-by-keystroke. Finally, I would think that adding a system- or user-specific salt would mitigate the risk of offline brute forcing.
There are a lot of ideas that have been proposed, but no one has put them into general categories yet, so I'll take a shot at it. Keep in mind that we are talking about the entry of passwords, either as a standalone authentication mechanism or as part of a multi-factor authentication system. We're not talking about scenarios that get rid of passwords entirely by replacing them with biometrics or other authentication systems.
1) Complete masking: The status quo. As the user types their password they see asterisks, dots, or whitespace. In most cases, the user at least gets one-for-one feedback for each keypress, although there are cases (e.g., Lotus Notes) that provide many-for-one and there are cases (e.g., the command-line runas.exe utility in Windows) where the user gets no feedback at all. These are advisable in high-security scenarios. Masking is very effective at keeping the password hidden, but is at the very heart of the usability problem that started this whole discussion.
2) Partial masking: These solutions show the actual password, but (in theory) make it readable only by the user. Ideas like showing each character briefly before masking it (e.g., the iPhone method) are still susceptible to video capture and shoulder surfing, although they make it more difficult. Ideas like halfmask are promising, but would need to prove their effectiveness in the field and overcome things like the colorblindness issue. This category could also include hardware solutions like polarized screen filters that limit the angle of viewing.
3) Altered masking: These solutions provide feedback that the user can recognize, but that does not contain the password itself and would require significant reverse-engineering or brute force efforts by an attacker to figure out the password. Ideas that have been discussed that fall into this category include hashmask and the more recently proposed idea to present a consistent-but-scrambled version of the password. I would think that the fundamental technology behind any of these has to be a cryptographic hash function and it would have to be salted and done server-side with asynchronous XHR to be implemented correctly. *If* (and this is still a big if in my mind) we're going to actually move away from complete masking, I like some of these ideas best. They provide a reasonable balance between security and the usability problem that Jakob cites.
4) Complete unmasking: The open kimono. Treat passwords like any other text field. Show them openly and leave it up to the user to secure them and keep them from prying eyes. I don't have a problem with giving users the ability to unmask a password at their discretion on low-security systems, but I believe (and I think that most of the list agrees) that this is a *very* bad idea as default behavior. There are too many situations (working in public, doing a demo, etc.) where others may see the screen as a password is being typed for this to be the default.
Did I miss a category? Does anyone have suggestions for a better taxonomy?
From: Bil Corry [mailto:bil at corry.biz]
Sent: Monday, July 13, 2009 5:44 PM
To: Chris Varenhorst
Cc: Matt Parsons; websecurity at webappsec.org
Subject: Re: [WEB SECURITY] Jakob Nielsen's Stop Password Masking
Chris Varenhorst wrote on 7/12/2009 8:13 PM:
> I thought this thread might be interested in two recent arc90 password
> masking experiments. The basic idea is to meet Jakob Neilson half way and
> mask the password so that the casual observation won't be able to get much
> information from it, but the user can still confirm they typed their
> password correctly.
Thanks for sharing these. A few thoughts on each:
I found that I couldn't read halfmask at all, or even guess at what I had typed. I could, however, read what I had typed if I highlighted the password. I also found I could easily read it if I turned the gamma way up and I also could easily read it on a screen capture image where I tweak the color curves.
As for hashmask, couldn't an attacker with a video camera deduce your password by replaying each hash image generated after every keystroke, then trying every character until it matches, then move on to the next one until your password has been entered? Even if the hash image isn't shown until you are done entering your password, it would still allow an attacker to record the final password hash image, then brute-force it off-line by comparing images without having to round-trip to the server (which is the best alert that a brute-force is taking place).
Join us on IRC: irc.freenode.net #webappsec
Have a question? Search The Web Security Mailing List Archives:
Subscribe via RSS:
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
Join WASC on LinkedIn
This E-Mail has been scanned for viruses.
More information about the websecurity