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

Please bear in mind voice input/output users. These may be blind or 
partially-sighted users of screen readers or simply people using 
voice-enabled phones. Password fields are read out "asterisk, asterisk, 
asterisk" to avoid broadcasting the password to everyone within earshot. 
Normal fields are read out letter by letter.

These users have the option of connecting headphones first (like they 
can at some bank teller machines), but that hardly seem a reasonable 
tradeoff.

On the other hand, displaying the text on screen could help people with 
limited dexterity or cognitive limitations, especially the elderly 
users. But it does seem unreasonable to force it people.

I think that this is something that should be a browser option (at least 
one screen reader allows users to hear the password if they wish to even 
when it is a password field) not forced on people by page designers.

best regards,

Alan


-- 
Alan Chuter
Departamento de Usabilidad y Accesibilidad
Consultor
Technosite - Grupo Fundosa
Fundación ONCE
Tfno.: 91 121 03 30
Fax: 91 375 70 51
achuter@technosite.es
http://www.technosite.es

Eduardo Casais escribió:
> 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 Wednesday, 4 February 2009 17:16:36 UTC