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

For the sake of completion, I note I implicitly considered that 
type="password" carried some semantic meaning ("this field contains a 
password").
That is probably the case now in the sense that users do not expect to 
see such fields in other circumstances and browsers use that as well to 
propose to store passwords, but... I don't see any explicit and 
unambiguous semantic meaning in the definition of the "password" type:
  http://www.w3.org/TR/html4/interact/forms.html#input-control-types
... apart from "This control type is often used for sensitive input such 
as passwords". The definition is indeed much more focused on the visual 
aspect of the field.

I don't think that changes anything in the thrust of the discussion, but 
felt it needed to appear somewhere.

On the text itself, instead of mentioning "password manager" (which is 
indeed very arguable as a best practice), we could simply focus on the 
user input and mention examples or not. Something along the lines of:
  "Unless the user agent is known to facilitate the input of passwords 
(e.g. by having them appear in clear or by providing some kind of 
password management functionality) and depending on your security needs 
that we urge you to consider very carefully, do not use type="password" 
so that the user sees what he types".

That would have to go through the hands of an editor if we decide to go 
down that road. Anyway.

Francois.


Rotan Hanrahan wrote:
> Password saving features... seem initially useful, until the day you
> lose your mobile device and wish you hadn't effectively given the
> finder/thief the keys to your valuable property.
> 
> Yes, these features exist, and they are used, regardless of the
> security-weakening effect they have. For now, though, concentrating on
> the basic Web experience (without plug-ins or fancy custom features) the
> issue is not whether the browser can offer assistance in weakening an
> application's security, but whether the access procedure is appropriate
> and usable by the mobile user. In this regard, the text you are
> proposing is much along the lines of what I was earlier suggesting, and
> I would support it.
> 
> ---Rotan
> 
> -----Original Message-----
> From: Francois Daoust [mailto:fd@w3.org] 
> Sent: 04 February 2009 13:24
> To: Rotan Hanrahan
> Cc: public-bpwg@w3.org
> Subject: Re: [ACTION-908] good practice for login forms
> 
> I don't doubt this is useful for past and current browsers, and that the
> 
> situation won't change for some time.
> 
> However, I find it reasonable to believe that future browsers will 
> provide password-saving features similar to what exists on most if not 
> all desktop browsers. That's already the case with Opera Mobile 9.5 [1],
> 
> there is a plug-in for Windows Mobile Internet Explorer [2], Mozilla 
> Fennec will have one according to specs [3]...
> 
> I haven't taken a close look, but I suppose browsers rely on 
> type="password" to detect login forms and propose to save passwords. If 
> we start to recommend not to use type="password", then I have the 
> feeling that, while addressing an important problem today, we're also 
> going to create a future one.
> 
> That being said, MWABP comes with "If" so we could perhaps find a 
> wording such as:
> "If you know the user agent does not have a password manager,
>   if you know password typing will be difficult on the user's device,
>   and depending on your security needs that we urge you to consider very
> 
> carefully,
>    do not use type="password" so that the user sees what he types"
> 
> ... which we could complete with:
>   "If you do that, consider adding a link to a type="password" version 
> of the login page"
> 
> Francois.
> 
> [1] http://www.opera.com/press/releases/2008/02/05/
> [2] http://pieff.desofto.com/
> [3] http://www.mozilla.org/projects/fennec/1.0a1/releasenotes/
> 
> 
> Rotan Hanrahan wrote:
>> 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 16:04:28 UTC