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

 > Thoughts ?

yes. BPWG is still being the victim of one-web. Open your minds to the 
concept that mobile devices are different from desktop web browsers and 
plain simple logic will do the rest.

Luca

Adam Connors wrote:
> 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 
> <mailto: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
>
>
>
>
>
>

Received on Wednesday, 4 February 2009 09:38:04 UTC