[WEB SECURITY] Jakob Nielsen's Stop Password Masking

Schmidt, Chris cschmidt at servicemagic.com
Wed Jul 15 15:52:36 EDT 2009


I too agree that some of the best ideas fall under category 3. I also
had an idea, which was spawned from the observation that we are really
trying to shoehorn in 21st century security considerations and needs
into a system designed 20 years ago which has changed relatively little
to accommodate newer requirements and considerations in the face of a
whole new internet. I personally think that a push needs to be made to
spec a new set of protocols for security on the internet, one that
happens outside of the browser itself and could thereby eliminate
usability issues by removing the need for users to do any browser level
authentication. 

The brief summary of my idea is that a multi-tiered system be put in
place where authentication keys are kept in a key locker that lives on a
secured (or any for that matter) usb thumb drive. 

The key locker is unlocked at the OS level, requiring Operating System
venders to have participation in the initiative. 

Once the key locker is unlocked with the users authentication
credentials (by whatever means the operating system authenticates, ie:
password, key, fingerprint, blood sample, etc.) A trust must be setup
and verified by the user between an application and a key within the
locker. The application only has access to the keys that it is trusted
by. 

When using websites that require a user account, part of the
registration process for a user account would be setting up a new key
and a trust relationship between that key and the browser, and also from
the browser to the website for that particular key. This requires
browser venders to implement new code for that purpose. 

I also proposed that authentication should happen outside of the http
protocol itself and outside of the session/request space of the website.
A new protocol would be created which would be an encrypted tunnel
between two nodes, the client and the auth server, which would then
authenticate the client and authentication checks would be done against
the local auth server on the websites network for larger sites with
several servers, or even on the same physical machine for smaller
single-server sites. 

This initiative would be a huge undertaking, but could be employed on a
grand scale to security sensitive web applications like bank sites and
so forth. The end user would only need to carry his key around with him
to have virtually instant seamless and secure access to his sensitive
information. 

Of course, this system would be overkill for sites and applications
where you are not working with sensitive data, so the original
authentication schemes would still be supported and would likely employ
one or more of the ideas discussed below. 

Now, the likelihood of something like this happening in reality isn't
even slim to none, given the scope of the undertaking and garnering
support for it from OS and Application venders would prove to be nearly
impossible unless mandated by law.

Anyhow, the biggest point I am trying to make is that I don't necessariy
think the right answer is to continue retrofitting hacks and
not-always-elegant solutions on top of a broken system - I think that
there needs to be a whole new system and that it will require
involvement and buy-in from a lot of different sources. 




-----Original Message-----
From: Vance, Michael [mailto:Michael.Vance at salliemae.com] 
Sent: Wednesday, July 15, 2009 12:24 PM
To: websecurity at webappsec.org
Subject: RE: [WEB SECURITY] Jakob Nielsen's Stop Password Masking

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?

-Michael

-----Original Message-----
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.
> 
> http://lab.arc90.com/2009/07/halfmask.php
> http://lab.arc90.com/2009/07/hashmask.php

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).


- Bil


------------------------------------------------------------------------
----
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA


This E-Mail has been scanned for viruses.

----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA



More information about the websecurity mailing list