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

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.

I agree.


> 
> 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 ?

I'd say this type of automation should stay in the hands of the browser. 
Same as the "Remember this password for future uses" feature in most 
desktop browsers. Even if that doesn't work for the time being on mobile 
devices, it sounds a bit clumsy to recommend implementing this feature 
at the cookie level.

I understand it is being done in practice, just wonder whether that can 
be a "best" practice.

Francois.


> 
> 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 10:01:35 UTC