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

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