[whatwg] RFC: <input type="username">

[Schalk Neethling]

I personally like the idea of having a type of username for an input field, makes sense based on the use case.

Kind Regards,
Schalk Neethling

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Dirk Pranke
Sent: Wednesday, May 05, 2010 8:20 AM
To: Boris Zbarsky
Cc: whatwg at lists.whatwg.org
Subject: Re: [whatwg] RFC: <input type="username">

On Tue, May 4, 2010 at 8:21 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 5/4/10 10:56 PM, Dirk Pranke wrote:
>>
>> What I would like to offer is a way to control some amount of the 
>> sign-in/sign-out experience while improving the security, by at least 
>> giving an in-page way to trigger sign-in / sign-out (the actual 
>> mechanism of collecting the credentials and performing the sign-in 
>> would be done by the browser without page intervention, where 
>> possible, for security reasons).
>
> So this would be something pages opt into?
>

Yes. I also imagine people submitting user scripts that could rewrite existing login forms into forms using the new tags.

> If not, how would the following sign-in workflows (taken from two 
> banking sites I've dealt with recently) work:
>
> Workflow 1:
>
> 1)  Site prompts user for only a username.
> 2)  After user enters a username, site responds with a "Hello,
>    __firstname__" (with either the first name corresponding to the
>    username filled in or a random one generated if there's no such
>    account) and two security questions.
> 3)  After the user correctly answers the two security questions, he is
>    presented with a previously-agreed-on image and phrase (to convince
>    the user that the bank is in fact the bank) and 9 clickable buttons
>    numbered 0-9.
> 4a) If the user has a mouse, the user clicks the buttons in the right
>    order to enter their PIN (I believe a 7-digit or more number).
>    Else go to 4b.
> 4b) If the user cannot use the mouse for some reason, the user can
>    follow a link which associates each of the 10 buttons with one
>    of a randomly chosen (each time you hit this screen, as far as
>    I can see) set of 10 letters.  The user can then type the
>    letters that correspond to the desired numbers.
>
> Workflow 2:
>
> 1)  Site prompts user for only a username.
> 2)  After user enters a username, site responds with a page that has a
>    password field and a bunch of buttons in the general shape of a
>    qwerty keyboard.
> 3)  The user enters a password in the password field.
> 4)  The user also enters a different password (the site enforces
>    that they're different during account setup) by clicking the
>    correct buttons on the "virtual keyboard".
>
> Various other banking sites I've dealt with have the 
> "previously-agree-on image and phrase" thing going on, but these two 
> are the ones that are creative with password input.  In particular, 
> the goal seems to be to defeat keyloggers by making replay of logged 
> keystrokes be insufficient to log into the site.

There is no question that people have dreamt up a large variety of mechanisms for logging into web sites. It would be difficult to support all of them out of the box, and certainly we would need to eventually extend the specs that Mozilla has defined to talk about how to support two-factor auth and other schemes like the ones you describe, if we can't figure out how to move them to more secure mechanisms. In particular, allowing a safe login from a compromised machine is, to say the least, somewhat challenging :(

Both the Mozilla Account Manager and the scheme I'm talking about -- which again, builds on top of the account manager -- at least have the advantages that (a) they take the actual typing in of the password out of page and (b) they make the job of password managers far more reliable. Those alone should deliver enough benefit to make these ideas interesting, in my opinion.

-- Dirk