W3C home > Mailing lists > Public > public-bpwg@w3.org > February 2009

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

From: Manrique Lopez <manrique.lopez@fundacionctic.org>
Date: Wed, 04 Feb 2009 10:06:57 +0100
To: casays@yahoo.com
Cc: public-bpwg@w3.org
Message-Id: <1233738417.7866.3.camel@bespin>

Hello,

For technical implementations, what about "inputmode" attribute for
XHTML Basic 1.1? Isn't it the same for XHTML MP 1.2?
<input type="text" name="pin" value="" inputmode="latin digits" />

References:
http://www.w3.org/TR/xhtml-basic/#s_inputmode
http://www.w3.org/TR/xhtml-basic/#s_mode-values

Thanks and best regards,

El mar, 03-02-2009 a las 12:16 -0800, 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
> 
> 
>       
> 
> 
-- 
José Manrique López de la Fuente <manrique.lopez@fundacionctic.org>
Área de Tecnología Fundación CTIC
Web: http://www.fundacionctic.org
Tel: (+34) 984 29 12 12
Parque Científico Tecnológico de Gijón
Edificio Centros Tecnológicos
Cabueñes s/n
33203 GIJÓN - ASTURIAS - ESPAÑA
#Antes de imprimir este e-mail piense bien si es necesario hacerlo: El
medioambiente es cosa de todos.
Received on Wednesday, 4 February 2009 09:07:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:43:00 UTC