RE: [ACTION-908] good practice for login forms

> * We have a BP on "One Web" which encourages the use of the same
account / personalization between desktop and mobile web applications
--> it would be strange then to have different recommendations for
mobile passwords as opposed to desktop passwords. 

 

There are limits to how far you can go. One Web doesn't have to mean
"desktop, only smaller". Sensitivity to the context of delivery should
also be encouraged, and given that BP says to make use of device
characteristics, I think such sensitivity is being encouraged. A mobile
device has the characteristic of being easier to obscure from
over-the-shoulder spies, and many also have the characteristic of having
a constrained keyboard that makes entering convoluted passwords very
awkward. Adapting to these particular contextual factors makes sense.
Expecting that recommendations for mobile and desktop must be exactly
the same is contrary to the idea of contextual sensitivity. There needs
to be some balance here.

 

> * Virtual keyboards are getting more popular and so even on mid-range
devices can we not expect the input limitations of numeric keypads to
fade away pretty quickly.

 

Partly true, but the legacy devices are not going to fade away pretty
quickly. Many service providers will (sadly) only focus on the latest
fancy devices to hit the market. It would be extremely unfair to
disenfranchise so many "legacy" users just because some new (and
probably expensive) device feature has hit the market.

 

> * The type="password" tag on most devices these days hides all except
for the last character entered in order to help mobile entry -- so the
"don't hide" advice is outdated I think.

 

Experience shows that many users find the period of visibility of the
last character is often insufficient. The last character can disappear
before the user can shift focus from the tiny keyboard to the tiny
screen. It's a shame that the browsers don't come equipped with a "show
me" button that would temporarily display the entire password field, as
then the issue would not be so bad. Given that there are so many devices
already out there that present difficulty for users inputting passwords,
I think the suggestion of using a clear text field makes sense. You
could be flexible and give the user the option of seeing the password,
and/or you could adapt to those devices that have restricted keyboards,
short visibility periods and so on. Of course, that would require having
plenty of knowledge about such device characteristics, which is not
generally available.

 

Speaking personally, I would prefer the clear text option because I am a
clumsy mobile keyboard user, and make mistakes often.

 

---Rotan

 

 

 

 

From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] On
Behalf Of Adam Connors
Sent: 04 February 2009 09:19
To: casays@yahoo.com
Cc: public-bpwg@w3.org
Subject: Re: [ACTION-908] good practice for login forms

 

Thanks Eduardo! That's incredibly useful and thorough input.

 

I have to say that I'm not in favour of having a BP to this effect in
MWABP though. My reasoning goes as follows:

 

* We have a BP on "One Web" which encourages the use of the same account
/ personalization between desktop and mobile web applications --> it
would be strange then to have different recommendations for mobile
passwords as opposed to desktop passwords. 

 

* Virtual keyboards are getting more popular and so even on mid-range
devices can we not expect the input limitations of numeric keypads to
fade away pretty quickly.

 

* The type="password" tag on most devices these days hides all except
for the last character entered in order to help mobile entry -- so the
"don't hide" advice is outdated I think.

 

Perhaps the take-away from this then is that we should have a BP along
these lines:

 

3.1.2 Enable Automatic Sign-in Between Invocations

 

Due to the difficulties of entering sign-in information on a mobile
phone it's particularly important to enable automatic sign-in. This can
be done by storing a Hashed user identity token in a cookie. Don't store
unhashed user password information in cookies though as it's insecure.

 

(With some word-smithing, of course).

 

Thoughts ?

 

Adam. 

On Tue, Feb 3, 2009 at 8:16 PM, Eduardo Casais <casays@yahoo.com> wrote:


The action is stated as "Note specific mobile good practice for login
forms
regarding use of numerics and mixed case and so on".


1.      GOOD PRACTICES.

Mobile applications strive to fulfil two requirements:

- minimize input keystrokes;
- minimize possibilities for mistaken input.

>From these principles, the following good practices have been derived
regarding
password input in forms:

a) Do not mix alphabetic symbols and numbers, nor upper- and lowercase.
b) Use numeric pin-codes rather than passwords.
c) Do not mask input that is being entered by the end user.

These practices obviously go counter to password guidelines in the
desktop Web,
where mixing all sorts of alphanumeric symbols, both upper and
lowercase, is
recommended.


2.      TECHNICAL IMPLEMENTATION.

Technically, these practices are implemented via specific attributes in
the
input tag in markup, and in rejecting input fields of type password in
favour
of normal text fields.

In XHTML mobile profile (format="NNNN" indicates a 4-numbers field):
<input type="text" name="pin" value="" style="-wap-input-format:NNNN" />

In i-mode HTML (istyle="4" indicates a numeric field):
<input type="password" name="pin" maxlength="4" size="4" istyle="4">

In WML (format="NNNN5N" indicates a numeric field with 4 to 9 symbols):
<input type="text" name="pincode" value="" format="NNNN5N"
emptyok="false"/>


3.      REFERENCES.

The following extracts are from several documents that deal explicitly
with
password input in mobile applications, and dating from 2001 to 2008.

Addressed good practices (a, b, c) are indicated for each reference.

------------

(c)

Luca Passani: Global Authoring Practices for the Mobile Web v.1.0.4,
2008-11.


Manage User Input (use input masks/minimize clicks)

[NO_PASSWORD_MASK] Do not mask user input when entering a password.

Rationale: Entering data and text is a very time consuming and
error-prone
task for users of mobile devices. Everything possible should be done to
minimize the amount of clicks required to users.

[...] Reading what is on the screen of a mobile device is often hard
enough
for the user of the device. Peeking over the shoulder of the user is
less
likely to disclose a password than observing the user's keypress
sequence.
For this reason, hiding user input to users themselves by replacing each
character with a '*' (star) symbol (or similar) will do very little to
protect
privacy, while making it generally harder to use the service. For this
reason,
users should be made enter passwords in clear text.

------------

(a) (c)

Nokia: Guidelines For Creating Web Content For Mobile And PC Browsing,
v.1.0,
2004-09-27.


2.12.1 Input fields

[...] Avoid requiring letters and numbers in the same input field
(especially
in a password field). When the password contains both numbers and
letters,
users in tests have entered the wrong password without noticing it.

Avoid requiring case sensitivity (especially in password fields). In
password
fields, when input characters turn to asterisks, novice users may have
difficulties remembering what they have input.

------------

(a) (c)

Sprint: Usability Requirements for XHTML Basic Applications, 2003-01.


4 PASSWORD ENTRY: A SPECIAL WARNING

The following recommendations are not requirements because we cannot
judge the
security needs of your application. We set this recommendation aside to
stress
its importance to usability. We urge you to consider it carefully.

! Do not mask out text input with "password" formatting. The usability
problems
associated with triple-tapping masked passwords outweigh the costs of
hiding
those passwords. Here's why...

On the surface, password format appears usable because the user can see
each
character as it is entered. Actually, while typing letters, users look
at the
keypad - not the display - as they determine the triple-tap sequence for
each
character. Once they look up at the display, the cursor will have
advanced,
obscuring the just-entered character with an asterisk or similar
character.
Even the most experienced users will have occasional trouble with
password
format. We do. Consider that each mobile device is a personal device,
and its
user has considerable control over it. Unlike kiosk or fixed computer
situations, where somebody could look over a user's shoulder, in mobile
situations the user can move the screen and keypad wherever desired.
When
combined with the difficulty in text entry on most devices and the
likelihood
of user distraction partway through text input, masking user input has
an
unacceptably high user cost for very low user or security benefit.

As a developer, do not be swayed by your personal ability to flawlessly
triple-tap a 14-character, mixed-case, alphanumeric password. You are
more
capable than your users! Most of them will fail at this task and not
return
to your application unless they must.

In summary: masking passwords (during input) will reduce the amount of
password theft primarily because there will be fewer passwords to steal,
because there will be fewer users.

! Avoid unnecessarily complex password formats. The format of your
password has
a strong and direct effect on the difficulty of entry. In general, the
difficulty of entering a masked string increases with the complexity of
the
string. As a rule:
-- Alphanumeric strings are more difficult to enter than alphabetic,
-- Alphabetic strings are more difficult to enter than numeric,
-- Case-sensitive strings are more difficult to enter than
case-insensitive,
-- Strings with symbols are more difficult to enter than strings without
symbols, etc.

Because complex passwords are more secure passwords, you must find the
appropriate balance for your particular application. All-numeric strings
are the easiest to enter, but because it is not possible to force
numeric
format with some PCS Vision phones, we recommend that you not mask out
numeric
passwords.

! If you do not mask text input with "password" formatting, assign the
password
input field to its own page. A password alone is useless. A password
combined
with a user ID or other credentials is a different matter. If you choose
to
increase the usability of your application by not masking passwords, you
can
avoid any additional risks by not displaying a user's full set of
credentials
on one page.

------------

(b)

How to create an i-mode site, 2002-11-18.


INPUT Tag

[...] Text input fields can have an istyle attribute that indicates the
input
mode for the field.
[...] For password fields:
<input type="password" name="name" accesskey="accesskey"
maxlength="maxlength"
size="size" value="value">
The default istyle attribute value for password inputs is numeric (4)
and
cannot be changed, except for the NEC N21i and TS21i. For these handsets
you should force the style to numeric.
[...] Tip: Limit password inputs to numeric only and indicate that a PIN
code
is required, rather than a password.

------------

(b)

ATT: Guide to mMode-Compliant HTML Coding, v.1.0, 2002-05-14.


2.2.2.6. Forms (User Entry)
2.2.2.6.1. Text Entry

[...] Note: istyle is not supported for input element with type equal to
password, which is always set to numeric input.

------------

(b) (c)

Openwave: GSM Application Style Guide, 2001-02.


Section 9: Data Entry Queries

[...] Make password fields numeric only, when possible.
It is easier to enter numbers than letters or symbols.

Do not mask alphanumeric passwords.
Do not mask the entry. It is easier for the user to hide the display
from others than to type with masked characters.

------------


E.Casais