Password Masking research

24 Jun 2009 - 3:00pm
5 years ago
18 replies
1157 reads
ELISABETH HUBERT
2007

Hi all,

In light of Nielsen's new article seen here:
http://www.useit.com/alertbox/passwords.html along with other user
frustration feedback, my team and I started looking at other
solutions to masking passwords on creation. Although I know the
simplest and best answer is probably not to mask the password at all,
it is highly doubtful that that answer will fly with our client.

One team member mentioned the way masking is done in iPhone seen
here: http://rc3.org/2008/07/13/iphone-20-password-masking/ as an
interesting solution. Does anyone know if this can be done in web
browsers? Are there other solutions or research items that anyone out
there has seen?

Lis ~
http://www.elisabethhubert.com

Comments

25 Jun 2009 - 12:53am
Jeff Howard
2004

Hi Elisabeth,

I haven't seen this done in a non-mobile web browser natively, but
it's possible to reproduce with Javascript (or in Flash with
Actionscript) with a bit of effort.

Juggling the user input to progressively mask the text seems unwieldy
at first glance but it's entirely possible. Instead of a password
field you basically take a normal text field and alter its contents
on each keypress, replacing characters with asterisks or a similar
placeholder. But then you need to store the actual input in a hidden
form field. As I say, unwieldy.

From a design angle, you could also look at the Mac OS X wireless
network connection interface. It has a "Show Password" checkbox as
mentioned in the Nielsen article. You'd use a similar Javascript
technique to achieve this in a browser.

// jeff

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=43168

25 Jun 2009 - 12:23am
Justin Maxwell
2009

Lis,

This can be done in web browsers by using input type="text" instead of
type="password" and using a timed javascript function bound to the
onchange event that passes/appends the most recent character to a
hidden form element and replaces it in the visible field with a "•"
character (•).

Best,
Justin

On Jun 24, 2009, at 1:00 PM, ELISABETH HUBERT wrote:

> Does anyone know if this can be done in web
> browsers?

25 Jun 2009 - 3:55am
Danny Hope
2008

2009/6/24 ELISABETH HUBERT <ehubert22 at gmail.com>:
> In light of Nielsen's new article seen here:
> http://www.useit.com/alertbox/passwords.html along with other user
> frustration feedback, my team and I started looking at other
> solutions to masking passwords on creation. Although I know the
> simplest and best answer is probably not to mask the password at all,
> it is highly doubtful that that answer will fly with our client.

Does anyone else suspect that this might be *an issue for browser
vendors* not designers?

--
Danny Hope
User Experience Consultant, Brighton (UK)
+44 (0)7595 226 792
@yandle

25 Jun 2009 - 4:31am
Yohan Creemers
2008

The way masking is done in iPhone originates from the days a phone had
a numerical keyboard where you had to press the [9] key four times to
get a 'Z'. In that scenario visual feedback was essential.

The iPhone solution seems to combine worst of both worlds: users
don't get full visual feedback and miscreants can still look over
their shoulders.

You might consider a 'Show password' checkbox as Jeff suggests, or
follow Jakob's advise and offer a 'Hide password' option.

- Yohan

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=43168

25 Jun 2009 - 4:44am
Yohan Creemers
2008

Danny wrote:

>Does anyone else suspect that this might be *an issue for browser
vendors* not designers?

Shouldn't browser vendors have interaction designers in their
development team?

Designers should not wait for market or technology to improve user
experience.

- Yohan

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=43168

25 Jun 2009 - 5:14am
Danny Hope
2008

2009/6/25 Yohan Creemers <yohan at ylab.nl>:
> Shouldn't browser vendors have interaction designers in their
> development team?
>
> Designers should not wait for market or technology to improve user
> experience.

Are you saying that this is or is not a browser problem?

--
Danny Hope
User Experience Consultant, Brighton (UK)
+44 (0)7595 226 792
@yandle

25 Jun 2009 - 6:28am
Troy Gardner
2008

Curious, I tried playing around with it in Flash.

Trickyness is introduced if it's to behave like another textfield
supporting selecting, backspace, cutting and pasting. Having to modify
the original word via array operations.

Also you need a fixed size font to keep the word from jumping aroudn
match. Meaning you can't replace m and i with a bullet and have them
spaced the same. This might interfere with the graphic design of some
sites, but there are alternative ways to mask. Played with blacking
things out - hard to see select, blur seemed viable.

Also in backspacing I found it preferable to keep the last character
in the word visible over the delay then hide.

Troy.

25 Jun 2009 - 6:54am
Joshua Porter
2007

A few months back I was working on a piece about password masking with
Josh Viney that touched on many of these issues...

Before we were able to publish it, Viget Labs beat us to it.

http://www.viget.com/advance/password-fields-are-annoying/

They show several javascript techniques that handle the situation
nicely. (at the bottom you'll find the iPhone-like solution)

One very important issue that Nielsen seems to be glossing over is
that one password is often used for many accounts...and so when
someone steals a single password they are often getting the keys to
the kingdom, so to speak.

As a designer I prefer to keep control in the user's hands at all
times (while also providing feedback when they want it), and so I'm
using the "show password" technique or the iPhone-like technique in
recent projects.

Cheers,

Josh

Joshua Porter, Founder
Bokardo Design
Interface design & strategy for social web applications
phone: 508-954-1896
http://bokardo.com
porter at bokardo.com
twitter: bokardo

25 Jun 2009 - 8:32am
ELISABETH HUBERT
2007

Hi all,

So far the feedback has been great and extra helpful! I'm liking the
show password solution myself as that seems to be a crowd favorite.
Def will help to get even more thinking going on my end. Examples and
articles are highly appreciated. If anymore thoughts/ideas come your
way feel free to share!

Thanks again,
Lis
http://www.elisabethhubert.com

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=43168

25 Jun 2009 - 9:29am
David Mulder
2007

Thanks for sharing this Nielsen column. It's a topic I have been
experimenting with a bit lately (based on my own findings while conducting
user research) but had not found answers on.

Ultimately I think a solution has to be implemented at the browser level,
but as designers we can help inform what that should look like.

I favor a modified version of the "show password" checkbox. Perhaps it could
be checked by default, and then switch off after a user changes focus or
submits the form. This would entirely be controlled by JavaScript, and if JS
is disabled then it defaults to standard password field behavior.

Nielsen is right in that this behavior is outdated, and it's great to hear
so many of you already experimenting with alternatives.

25 Jun 2009 - 10:28am
Diego Moya
2005

Thinking of this as an information problem instead of a security one,
what is needed to solve it is something like the hash codes as used in
cryptography.

You don't really need to show the *whole* password, just enough
information derived from it so that the user will notice if there was
an error. For an example on how it could work:

- Say, the chosen password is HOMELAND.
- As a simple hash, remove every second letter: HMLN
- Shift each letter one character down: GLKM
- For this result to be usable, combine each obtained letter with the
nearest vowel: GILOKOMO

If the user mistypes the password, a different check-word will be produced.
For example: HOPELAMD -> HPLM -> GOKL -> GIOUKOLO *error, the
password is wrong.

Of course, a real hash function should be used that utilizes *all* the
information in the original password, not half of it! The important
property of a hash function is that the original information can't be
recovered from it, so the password is safe. Much better for security
than a plain-text exposed password, isn't it?

This process has a small usability problem in that you'll have to
learn the check-word for every new used password, but login is such a
repetitive procedure that this learning should happen quickly.

If you try to patent this procedure, I will claim prior art :-)

Diego Moya

27 Jun 2009 - 7:27am
dirtandrust
2008

There were no comments allowed on the Jakob Nielsen piece so I'm saying my .02 here...

What he neglected to mention is that key loggers capture your password (and store it on a computer for later retrieval) much more often than "shoulder surfing" does. Not masking the password seems quite negligent in my view.

Though I realise keyloggers can get the typed information even before it makes it to a masked password field, at least making the effort seems to me to be the way to go.

How could Mr. Nielsen not see this?

Sometimes we sacrifice convenience for security and I think this is one of those instances. I'd never sign into a bank site, for example, that didn't have password masking.

Maybe I should start another thread on this...

25 Jun 2009 - 10:11am
Justin Maxwell
2009

On Jun 25, 2009, at 4:54 AM, Joshua Porter wrote:

> One very important issue that Nielsen seems to be glossing over is
> that one password is often used for many accounts...and so when
> someone steals a single password they are often getting the keys to
> the kingdom, so to speak.

True. A previous poster mentioned the AirPort/Wireless Network box's
use of the "show password" checkbox, and...

> As a designer I prefer to keep control in the user's hands at all
> times (while also providing feedback when they want it), and so I'm
> using the "show password" technique or the iPhone-like technique in
> recent projects.

There is a substantial difference between web input forms and these
two contexts that I'm not sure has been addressed yet:

1. iPhone: input method yields a high number of unintentional
keypresses, especially for new users unfamiliar with the keyboard.
The solution is to display the most recent character of input in the
password field for something like 500ms to give the user visual
feedback and confirmation of desired behavior. There is a small
tradeoff of security for usability, but the reduced screensize of the
iPhone probably makes it less likely to be read over the shoulder,
especially if the user keeps the device close.

2. Wireless passwords: while the input method is standard, the
password is a non-standard, monster of a string. Users frequently key
in 40-character hex strings. The need to compare the password given
to them, whether on paper or in email, is vital to getting it correct,
and the "show password" toggle affords this. (If you've ever dealt
with one of these you probably remember getting it wrong 50% of the
time, or someone reciting it to you character by character to verify
it). Another tradeoff of security for usability, but in this context
the user is given a choice to evaluate the risk.

So yes, I agree that there are problems with the bullet masking of
type="password" fields, but it serves a necessary evil for many
contexts. When we have optic nerve implants this will all be moot.
Until then, I need to block prying eyes in a Starbucks from any
possibility of seeing a user's banking password, and unfortunately
that means preventing the user from toggling visibility with a
checkbox...because he or she might not be fully cognizant of the risk
involved. If security is compromised, the blame is still on us as the
designers of the system.

So far one of the best error-prevention methods I've seen is the use
of a caps lock symbol in the OS X login window to alert the user his/
her capslock is active.

What other methods have folks on the list explored? I wonder if one
could take advantage of the contrast and color shift of displays
outside the optimal viewing angle to display the password to the user
but reduce its visibility from outside, say, a 15 degree angle.

Best,
Justin

9 Jul 2009 - 4:29am
Fredrik Matheson
2005

http://lab.arc90.com/2009/07/halfmask.php is an experiment in half-masking
passwords. Might be worth looking at.

9 Jul 2009 - 7:46am
Niklas Mortensen
2009

Some excellent points raised her!

Have a look at what i think is the slickest implementation of
iphone-style half-masking i've seen yet.

http://blog.decaf.de/2009/07/iphone-like-password-fields-using-jquery/

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=43168

9 Jul 2009 - 1:20pm
James Page
2008

Has anybody actually done some research into how many people it effects?
I find most times I type a wrong password it is not because of a typo,
but because it is the wrong password. Masking/Unmasking will not help here.
For example typing my Twitter password into Gmail, or my Gmail password
into Twitter.

When I enter passwords I am doing it as a reaction. I don't know if a am
actually looking at the screen.

One solution for non hidden passwords could be only asking people for
two random nth characters of their password. That way anybody looking over
the shoulder would only get two of the characters of password. If you get
the characters wrong then the system would ask for another two random
characters.
As long as the password includes Upper, lower and punctuation characters. It
would be secure. Personally I hate using the approach above.

But as I said above, I don't think anybody knows if this is a real issue or
not. And as somebody who used a Internet Cafe at 1 am because I was locked
out of an apartment, I appreciate having the mask.

All the best

James
http://blog.feralabs.com

2009/7/9 Niklas Mortensen <niklas at interactionlove.com>

> Some excellent points raised her!
>
> Have a look at what i think is the slickest implementation of
> iphone-style half-masking i've seen yet.
>
> http://blog.decaf.de/2009/07/iphone-like-password-fields-using-jquery/
>
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the new ixda.org
> http://www.ixda.org/discuss?post=43168
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

9 Jul 2009 - 3:31pm
ambroselittle
2008

On Thu, Jul 9, 2009 at 2:20 PM, James Page <jamespage at gmail.com> wrote:

> Has anybody actually done some research into how many people it effects?
> I find most times I type a wrong password it is not because of a typo,
> but because it is the wrong password. Masking/Unmasking will not help here.
> For example typing my Twitter password into Gmail, or my Gmail password
> into Twitter.
>

I agree. On iPhone and maybe other mobiles, the chance of typo is way
higher. I can't say how many times I hit the wrong key on my iPhone, but it
is often, and the little preview before mask helps a lot there. But I have
to say I've been in public rooms and felt exposed even just having this on
my iPhone; I would probably not use a site that tried this for conventional
Web.

The other thing is that when you type on a keyboard, especially something as
rote as a password, you type so fast that the little preview thing doesn't
help anyways.

In short, I think the preview then mask approach really only works on
iPhone/mobile. We should not be encouraging folks to try this or other
unmasked approaches that are not opt in. I mean, when I have someone
nearby, I get self-conscious even with masking, and if someone else is, for
instance, signing in to do something for me (like adding my computer to a
domain), I look away out of courtesy--so I don't even see their fingers on
the keyboard. Not masking is just crazy talk. I am still baffled that
Nielson suggests it.

-ambrose

10 Jul 2009 - 1:24pm
DrWex
2006

Forgive me if I'm repeating a point that has been raised before...

When considering whether to mask a password I think it's important to
remember that there are other situations in which the password can be
made to appear other than it being typed in character-by-character.

The most common case (which I'm dealing with now) is the situation in
which the user's browser has been told to remember the password. This
is a default feature in at least IE and Firefox and probably exists in
other browsers. In cases where the browser's auto-complete features
are turned on (also easy to do) a single keystroke in the username
field can pre-fill a remembered ID and password.

The question, then, is slightly different - under what situations
could someone other than the intended user be in a position to type
that keystroke and thereby potentially see an unmasked password? If
the computer is always only used by one person then it's a moot
question. In the real world, though, there are often other people who
may be at the controls - a babysitter or party guest (at home), a
coworker or temp (in an office) - and I'm sure you can think of other
cases.

In these situations the point of masking the password is to conceal it
not from the hypothetical shoulder-surfer (a case I would consider
rare) but from every other person who might use the same browser.
That seems to be a much larger set of people.

Once again half-masking may provide a solution. A password brought up
by one of these indirect routes could appear fully masked
independently of the way it's shown during the process of entry.

My $0.02 anyway...

--Alan

Syndicate content Get the feed