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

 > However, I find it reasonable to believe that future browsers
 > will provide.....
  ^^^^


Still stuck with the famous "forward-looking best practices"....

Luca




Francois Daoust wrote:
>
> 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 13:59:26 UTC