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

I was part of BPWG at the time (working for Openwave) and I was arguing 
strongly to have this practice included.

Because of the ideological approach to the problem by BPWG , my 
recommendation was turned down (one of the reasons why I decided that BP 
was no good for developers and I decided to go for GAP instead. Of 
course, the main reason of disagreement remains that ill-conceived 
one-web, which still keep mudding the waters)

Luca

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