[ACTION-908] good practice for login forms

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

Received on Tuesday, 3 February 2009 20:17:09 UTC