W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2010

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

From: Dirk Pranke <dpranke@chromium.org>
Date: Tue, 4 May 2010 23:20:09 -0700
Message-ID: <h2j3726d1bf1005042320s814497fuf4e163c5624b6bb0@mail.gmail.com>
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
Received on Tuesday, 4 May 2010 23:20:09 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:23 UTC