[whatwg] Solving the login/logout problem in HTML

[Ian Hickson]

As can be seen in the feedback below, there is interest in improving the 
experience with logging in and out of Web sites.

Currently there are two main mechanisms: HTTP authentication, and 
cookie-based authentication with a form login.

Benefits of form authentication over HTTP authentication:
 - supports creating an account
 - supports recovering a lost password
 - supports showing the login form inline with other content
 - supports styling the login form
 - supports an obvious way of logging out from within the page

Limitations of form authentication:
 - no way to indicate that access is being denied because the credentials 
   passed were wrong or because there were no credentials passed
 - insecure when unencrypted

It seems to me that the first limitation of form authentication could be 
removed by inventing a new WWW-Authenticate challenge that means "reply to 
the form in the page". I have now specified such a value in HTML5 (since 
it is specific to entity bodies that contain HTML forms):

   challenge = "HTML" [ form ]
   form      = "form" "=" form-name
   form-name = quoted-string

(There's no "credentials" value for this scheme, since the login is done 
as a POST to a login script and then the server sets proprietary login 
information, like a cookie using Set-Cookie.)

So when you get to a page that expects you to be logged in, it return a 
401 with:

   WWW-Authenticate: HTML form="login"

...and there must be a <form> element with name="login", which represents 
the form that must be submitted to log in.

We could also make HTTP login work better, but frankly I'm not convinced 
there's much point. The form login cowpath is so commonly frequented that 
not only has someone already gone and paved it but it has also been 
tree-lined, has garbage collection scheduled for Tuesdays and Thursdays, 
and will be electing a representative at the next general election.

With all this in mind:

On Fri, 17 Dec 2004, Matthew Thomas wrote:
> On 17 Dec, 2004, at 6:08 PM, Ian Hickson wrote:
> > On Fri, 17 Dec 2004, Matthew Thomas wrote:
> > > 
> > > Future browsers could, instead of displaying an alert for HTTP 
> > > authentication, provide the authentication UI in a panel at the top 
> > > of the non-authenticated page (fixing annoying modality issues in 
> > > the process). That wouldn't require any change to HTTP 
> > > authentication either.
> > 
> > A very interesting idea. The problem with that is that if you show the 
> > 401 page at the moment, you'll get something like:
> > 
> >     401 UNAUTHORIZED
> > 
> >     YOU DO NOT HAVE THE PROPER PERMISSIONS
> > 
> > 
> > 
> >    ___________________________________________________________
> >     Username: [_____]  Password: [_______]   (Login)      [X]
> 
> Well since I said "at the top of the non-authenticated page", and since ~70
> percent of sites use Apache, most of the time it would look more like this ...
>  ____________________________________________________________
> | Committee Members Area         ID: [          ]            |
> | foo.example.org          Password: [          ] ( Log In ) |
> |""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""|
> |                                                            |
> | AUTHENTICATION REQUIRED                                    |
> :                                                            :
> 
> .... which would be quite okay, since "authentication required" isn't 
> contradicting anything. (Further, a really earnest browser might delay 
> rendering of any unauthorized page to prevent FOUC, and then display the 
> unauthenticated page only if it didn't contain the case-insensitive 
> regexp "401*.unauthorized". That would be weird, but hardly weirder than 
> Internet Explorer's current length-based overriding of server error 
> messages.)

I think this is still a good idea, but requires nothing of HTML5.


> > We could get around that by saying that you can include 
> > WWW-Authenticate headers with 200 OK responses as well (nothing in 
> > HTTP seems to say you can't), and that if you do, then the bar is 
> > shown as above ("interactive user agents should provide a non-modal 
> > authentication interface"). Then, if you've already sent your 
> > credentials and you get a 401, then you get the 401 page and the bar, 
> > instead of the modal dialog. ...
> 
> Yes, that's a simpler option. :-) (Provided that current browsers still 
> ask for authentication even when given a 200 OK.)

I don't think they do now, but it's something we can move towards.

I think the above idea (of using WWW-Authenticate with 200 OK) is a good 
one, but is something we should let the HTTPWG worry about.


On Fri, 17 Dec 2004, Greg Kilwein wrote:
>
> Related to this, it would be nice to have a standard, simple way for a 
> browser session to "log out" of its HTTP authentication.  Currently with 
> some UAs, a user must to close all of his or her browser windows and/or 
> tabs in order to be able to log in as someone else.  Granted, there are 
> ways to trick the browser into popping up the authentication box, but it 
> would be nice to have a standard "log out" feature.
> 
> The way HTTP authentication is implemented now assumes that the user 
> will never want to change usernames.  This is simply not true in every 
> case, even if it is for the majority of cases.
> 
> I'm not sure of the best way to accomplish this log out functionality 
> (headers? HTML tags?) but this certainly would be a helpful feature in 
> the web application that I develop.  Has anyone else experienced a 
> situation in which this feature would be useful, or have any ideas about 
> how it could be accomplished that would be within the scope of this 
> group?

On Sat, 18 Dec 2004, Matthew Thomas wrote:
>
> That's entirely the fault of the browser vendors; they haven't bothered to
> implement it in a convenient way. (See for example
> <https://bugzilla.mozilla.org/show_bug.cgi?id=260839>.)
> 
> There's no need for authors to do anything extra; browsers just need to 
> do a full implementation of HTTP authentication (i.e. one that includes 
> the ability to log out). A browser using my design for logging in, for 
> example, could change the panel for logging in to one for logging out:
> 
>  ____________________________________________________________
> | Committee Members Area             ID: [        ]          |
> | foo.example.org              Password: [        ] (Log In )|
> |""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""|
> :                                                            :
>                               |
>                               V
>  ____________________________________________________________
> | Committee Members Area   Logged in as: gregk               |
> | foo.example.org        Stay logged in: [1 week:^] (Log Out)|
> |""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""|
> :                                                            :

On Mon, 13 Jun 2005, Charles Iliya Krempeaux wrote:
> 
> Having a way to "logout" the user from an HTTP authentication session is 
> very desirable.
> 
> The only reason I use "cookie" based authentication is because there is 
> no way (that I know of) to log the user out of an "HTTP authentication 
> session".  (Once they are logged in, they are always logged in.)  
> (Although, really, there are some "hacks".  But those hacks have 
> usability issues.)

On Mon, 13 Jun 2005, Charles Iliya Krempeaux wrote:
> 
> I agree with you in that this is (partially) a problem with the browser.  
> But what if the browsers had a feature where the user could "logout" of 
> a website (using HTTP authentication).  (In other words, what if the 
> browser had a button or something that would "clear out" the "username" 
> and "password" it is sending for a web site.)  Would that be enough?
> 
> I don't think it would be enough.  The reasons are....  #1: Web 
> developers will want to integrate the logout button into their "web 
> pages" or "web applications".  #2: Web developers will want to be able 
> to "logout" via JavaScript.  #3: Web developers will probably want to be 
> able to control if the "authentication pop-up" (the pop-up window you 
> type your username and password into) comes up or not.
> 
> At the very least there should be a JavaScript API that can let you 
> "logout".  (And be able to detect if you are "logged in" or not.)

We could introduce a <bb type="logout"> option, but frankly what's the 
point. Logout already works for regular form-style login, and as mpt notes 
above, UAs could implement HTTP auth better already.


On Fri, 17 Dec 2004, Greg Kilwein wrote:
>
> One such solution for the authentication issue is at the following 
> location:
> 
> http://www.w3.org/TR/1999/NOTE-authentform-19990203
> 
> Perhaps this could be used in full or at least as a basis for a method 
> to provide a "log out" feature.

This is an interesting proposal, but as noted above, I'm not sure there's 
much point trying to save HTTP auth at this point. People wanting security 
should use SSL, IMHO. Digest isn't really that secure, and Basic is worse 
than session cookies.


On Mon, 13 Jun 2005, Charles Iliya Krempeaux wrote:
> 
> So you want some standard "hand shake" for logging off.  I.e.,
> 
>     #1: The client sends a "log me out" message to the server.
>     #2: The server receives the "log me out" message and "cleans up".
>     #3: The server sends a "you are logged out" message to the client.
>     #4: The client clears the "HTTP Authenication" data.

On Mon, 13 Jun 2005, S. Mike Dierken wrote:
>
> Actually, I don't want #1 or #2 to be standard (the existing POST method 
> would work), I would like #3/#4 to be provided by the protocol. As you 
> mentioned earlier, the client could provide a 'clear authentication' 
> button or an extension to HTML forms, and although that would work, it 
> doesn't give quite the kind of control web page developers would want 
> (where to redirect the user, what the result page looks like, a chance 
> to notify the server, etc). I like the ability for the server to 
> participate in login/logout activity.

This is already possible with forms authentication, so I don't see much 
point adding stuff to HTML to make it possible with HTTP auth too.


On Thu, 7 Sep 2006, Anders Rundgren wrote:
>
> As you probably have noticed, practically every site offers a login.for 
> their members, customers, citizens etc. etc.
> 
> 1.  User-id/password management has become a real nuisance. Once this 
> was an issue for computer professionals only, now it affects everyone 
> from children to grandma.
> 
> 2. There are other and better authentication methods available that 
> become hard to migrate to without making life hard for end-users by 
> asking them to use another login method.  The site has no way of 
> detecting the user's options.
> 
> It appears, that it may be possible to add some kind of negotiation/ 
> option elements at the HTML level, that if supported by the underlying 
> system could offer a standardized and potentially more powerful version 
> of the password caches or external login form "hijacker software" that 
> we currently use. Tentative functionality for the AHE (Authentication 
> Helper Extension):
> 
> - Find out if the AHE is installed/available
> 
> - If the AHE is available, find out if the site in question is in the 
> list
> 
> - If in the list, put out a dialog box giving the user an option to 
> login, decline or manually enter login information.
> 
> - If the site so requests, the user's authentication options (in case 
> form based authentication was used) can be transferred during login, 
> giving the site an option to ask/require the user to upgrade their 
> authentication.  This could involve anything from digest-authentication 
> to certificates.  The latter current lacks a decent provision method but 
> there is some work going on in this area as well.  MS CardSpaces is also 
> an option.
> 
> - The authentication stuff would be possible to store in an USB token or 
> even better in a mobile phone.  This is of course outside of HTML5 but 
> will be natural to support within 3-5 years from now.
> 
> - The scheme would (if properly implemented) be able to thwart phishing 
> since a user-id/password (or other auth solution) could be tied to a SSL 
> root + host name (or even better host domain).
> 
> In essence the desired result is a portable (mobile) multi-site 
> authentication support mechanism that should not only make the web 
> easier, but also long-term considerably more secure.
> 
> Other Options?
>
> The other option is addressing this problem at the transport level but I 
> think form-based authentication is a better entrance point since it is 
> already in place. There is no problem [at all] of having a mechanism [in 
> the proposed scheme] that switches from form-based authentication to 
> transport-level authentication like using TLS-client-certificates, while 
> the opposite is impossible.

On Thu, 7 Sep 2006, Dave Bacher wrote:
>
> Why not just issue a TLS 1 certificate?
> 
> Internet Explorer 2 and later support it.  Netscape Navigator 2 and 
> later support it.  All versions of Opera support it.  All versions of 
> FireFox support it.  All versions of Safari support it.  In fact, the 
> vast majority of libraries and user agents that support TLS or even SSL 
> websites also support TLS 1 client certificates.
> 
> When you issue the certificate, most browsers offer a convenient way to 
> send it to the client.  It is installed into the local certificate 
> store, or potentially a hardware device such as a smart card.  Later, 
> the user authenticates to the user agent, and then is given the option 
> of providing the certificate to a site that asks for it.  You can either 
> issue a certificate specifically for your site, or you can have them go 
> get a (freely available, in at least some cases) client certificate from 
> a vendor like VeriSign.  These are typically called "e-mail signing 
> certificates" or "digital ID's" by the companies that sell them.
> 
> There are a couple big benefits here.  First, you are using an existing 
> user agent feature, that every user agent is likely to support.  So you 
> just have to talk the user through installing the certificate into IE.
> 
> Secondly, web server side, it is a radio button in IIS 4 or later (not 
> sure about earlier versions), or a single line in Apache to enable the 
> feature.
> 
> Thirdly, if the ID becomes compromised, you can issue a revoke request, 
> and issue a new ID.  This means the certificate that you issued before 
> immediately becomes invalid, and so if the user loses the certificate or 
> has it stollen, it takes no effort.
> 
> Fourthly, if the computer has a smart card reader (about USD $20) and a 
> smart card, the certificate can be installed onto the smart card.  If 
> this is done, then the user must provide a valid PIN in conjunction with 
> the physical card in order to send data using the identities installed 
> onto the card.  This adds a physical layer of security that is not 
> possible with a name/password system.
> 
> And the worse problem than the number of systems using user id/password 
> on a form to authenticate (and not at least using digest) is that many 
> of these don't use TLS, and so the password is sent plain text or plain 
> text equivalent across the network.  Additionally, many of these systems 
> send the username and password pair by e-mail, which means not only is 
> the user name and password sent across the internet, but also that it is 
> stored in one or more well known locations on the user's computer for at 
> least some period of time.  Since most operating systems don't provide 
> any mechanism to lock down a directory so that only one module or 
> application can access it, and since the most protection most user 
> agents offer to e-mail files is the non-protection of a randomly 
> generated file name, this is actually the worst part of the security 
> risk.
> 
> Failing TLS, most servers (including IIS and Apache) and user agents 
> support Kerberos, NTLM and a host of other options, and there are 
> several publicly available specifications for what is called "Federated 
> Identity."  The problem with all of these is that various parties have 
> interests in pushing their own view of how a federated identity should 
> work, usually to further their own goals.
> 
> Also, keep in mind that a federated identity system also poses privacy 
> risks for the user.  When the user connects to your site, you must 
> contact the federation and ask if they are who they say that they are.  
> This means the federation knows both who you are, and what site you are 
> trying to access. This is why they aren't popular.
> 
> TLS doesn't have that problem, because you retrieve a certificate 
> revocation list versus asking if a specific certificate is valid.  All 
> that verisign (as an example) knows is that a TLS website asked for a 
> revocation list, they don't ever know what user it was who was trying to 
> access the site.
> 
> The issue with a federated log on is you must log on and log off from 
> the federation site.  Sites have to check with that site to see if your 
> token is valid or not, so any token based authentication inherently 
> compromises your privacy (at least potentially).

On Fri, 8 Sep 2006, George Staikos wrote:
> 
> I would like to add a few more points here.
> 
> 1) The hardware is very cumbersome.  It's not pervasive, it requires 
> carrying cards and tokens, and limits mobility.
> 
> 2) Certificates are more easily stolen than passwords unless the 
> certificates have passwords on them.  Then, well, we are using passwords 
> again.  Certificates have lost most of their value by this point I 
> think.
> 
> 3) Users just don't understand this stuff yet.  In the case of a system 
> failure most users will be completely lost with how to recover.
> 
> 4) People are aware of the vulnerabilities of passwords and take at 
> least some reasonable precautions with them.  Certificates are not 
> infallible and people are not aware of how to properly protect them.
> 
> Simplicity is golden here, as long as we don't truly compromise 
> security.  I don't think passwords are necessarily a compromise of 
> security.  At least not in contrast to TLS certificates (which I 
> personally believe are a great technology).

On Sat, 9 Sep 2006, Ben Meadowcroft wrote:
> 
> But you usually can't get someones certificate by offering a mars bar on 
> the street...

On Fri, 8 Sep 2006, George Staikos wrote:
> 
> Do you have evidence that this is any different than the password case?

On Sat, 9 Sep 2006, Anders Rundgren wrote:
> 
> I agree with all you things you say about this technology but let me 
> begin with another, for the WHATWG applicable comment:
> 
>   The "standards" for PKI provisioning using browsers are in a real mess.
>   Xenroll, KeyGen and a JavaScript CRMF do not really make this
>   part as simple as it must be in order to challenge passwords.
> 
> Anyway, my proposal was about offering a "migration path" to other 
> authentication schemes, as well as improving the current de-facto 
> standard.
> 
> Regarding certificates: the provisioning, mobility and pretty 
> proprietary card schemes (like no preinstalled drivers in Windows) will 
> make this transition period rather long.  That none of the browser 
> vendors support digital signatures (in a reasonable way), is another 
> reason why PKI deployment is hampered.
> 
> Personally, I believe PKI will stay marginal [*] until you can keep your 
> IDs in a mobile phone.  The US PIV card (to take an example), only 
> allows you to keep a single Federal ID which is not particularly useful 
> for the Internet where you will continue to have multiple and mostly 
> entirely independent IDs.

I think these ideas are very interesting, but I don't think HTML5 is the 
right place to start with these ideas. I recommend approaching browser 
vendors and seeing what they would be interested in providing.


On Wed, 15 Aug 2007, Julien TOUCHE wrote:
> 
> I want to sugges some new attributes related to security of the form for 
> Web Forms 2, XForms and HTML 5.
> 
> Example:
>   <input type="password" hash="sha256" name="mypass" />
> so the browser transmits only the corresponding hash of the given value.
>
> Also, as we need to avoid to transform hash as a simple password, server
> need to propose one-time salt for the client like this
> <input type="password" hash="sha256" salt="123456" name="mypass" />
> in order to avoid crackers to submit directly the hash to servers.

On Wed, 15 Aug 2007, Kornel Lesinski wrote:
> 
> Unfortunately this will not secure browsing session, because once user 
> is authenticated, server will have to use cookies which could be stolen 
> and used to impersonate the user.
> 
> My suggestion is to kill two birds with one stone by marrying forms with 
> Digest authentication (RFC 2617).
> 
> Digest is already implemented in browsers, doesn't require storage of 
> unhashed passwords, protects entire browsing session (with integrity 
> checking of payload and stopping replay attacks) and can provide mutual 
> authentication - it would be wasteful to re-invent and re-implement all 
> that for forms.
> 
> The dealbreaker in current Digest implementations is the user interface 
> - looks unfriendly, can't be customized, website can't offer account 
> registration until user cancels login and there's no logout mechanism.
> 
> This can be solved by providing form controls that would log user in 
> using Digest authentication:
> 
> <form method=digest>
> <input type=hidden name=realm value="my realm">
> <input type=text name=username>
> <input type=password name=password>
> </form>
> 
> or
> 
> <input id=myusernameid>
> <input type=password authentication=digest realm="my realm"
> username=myusernameid>
> 
> UI for logging out could be as simple as <button type=logout>, however 
> implementation details are probably outside scope of HTML 5.

On Thu, 16 Aug 2007, Julien TOUCHE wrote:
> [snipped parts not relevant to html, like ip-limiting cookies]
> 
> it is one way to achieve above hash passwd, if it could be integrated in 
> a standard html fashion.
>
> Still need to standardize other algorithm than in rfc2617 which 
> specifies only md5 (better to add sha1/sha256/sha512)
>
> rfc2617 also defines a salt-like with nonce, which is a very good point, 
> but it seems to give the same problem said in first mail: it need server 
> to have passwd in clear to be able to compare against a changing hash 
> (if nonce is used) ...

I don't really understand what problem the above solves that isn't solved 
better by SSL.


On Tue, 21 Oct 2008, Aaron Swartz wrote:
>
> The most common way of authenticating to web applications is:
> 
> Client: GET /login
> Server: <html><form method="post">....
> Client: POST /login
> user=joesmith01&password=secret
> Server: 200 OK
> Set-Cookie: acct=joesmith01,2008-10-21,sj89d89asd89s8d
> 
> The obvious problem with this is that passwords are transferred in the 
> clear. Some major web services redirect the user to an SSL server for 
> the login transaction, but SSL is too expensive for the vast majority of 
> services. (We can hope ObsTCP will fix this, but that's a long way away, 
> if ever.)
> 
> My proposal: add something to HTML5 so that the transaction looks like this:
> 
> Client: GET /login
> Server: <html><form method="post" pubkey="/pubkey.key">...
> [with a nonce]
> Client: POST /login
> dXNlcj1qb2VzbWl0aDAxJnBhc3N3b3JkPXNlY3JldA==
> Server: 200 OK
> Set-Cookie: acct=joesmith01,2008-10-21,sj89d89asd89s8d
> 
> where the base64 string is the form data encrypted with the key 
> downloaded from /pubkey.key. This should be fairly easy to implement 
> (for clients and servers), falls back to exactly the current behavior on 
> browsers that don't support it, and solves a rather important problem on 
> the Web.

I don't see why this is an less expensive than SSL. SSL is expensive 
primarily in terms of CPU power to do the encryption, but if all you are 
doing is the login form, then the cost is mostly mitigated.

There's no point doing the login over unencrypted HTTP, since if someone 
can sniff the password, they can just as easily MitM you and just grab the 
password unencrypted.

Also, as Philip Taylor mentioned, this seems like it would be vulnerable 
to an offline dictionary attack.


On Tue, 21 Oct 2008, Aaron Swartz wrote:
> 
> There are three costs to SSL:
> 
> 1. Purchasing a signed cert.
> 2. Configuring the web server.
> 3. The CPU time necessary to do the encryption.

The first two costs are flat fees much like the cost of setting up a 
regular HTTP server. The problematic cost is #3, which your proposal 
suffers from as well.


[snip conversations with no actionable feedback]


On Tue, 21 Oct 2008, Kornel Lesinski wrote:
> 
> You're re-inventing Digest authentication (RFC 2617).
> 
> Digest has two-way authentication with hashed challenge-response, 
> nonces, can use passwords stored as hashes (though not as secure as 
> storage for plaintext auth), avoids insecurity of cookies and even has 
> simple data integrity verification.
> 
> ...and it's all futile if attacker can modify a single byte sent over 
> the network.
> 
> Anyway, it doesn't make sense to duplicate all that functionality in 
> forms just because typical interface for HTTP authentication is ugly and 
> unusable. You can fix the interface, and there's proposal for it already 
> (from 1999!): http://www.w3.org/TR/NOTE-authentform
> 
> I think that proposal is generally a good idea, but the details could be 
> improved (i.e. should reuse existing forms and input types rather than 
> creating new ones that can't offer seamless fallback).

I agree that Aaron's proposal doesn't seem to give us much over Digest.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'