"Confirm password" field - Superfluous?

9 Jul 2008 - 3:25pm
6 years ago
32 replies
69685 reads
Steven Chalmers
2007

I have a design for a new user registration form in which I am proposing to
not use a "Confirm password" field and would like your feedback on this
decision.
The form will have 4 fields, all of which are required:

1: User name (This will be supplied to the user prior to their using this
form)
2: Password
3: Hint question
4: Hint answer

The form also has some explanatory text that describes the use of the hint
question and answer which is that the pair of fields will be used when the
user forgets their password. If the user forgets their password, or thinks
it was entered wrong, they will will click the "Sign in using the hint
question" link. The hint question will be displayed and the user is to
enter the hint answer. Doing so will sign them in and present them with a
form to reset their password.

The justifications for the decision to not use a "Confirm password" field
are as follows:

a) I believe that it is rare that people type new passwords incorrectly.
b) Assuming that it is rare why should 100% of the people have to retype
the password?
c) In the event that the user does type their new password incorrectly on
the registration page, which they will realize the first time they try to
sign in, they can follow the "Sign in using the hint question" link.
d) Having a second password field doubles the chance that they will make a
typo error on their password.

The resistance I am getting is as follows:

i) It is convention to enter passwords twice.
- My response: I need a better reason than that.
ii) Since we are only showing asterisks or dots for each character the user
doesn't know if they have typed the correct password or not.
- My response: A user is likely to be paying more attention to
the typing of a new password than for most form fields and thus is that much
more likely to get it right. No data to support that, just a gut feeling.
iii) Users would rather find out sooner than later that their password was
wrong.
- My response: Agreed, but at what cost? 1% of the users who
mistype their password benefit from 100% of the users typing their password
twice with no benefit.

Thoughts?

Steven Chalmers

Comments

9 Jul 2008 - 5:57pm
Steven Chalmers
2007

I have a design for a new user registration form in which I am proposing to
not use a "Confirm password" field and would like your feedback on this
decision.

The form will have 4 fields, all of which are required:

1. User name (This will be supplied to the user prior to their using this
form)
2. Password
3. Hint question
4. Hint answer

The form also has some explanatory text that describes the use of the hint
question and answer which is that the pair of fields will be used when the
user forgets their password. If the user forgets their password, or thinks
it was entered wrong, they will will click the "Sign in using the hint
question" link. The hint question will be displayed and the user is to
enter the hint answer. Doing so will sign them in and present them with a
form to reset their password.

The justifications for the decision to not use a "Confirm password" field
are as follows:

1. I believe that it is rare that people type new passwords incorrectly.
2. Assuming that it is rare why should 100% of the people have to retype
the password?
3. In the event that the user does type their new password incorrectly on
the registration page, which they will realize the first time they try to
sign in, they can follow the "Sign in using the hint question" link.
4. Having a second password field doubles the chance that they will make
a typo error on their password.

The resistance I am getting is as follows:

1. It is convention to enter passwords twice. My response: I need a
better reason than that.
2. Since we are only showing asterisks or dots for each character the
user doesn't know if they have typed the correct password or not. My
response: A user is likely to be paying more attention to the typing of a
new password than for most form fields and thus is that much more likely to
get it right. No data to support that, just a gut feeling.
3. Users would rather find out sooner than later that their password was
wrong. My response: Agreed, but at what cost? 1% of the users who mistype
their password benefit from 100% of the users typing their password twice
with no benefit.

Thoughts?

Steven Chalmers

10 Jul 2008 - 2:55am
Suman Paul
2007

I guess "confirm password" is a legesy which never got changed.

I think you should go ahead with your gut feeling and actually test user
response after deployment.
If the rate of "forgot password" or "mistyped password" rate increases i's
better to have the confirm password.

If not then you are confirmed that it's right decision to drop "confirm
password"

regards
suman

"Steven Chalmers" <steven.john.chalmers at gmail.com>
Sent by: discuss-bounces at lists.interactiondesigners.com
07/10/2008 04:27 AM
Please respond to
mail at stevenchalmers.com

To
IxDA <discuss at ixda.org>
cc

Subject
[IxDA Discuss] "Confirm password" field - Superfluous?

I have a design for a new user registration form in which I am proposing
to
not use a "Confirm password" field and would like your feedback on this
decision.

The form will have 4 fields, all of which are required:

1. User name (This will be supplied to the user prior to their using
this
form)
2. Password
3. Hint question
4. Hint answer

The form also has some explanatory text that describes the use of the hint
question and answer which is that the pair of fields will be used when the
user forgets their password. If the user forgets their password, or
thinks
it was entered wrong, they will will click the "Sign in using the hint
question" link. The hint question will be displayed and the user is to
enter the hint answer. Doing so will sign them in and present them with a
form to reset their password.

The justifications for the decision to not use a "Confirm password" field
are as follows:

1. I believe that it is rare that people type new passwords
incorrectly.
2. Assuming that it is rare why should 100% of the people have to
retype
the password?
3. In the event that the user does type their new password incorrectly
on
the registration page, which they will realize the first time they try
to
sign in, they can follow the "Sign in using the hint question" link.
4. Having a second password field doubles the chance that they will
make
a typo error on their password.

The resistance I am getting is as follows:

1. It is convention to enter passwords twice. My response: I need a
better reason than that.
2. Since we are only showing asterisks or dots for each character the
user doesn't know if they have typed the correct password or not. My
response: A user is likely to be paying more attention to the typing of
a
new password than for most form fields and thus is that much more
likely to
get it right. No data to support that, just a gut feeling.
3. Users would rather find out sooner than later that their password
was
wrong. My response: Agreed, but at what cost? 1% of the users who
mistype
their password benefit from 100% of the users typing their password
twice
with no benefit.

Thoughts?

Steven Chalmers
________________________________________________________________
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

ForwardSourceID:NT00015D1A
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you

10 Jul 2008 - 8:13am
Steve Schang
2008

The user can visually verify correct data entry in all the fields except
the password field (because it is masked). Requiring the user re-type the
password is the only way they can verify they typed the correct password.

I would vote to keep the re-type password field. I have seen some systems
that use javascript to compare the two password fields on the fly. That
way I don't realize I mis-typed my password after pressing Submit.

Steve Schang
Interactive Design Group | eCommerce | Wachovia Corporation
704.715.3845
Usability | iRise | TrendsCast Blog

10 Jul 2008 - 7:54am
Elena Melendy
2008

Should you need support as ammunition against your resistence:

Steven Chalmers wrote:
> i) It is convention to enter passwords twice.
> - My response: I need a better reason than that.
>
It's not such ingrained convention that any user will wonder why it's
not there.
> ii) Since we are only showing asterisks or dots for each character the user
> doesn't know if they have typed the correct password or not.
>
Is that a security issue? Can't you have a radial button to offer a
choice of showing or not showing the password, the way (for example) my
Mac does when I'm re-entering my network password? Or show the password
until the user clicks enter and then have it resolve to asterisks, the
way I've seen on some sites?
> - My response: A user is likely to be paying more attention to
> the typing of a new password than for most form fields and thus is that much
> more likely to get it right. No data to support that, just a gut feeling.
>
I have absolutely the same feeling. I know that I personally pay much
closer attention to the password field than to, for example, typing in
my email address, even though I'm expected to do that twice as well.
> iii) Users would rather find out sooner than later that their password was
> wrong.
> - My response: Agreed, but at what cost? 1% of the users who
> mistype their password benefit from 100% of the users typing their password
> twice with no benefit.
>
>
Yes, this has happened to me before. In every case, it was because I was
in such a hurry to get through the stupid registration process that I
mistyped the password the SECOND time. I finally got a clue and started
copy-pasting from one field to the other.

A completely unnecessary and useless barrier, in my opinion. Thanks on
behalf of users everywhere for taking it on.

Elena

10 Jul 2008 - 8:49am
cneidley
2008

>From a user's point of view, I know that I tend to type rather
quickly. If anything, I probably mistype my password on registration
forms more than anyone else because I'm doing it quickly and assuming
I got it right. I think it would make me feel uneasy if there's no
field to confirm.

Especially when the javascript can tell you instantly if there's a
discrepancy, it takes so little time to retype that I've never thought
of it as an "inconvenience." Also, I think I would get to the login
site and sit there typing and retyping my password for a few minutes
of cursing before realizing that I typed it in wrong at the
registration page.

However, I think Elena's would probably be an even better idea: "Can't
you have a radial button to offer a choice of showing or not showing
the password, the way (for example) my Mac does when I'm re-entering
my network password?"

With the "hint questions" I always feel like anyone with a facebook
account or a blog can dig around and find the answer to most generic
hint questions. So I tend to make mine so ridiculous that I can rarely
remember the answer. (Of course, most people might not be as paranoid
as I am.)

In essence, you're asking your users to memorize two passwords: the
password that they maybe typed in, and the hint answer. That seems
like much more of an inconvenience to me, and it feels less secure.

-------------
1. It is convention to enter passwords twice. My response: I need a
better reason than that.
2. Since we are only showing asterisks or dots for each character the
user doesn't know if they have typed the correct password or not. My
response: A user is likely to be paying more attention to the typing
of a new password than for most form fields and thus is that much more
likely to get it right. No data to support that, just a gut feeling.
-------------

"It's just a gut feeling." isn't all that different than "It's
convention." They both require more testing. I think you're going to
have a lot of people passionate about either side. I'd say if you can,
it's probably best to go ahead and usability test it both ways. I'd be
really interested in hearing which comes out on top.

My newbie two cents,
Christine Neidley

10 Jul 2008 - 9:02am
Paul Trumble
2004

Steven,

We had a form like that for several years where we only asked for the
password once.

For a username we required an email address. I had it changed to include a
second box for confirmation, but the reason had nothing to do with typing it
incorrectly.

I observed multiple instances in usability tests where the participant
interpreted it as asking for the password to their email account, which
caused tremendous abandonment of the process. We had always associated
abandonment at this point to be due to the email requirement, but a
substantial portion was because of the password.

So we added a second password field which we think clarifies that we would
like them to create a password in relation to our site, and the data backs
that up.

I don't know if you will find the same issue with a user-created username,
but since most people have usernames on multiple sites that might be the
case.

I'm not a big fan of being a trailblazer, particularly when it's something
like a registration where the user will have very little experience with
your site. The more you can use their experiences on other sites to give
context to yours, the better off you are.

Paul Trumble

--
The truth is more important than the facts - Frank Lloyd Wright

http://www.trumbling.com/
http://www.flickr.com/photos/paultrumble/

10 Jul 2008 - 12:36pm
Jeremy White
2008

How much easier is it to guess someone's hint question than it is
their password? I'm guessing it's a lot, considering you're given
a hint and the answers are usually given as simple words, not random
characters as good passwords could be.

I would consider if is the security risk was worth it.

Is there some mechanism that would make giving an answer to a hint
just as secure as a password? I can't think of one, but if there is,
then maybe forgoing the password altogether in favor of the hint would
be better.

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

10 Jul 2008 - 12:37pm
jabbett
2008

I think the terminology you use is confusing two separate concepts out there.

First is the "password hint." This is typically a phrase that will
jog one's memory of one's actual password, like "my first dog's name
with a hyphen in the middle."

Second is a "secret question and answer." This is typically used to
let a user reset his password when it's forgotten, and will often be
coupled with an e-mail message sent to the address tied to the
account. The security community has roundly rejected this practice --
all you're doing is letting your users have an insecure password.

http://www.schneier.com/blog/archives/2005/02/the_curse_of_th.html

A great deal of people could find out my mother's maiden name,
father's middle name, etc., and at least 30 classmates of mine know
who my first grade teacher was. When it's coupled with e-mail, it's a
bit safer, since you'd also have to intercept my e-mail account to
confirm the change.

I work with personal health data, so we try to be very careful with
account security. If you're designing a system that won't hold any
sensitive information, a weak security scheme probably won't raise any
red flags.

-Jon

On Thu, Jul 10, 2008 at 10:02 AM, Paul Trumble <paultrumble at gmail.com> wrote:
> Steven,
>
> We had a form like that for several years where we only asked for the
> password once.
>
> For a username we required an email address. I had it changed to include a
> second box for confirmation, but the reason had nothing to do with typing it
> incorrectly.
>
> I observed multiple instances in usability tests where the participant
> interpreted it as asking for the password to their email account, which
> caused tremendous abandonment of the process. We had always associated
> abandonment at this point to be due to the email requirement, but a
> substantial portion was because of the password.
>
> So we added a second password field which we think clarifies that we would
> like them to create a password in relation to our site, and the data backs
> that up.
>
> I don't know if you will find the same issue with a user-created username,
> but since most people have usernames on multiple sites that might be the
> case.
>
> I'm not a big fan of being a trailblazer, particularly when it's something
> like a registration where the user will have very little experience with
> your site. The more you can use their experiences on other sites to give
> context to yours, the better off you are.
>
> Paul Trumble
>
>
>
> --
> The truth is more important than the facts - Frank Lloyd Wright
>
> http://www.trumbling.com/
> http://www.flickr.com/photos/paultrumble/
> ________________________________________________________________
> 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
>

10 Jul 2008 - 12:51pm
Loren Baxter
2007

I personally love the confirm password field. When I'm entering a
highly complex and secure password such as fr5^n(!QD#asdf, it's
really easy to mess up. Without the confirm field I can think of
many instances when my password would have been wrong.

So please count me as one user who votes "no" to removing the
confirm password field.

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

10 Jul 2008 - 1:06pm
Jeremy White
2008

The way it's written, it doesn't look like an email is part of the
plan; just answer the question and you're logged in and allowed to
change your password.

Sending the person an email is definitely not going to be such a
security risk (such as the way IxDA.org handles log-ins).
This won't work in every situation however. In creating an elearning
site for state highway maintenance workers, I found that many of the
students either didn't have an email address or didn't know how to
check their email address if they did have one. In this case, using
email as the sole means of any communication wasn't an option, so we
stayed with the password / confirm password method.

If email isn't an option (or maybe I'm missing something else),
then it seems like this proposed alternative is a question/secret
answer solution and a security issue.

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

10 Jul 2008 - 2:08pm
Steven Chalmers
2007

@ Jeremy regarding: "How much easier is it to guess someone's hint
question than it is their password? I'm guessing it's a lot,
considering you're given a hint and the answers are usually given as
simple words, not random characters as good passwords could be. "

My apologies for not giving enough detail on the hint Q&A. Our
proposal is to have the user create their own hint question and
answer. The hope is that they could create something more memorable
than having to select from a list of questions.

What is to keep a user from using a "simple word" as their
password? Even if you require digits in the password the common
response is to substitute zero for the letter "o" and 1 for the
letter "l" or "i".

Steven

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

10 Jul 2008 - 2:11pm
Steven Chalmers
2007

@ Jonathan Abbett regarding: "I think the terminology you use is
confusing two separate concepts out there."

Sorry you didn't find my terminology clear. I'm not proposing a
"Password hint", nor did I call it that.

The proposal is to have a back-up, automated mechanism for allowing
users access to the system and to reset their passwords.

Steven

Fortunately this is application is internal and does not contain
highly secure information.

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

10 Jul 2008 - 2:13pm
Steven Chalmers
2007

@ Loren Baxter regarding: I personally love the confirm password
field. When I'm entering a highly complex and secure password such
as fr5^n(!QD# asdf, it's really easy to mess up. Without the confirm
field I can think of many instances when my password would have been
wrong.

While I respect your position and understand that you worry about
messing up entering your password I'm confused by how it is
different to enter the password one time on the registration page
versus one time on the log in page.

Steven

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

10 Jul 2008 - 2:22pm
Patricia Garcia
2007

The difference between the password being simple and the answer being
simple is the fact that the answer, is well an answer to a question.
The password has endless possibilities of simple answers.

Not that my users are the same as yours, but we did a survey to find
out if our users prefer to make up their own security question or
have a list of choices to choose from and they overwhelmingly wanted
the list to choose from. I can only guess from the responses that
they felt thinking up a good username and password was enough, they
didn't want to have to think up a security question as well.

You are already placing registration between them and their goal,
limit how much thinking they have to do.

As for the re-enter password, I believe users have grown accustomed
to seeing two fields when they are creating a new password and one
password field when they are giving you their existing password (or
signing in).

But I wouldn't discourage you, test it out and see what happens.

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

10 Jul 2008 - 2:29pm
Steven Chalmers
2007

@ Jeremy White - Regarding availability of e-mail.

Jeremy, you guessed correctly that these users do not have e-mail.

I believe that the best way to justify my design is to consider the
following design criteria (which I should have included in my first
post):
1) This is a low security risk application
2) The users do not have e-mail
3) We want to lessen the load on our internal help desk for password
resets.

Steven

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

10 Jul 2008 - 9:54am
Carolynn
2008

Hey Steven

I personally hate the hint question and answer and can never imagine
a useful scenario for it. I've put in a user name, thought of a
password, now I need to think of a hint question and answer as
well??! That alone would stall me significantly!! Retyping a
password? Easy! Obviously I'm not certain of how this works on your
site but you say that you will send them a username... in my mind
that's already a cognitive burden as they haven't chosen it
themselves and possibly need to cross reference an email to get that?
The hint stuff on top of that seems a bit much!

Also, think of the effort required if you use the hint question... if
you do somehow remember the answer your job isn't over - was it caps
or lowercase, did I break it into two words or one etc. On various
accounts I have I've had to use this feature 3 times, and I've
never used it successfully. Is there a technical/logistical reason
why they can't just get an email to reset the password if they have
forgotten it?

I'm not against losing the 'Confirm password' field, and I like
Elena's thought 'Or show the password until the user clicks enter
and then have it resolve to asterisks, the way I've seen on some
sites?' ... I've only seen this done with a drop down which
obviously isn't helpful to you!

A side thought - if this is a registration form, why convert the
password to asterisks at all? On login I can understand, but is there
really a need to do it at registration? It seems an accepted norm but
I'm wondering why? I do it on my sites but now you have me thinking
Steven!

Quick question for Paul, before you changed your site to add the
'Confirm password' field, what was the field label for the
password? Was it just 'Password' or did it give a hint such as
'Create password'?

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

10 Jul 2008 - 9:41am
Jacob Geluk
2008

Why not let the user decide!

Make the confirm password field optional and label it thusly.
Only validate against it if it is not null!

Cheers,

Jacob

10 Jul 2008 - 11:08am
Marty DeAngelo
2007

I really like the concept of allowing the USER to choose whether the
password is obscured or not when they enter it. In most cases, I would
expect that they would NOT obscure it (how many people register for
things in places where they'd need it obscured from prying eyes).

-----Original Message-----
Subject: Re: [IxDA Discuss] "Confirm password" field - Superfluous?

Should you need support as ammunition against your resistence:

Steven Chalmers wrote:
> ii) Since we are only showing asterisks or dots for each character
the user doesn't know if they have typed the correct password or not.

Is that a security issue? Can't you have a radial button to offer a
choice of showing or not showing the password, the way (for example) my
Mac does when I'm re-entering my network password? Or show the password
until the user clicks enter and then have it resolve to asterisks, the
way I've seen on some sites?

Elena

10 Jul 2008 - 5:06pm
Anonymous

Hi Stephen,

I definitely vote for keeping the confirm password box.

Especially if you are keen on lessening the load on your internal
help desk for password resets. If you're allowing users to create
blind-typed passwords then the rate of mis-typed passwords (without
the user even realising they've mistyped) must increase.

Unless you're going to allow this mac-style radio option suggested
above which will allow them to see what they type.

I'd be fascinated to find out if you reduced help desk calls without
the confirmation.

Tim

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

10 Jul 2008 - 8:09pm
Josh Powell
2008

I've always disliked double fields of any kind, especially double email
fields which I just copy and paste. I always think, can we please not
assume I'm stupid enough to mess this up?

I've always felt the asterisks were unnecessary on sign up forms. How often
do I sign up for a service with people looking over my shoulder ogling my
password? Never. Make it a plain input form instead of asterisks.

On Thu, Jul 10, 2008 at 12:29 PM, Steven Chalmers <
steven.john.chalmers at gmail.com> wrote:

> @ Jeremy White - Regarding availability of e-mail.
>
> Jeremy, you guessed correctly that these users do not have e-mail.
>
> I believe that the best way to justify my design is to consider the
> following design criteria (which I should have included in my first
> post):
> 1) This is a low security risk application
> 2) The users do not have e-mail
> 3) We want to lessen the load on our internal help desk for password
> resets.
>
>
> Steven
>
>
>
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the new ixda.org
> http://www.ixda.org/discuss?post=31190
>
>
> ________________________________________________________________
> 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
>

11 Jul 2008 - 12:03pm
Torey Maerz
2008

If you want to lessen the load on internal help desk for password
resets then I think you should keep the confirm password box or put
something in for them to confirm that they entered the correct
password. If this is a low security application, does it make sence
to simply display the password when they create it?

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

11 Jul 2008 - 1:59pm
Jeremy White
2008

If the users don't necessarily have email, then I don't think we can
assume that these users have become accustomed to having to retype
their password. After all, there are still people who hardly ever use
computers, especially people without email.

If the security risk is low, then I'll change my vote to "give it a
try".

However as Torey implied, if it's low security, displaying the
password as they type it may be fine.

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

14 Jul 2008 - 12:47pm
Anonymous

What do you think about putting a checkbox labeled "Show password"
or "Unmask" right next to or below the password field, like so:

Password: [____________]
[ ] Show password

when you check the Show password checkbox, it unmasks the password
and shows what you typed in. Uncheck the box, the password is masked
again. This might eliminate the need for the Confirm password field.
Mac OS uses this approach in the system preferences, I believe.

Another idea is to show the password as the user types it, and put a
timer on it, so when they pause for, say 1 second, it then masks the
password. I can see there could be some privacy concerns with this,
but might be worth user testing it. :)

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

14 Jul 2008 - 2:57pm
jabbett
2008

I believe there's more to password masking than protecting against an
onlooker. The HTML password field is handled uniquely by your
browser: after you submit the form, any return visits to the page
using the back button will clear out the password field. A regular
text field, however, will have its contents intact.

Since your users do not have e-mail accounts, I suspect they may be
using public (or at least shared) computers -- the potential for
stealing passwords is significantly higher in such an environment.
Unless you can be certain that they'll close their browsers completely
after registering, it'll be very risky to input passwords in a plain
text field.

On Mon, Jul 14, 2008 at 1:47 PM, Erin Yu <erin.yu at utoronto.ca> wrote:
> What do you think about putting a checkbox labeled "Show password"
> or "Unmask" right next to or below the password field, like so:
>
> Password: [____________]
> [ ] Show password
>
> when you check the Show password checkbox, it unmasks the password
> and shows what you typed in. Uncheck the box, the password is masked
> again. This might eliminate the need for the Confirm password field.
> Mac OS uses this approach in the system preferences, I believe.
>
> Another idea is to show the password as the user types it, and put a
> timer on it, so when they pause for, say 1 second, it then masks the
> password. I can see there could be some privacy concerns with this,
> but might be worth user testing it. :)
>
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the new ixda.org
> http://www.ixda.org/discuss?post=31190
>
>
> ________________________________________________________________
> 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
>

14 Jul 2008 - 4:11pm
Marty DeAngelo
2007

Erin Yu said:

>> "Another idea is to show the password as the user types it, and put a
timer on it, >> so when they pause for, say 1 second, it then masks the
password. I can see there >> could be some privacy concerns with this,
but might be worth user testing it. :)"

It's funny that you mention that - that's just what I got on the iPhone
today when I was downloading an application. The character I just typed
was visible until a) I typed the next character or b) 1 second or so
went by.

I see THAT interaction being more applicable to the iPhone or other
mobile devices where your keypad is directly correlated to your screen
(and there are frequent errors, such as I get with my clumsy fingers on
the iPhone). I don't know that it works as well with a desktop app
where you are using a keyboard and would be typing too fast to really
get that recognition unless the characters stayed up for a much longer
time.

-- Marty DeAngelo

14 Jul 2008 - 5:10pm
Carrie Garzich
2008

I'm intrigued by the idea of letting the user "turn off" password masking
with a radio button or a checkbox, but one concern -- is there a likelihood
that a lot of users will be tabbing through this form?

Unless your users are savvy enough to know to use the space bar
on checkboxes/radio buttons, those tabbing through the form would need to go
to mouse to turn off the masking, which may take them longer to do than it
would to just type the password again.

11 Jul 2008 - 1:59pm
Marielle Winarto
2008

> If this is a low security application, does it make sence
> to simply display the password when they create it?

Even for a low security application the password a user chooses can be
high security. Many people have only a small number of passwords,
which they re-use across applications. For such a user not hiding the
password means a serious security risk. I wouldn't be surprised if
people would react by choosing another password, different from their
usual and more difficult to remember (which would result in even more
helpdesk calls!).

Marielle

15 Jul 2008 - 8:52am
Steven Chalmers
2007

Password field: Momentary reveal.

The users are corporate users at call centers where they are not
allowed to be distracted by such things as e-mail and internet
access.

The application is being developed in Silverlight so we have a lot of
functionality flexibility. My development team and I have decided to
build a password field that reveals the character typed but only for
a moment. Once we get that working I want them to implement
functionality that allows the user to move the character cursor
across the letters to again reveal them momentarily. This allows the
user to review what they have typed in.

I believe this is advantageous over an extra UI control such as an
option button.

Steven

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

15 Jul 2008 - 11:39am
Sachin Ghodke
2008

There are two ways to look at this and before that i would like to say
that the confirm password is essential at the current stage that it
is. By this i mean it is important to verify user key strokes even if
means that most of the users do pay attention or are concentrating the
most while typing the password.

The two ways to look at this are:
(1) Keep the confirm password fields as they are for the reason i
mentioned above.
(2) Keep a single field but do not mystify the password by displaying
asterix in the field. If verification for password is needed then
simply display what is actually being typed rather than displaying
encrypted field entry. This way the user will know what is being
typed and can visually verify it if he/she has got it right. This
will safely eliminate the single password entry error issue. And we
really do not need to show encrypted field entry after all the
password need not be hidden from the person who is typing it.

Another way that i felt was quite innovative was the way i registered
on IxDA. I registered from my office. And when i wanted to access the
website again from home, this instance i was again asked to verify my
name and mail. My guess, is that this is being done by mapping either
the MAC id of your machine or your Machine IP address. If this is the
case then it provides sensitive information to third party. But since
we know that IxDA is a very serious community it is obvious that this
personal information will 'never' be misused. This is only if IxDA
has configured the "Sign In" process to the website.

Having said all this, my best bet would be #2 if you want to push
your idea across.

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

16 Jul 2008 - 10:06am
Jeremy White
2008

Interesting suggestions about the password reveal. I was thinking
along the same lines. Perhaps a "reveal" button that must be held
down and when released, the password is again asterisks.

Good luck! I'd be happy to know what your final product uses as some
of my clients seem very similar.

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

16 Jul 2008 - 11:13am
Steven Chalmers
2007

Jeremy, Yes, I was thinking of a "momentary" button too. It is a
nice design because it requires that the user conciously engages it.

I think the only negative is the addition of another UI control to
the form.

Steven

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

16 Jul 2008 - 12:23pm
Sachin Ghodke
2008

And then i was thinking about the #2 option i have mentioned above.
Thought why not keep only one field. Encrypt the password in the one
single password field. But... Display a talk balloon simultaneously
as the user types the password in for a brief moment so that he/she
will know if the password that is being typed is the correct one or
not.

Hope this aftersight helps.

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

Syndicate content Get the feed