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

A conclusion to that thread, but not a decision.

"Use another browser" is not exactly a friendly way to propose solving
the problem for a typical mobile Web user. The only two viable options,
I think, are to:
- Don't use type="password"
- Give the user the option of an alternative page where type="password"
is not used.

The first would be OK for me, but perhaps other users might complain
that in their particular circumstance there is a security risk.

The latter would involve another round-trip for people who want a
clear-text version of the login page.

Of course, you could default to the clear-text version, and use a link
to get to an optional type="password" version of the login page, if it
was agreed that the best practice was to use clear-text by default.

Back in 2006 I didn't have much of a personal opinion on the matter, as
most of the sites I visited did not require login. That has changed in
the intervening period, and now I have experience with using mobile
login and find the asterisks to be the most frustrating part of the
experience, so much so that I'm inclined now to wait until I get to a
desktop where I can successfully enter the passwords. It's so bad to
have a barrier to mobile Web use as the first page you encounter :(

---Rotan.

-----Original Message-----
From: Francois Daoust [mailto:fd@w3.org] 
Sent: 04 February 2009 11:08
To: Rotan Hanrahan
Cc: Adam Connors; casays@yahoo.com; public-bpwg@w3.org
Subject: Re: [ACTION-908] good practice for login forms

This does look like a best practice that could have fit in the Mobile 
Web Best Practices document at first, so I thought it would probably 
have been discussed in the past.

It was! Back in 2006, on the member list (the WG was not operating in 
public at that time):
  http://lists.w3.org/Archives/Member/member-bpwg/2006Nov/0149.html

I wasn't there. The conclusion was, it seems, that the trade-off should 
be left to the browser implementation. If you don't use type="password" 
then the user has no way to "hide" the password. On the other hand, if 
you do use type="password" then a user could choose, in theory, a 
browser that proposes to display password inputs.

Some old BPWG beast would probably know more about that.

Francois.


Rotan Hanrahan wrote:
>>  * 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. 
> 
>  
> 
> There are limits to how far you can go. One Web doesn't have to mean 
> "desktop, only smaller". Sensitivity to the context of delivery should

> also be encouraged, and given that BP says to make use of device 
> characteristics, I think such sensitivity is being encouraged. A
mobile 
> device has the characteristic of being easier to obscure from 
> over-the-shoulder spies, and many also have the characteristic of
having 
> a constrained keyboard that makes entering convoluted passwords very 
> awkward. Adapting to these particular contextual factors makes sense. 
> Expecting that recommendations for mobile and desktop must be exactly 
> the same is contrary to the idea of contextual sensitivity. There
needs 
> to be some balance here.
> 
>  
> 
>>  * 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.
> 
>  
> 
> Partly true, but the legacy devices are not going to fade away pretty 
> quickly. Many service providers will (sadly) only focus on the latest 
> fancy devices to hit the market. It would be extremely unfair to 
> disenfranchise so many "legacy" users just because some new (and 
> probably expensive) device feature has hit the market.
> 
>  
> 
>>  * 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.
> 
>  
> 
> Experience shows that many users find the period of visibility of the 
> last character is often insufficient. The last character can disappear

> before the user can shift focus from the tiny keyboard to the tiny 
> screen. It's a shame that the browsers don't come equipped with a
"show 
> me" button that would temporarily display the entire password field,
as 
> then the issue would not be so bad. Given that there are so many
devices 
> already out there that present difficulty for users inputting
passwords, 
> I think the suggestion of using a clear text field makes sense. You 
> could be flexible and give the user the option of seeing the password,

> and/or you could adapt to those devices that have restricted
keyboards, 
> short visibility periods and so on. Of course, that would require
having 
> plenty of knowledge about such device characteristics, which is not 
> generally available.
> 
>  
> 
> Speaking personally, I would prefer the clear text option because I am
a 
> clumsy mobile keyboard user, and make mistakes often.
> 
>  
> 
> ---Rotan
> 
>  
> 
>  
> 
>  
> 
>  
> 
> *From:* public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org]

> *On Behalf Of *Adam Connors
> *Sent:* 04 February 2009 09:19
> *To:* casays@yahoo.com
> *Cc:* public-bpwg@w3.org
> *Subject:* 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 
> <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 11:25:15 UTC