Rant warning
We enter our usernames and password on pretty much all the sites we commonly visit. Authentication is probably one of the first things you're being taught when starting to work with PHP. For some reason, in 99% of the cases this is done through an HTML form, with the username and password submitted as a urlencoded string.
You probably know that HTTP also has native authentication, in the form of Basic and Digest authentication (read my older article if you want to know how). Every browser and pretty much any HTTP client does too. There's some big benefits to that, because it provides a very standardized mechanism to authenticate a client, whether you're a machine or human.
What baffles me is that HTTP authentication hasn't been developed further. HTTP Digest is pretty secure by itself, and has some nice features (hashed password, protection against man in the middle and replay attacks, message digests) which is way more advanced than an HTML POST form with a session cookie can provide.
What's missing?
- There's no way for a user to see if they are authenticated to a site. Perhaps a username in the addressbar?
- Pretty much everybody always wonders how they can code a logout mechanism. Because there are no session cookies that can be destroyed, there are some hacks that trick the browser to ask for credentials again. There should be no need for the server to provide this functionality. The browser knows it's logged in, and HTTP applications are stateless. We need an in-browser log-out button.
- Less important, some javascript hooks that allow developers to still use html forms to setup HTTP authentication.
Mozilla is doing some interesting things with their Account Manager Add-on for firefox, but even that add-on does not support HTTP authentication. With Account Manager they are jumping through some hoops with javascript hooks so it works with regular authentication systems, but you'd think that if HTTP Authentication was used, things could be a lot more straightforward. The browser knows exactly who is logged in.
So, does anyone know how this happened? Is there a major flaw in HTTP authentication I'm just missing?
Absolutely true, HTTP Authentication is secure enough and can extended to authentication/authorization services like those provided by LDAP/Exchange (server side). But one other thing that also missing is the potential to use one username/password pair on multiple independent servers/web-applications. Something OpenID, Google accounts and Yahoo accounts (and many more) are used for.
Of course a apache module / other webserver addition could be used in background to cache and verify OpenID's, etc... but I geuss that could turn out to be difficult to achieve since there is no real standard.
Also there is little control over HTTP Authentication in browsers.
HTTP authentication is ugly for the end user. Web designers would be mortified if they spent several hours designing a beautiful log-in form and then the developer goes and implements HTTP authentication which pops up an ugly pop-up dialog box.
I suppose it's fine for intranets etc., but can you imagine Facebook and Twitter popping up those ugly username/password boxes?
I just don't think built-in browser authentication is very flexible and it needs a lot of work to be usable on a real website.
From a technical standpoint, it works great and achieves the task well (aside from no logout, something that baffles me too!) but from a design perspective it's just ugly.
@James:
My point (3) also mentions Javascript hooks for this very purpose. There's absolutely no need for it to be ugly. If some good thought went into making HTTP authentication more usuable in the browser, I feel this should be important as well.
Well ... the problem is that what's missing is missing.
You can't log out, short of restarting the browser. You can't style the login box. Those two are pretty much keeping the adoption to a trickle.
Your #1 isn't really the case though. The server knows who is logged in when serving the content. It's trivial to have it dynamically insert the login name (or the name of the user, fetched from a database) in the corner of the web page, same as with the session cookie method of authentication.
You're absolutely right though. A log-out button and javascript hooks would eliminate the barriers to widespread adoption.
Ah, my pet angst.
What's broken for me about this in Firefox:
1. https://bugzilla.mozilla.org/show_bug.cgi?id=300002
2. https://bugzilla.mozilla.org/show_bug.cgi?id=254534
3. https://bugzilla.mozilla.org/show_bug.cgi?id=521588
Why the hell would you want to style the login box?
IMHO that's functionally equivalent to wanting to style the scrollbar, or other browser UI elements (or, to open a can of worms, to enforce your fonts). The web designer should have no business giving the browser any sort of "style" - the only business they have is providing the content.
Related to number 3... Because there's no way to style the login prompt, there's no way to implement a password recovery mechanism in a user friendly way.
Jim.
Isn't there a way to provide arbitrary HTML for the Access Denied response?
IMHO placing a "forgot your password?" link there would work perfectly.
Agreed that the browser should not only support login, but also logout and showing who the logged in user is.
The problem with the login box is not so much that you can't style it. As has been pointed out, sites don't generally mind not styling the url bar or other elements either. The problem is that it almost always seems to be implemented as a modal popup dialog. Modal popups usually make for a horrible user experience because a user is forced to deal with the popup before they do anything else in the application.
Also a problem is the authentication protocol itself. Basic auth is just about as bad as you can get. The user's password is sent in the clear with every request. Digest is better but still not great, despite what the author of this post seems to be claiming. It is better than POSTing from an html form over an unencrypted connection though.
What we really should be using is a system built into the browser chrome that doesn't interrupt a user with a modal popup as a result of requesting a page. It should display the login status in the browser, as demonstrated by Mozilla's account manager add-on.
It should use a strong authentication protocol which prevents both active and passive attacks and provides mutual authentication of the client and the server to each other. SRP for passwords, X509 or similar for certificates, or Kerberos tickets for existing single sign-on sessions. The authentication exchange should be used to initiate a TLS-encrypted persistent connection with the site. While that session is active, the browser should prominently indicate that fact to the user. This way, being "signed in" means you are authenticated, and your communication is encrypted, and the browser is visually telling you this in an obvious way.
a login toolbar should be a great addin. I can check if the browser has it, read its fields and status. hurry and code it. let me know so i can install it.
Personally, as a user, I would MUCH rather have a login dialog that was in a standard place and used a standard format than play "hunt the login". Whether it's a modal dialog or not is far down on my list of concerns.
If the browser makers added a "logout" option and a way of managing this stateless login information, I for one would be asking site owners to support it.
Personally, the concern that a designer has spent hours forming a beautiful login is a symptom of the even larger problem facing the web.
Morons called designers think that the presentation is more important than the content. This in turn leads to a list of problems:
1) The same morons will use authentication that fits their stupid pretty picture scheme.
2) The exclude people with visual disabilities.
3) They stupidly think that their interpretation of the world is better than the one people know how to use.
Yeah, I agree with that too. I have to emphasize the standardization (ugh) of the logon panel, even though it is ugly. What I wouldn't like to see is everyone doing different things to the logon screen just to "prettify" it, or rather, as long as there is a way to extend that class inheriting the properties and (for Petessake) not allowing renaming the boxes and break automation, I can be even cool with these frisky logon screens (-sorry, my 5 cents rant -)
The big flaw that renders HTTP Digest auth almost useless is that it does not work if you store your passwords as hashes (e.g. in a database), which is something you should do.
The reason is that the browser/client throws the plain-text password into the digest algorithm, but the server only knows the hash. So it can't actually verify what the client sent.
Ingmar, the solution is simple: store the A1 part of the digest string. You need to hash anyway, so why not 'user:realm:password'.
Another problem inherent in HTTP authentication is that it has to be done with every single HTTP request. That can dramatically add to the server load. Add to that the fact that you have to use HTTPS to keep the password secure, and HTTP authentication is pretty much not viable for large-site use.
Another issue is that HTTP logins have to be tied to the server name, making single logins across server farms difficult if not impossible.
BTW, it IS possible to use Kerberos over HTTP in many browsers to support single-sign-on. But that's non-standard, requires browser reconfiguration and a Kerberos infrastructure. Very nifty in intranet situations.
Kevin,
If you do it right, re-authenticating a user does not have to be heavier than, say, validating a session key.
Your point about being stuck to a single server is valid though.
Evert
Another problem that could be faced with DIGEST authentication is to map those system user profiles with web application specific profiles.
For example , if in a given web application we need to control options and links as per user specific role, we may need to import digest specific user profiles into properitory backend. This is unnessasary duplication of data.
Could there be more elegent alternative to this issue in DIGEST authenticaton?
Thants,
Leena
Great article and great discussion.
Seen only few apps like server control panels using this method.
Most of these issues stem from low usage of the technique and thus it looks non-standard. Probably, when more people starts using it, further development and user-friendly methods might happen.
IMHO, it seems kind of bridging between different levels. Who knows, when evolved, authentication ¬
@Kirk - :) You needn't that harsh on designers. There are good ones too.
Thanks Evert
(Seems something happened to the previous comment)
..... IMHO, it seems kind of bridging between different levels. Who knows, when evolved, authentication and related issues could become another layer within the browser and more space would be available for content. ........
What happened was that a serious lack of thought went into how PHP and CGI programs got access to the HTTP authentication headers and status in Apache in a shared hosting or load balanced environment. Because they couldn't get that access, web app developers had to do it all over themselves.
Most of the complexity of the spec for OAuth 1.0 was to work around this problem.
Some of these problems are actually discussed in the HTTP/1.1 standard itself (RFC 2616):
15.6 Authentication Credentials and Idle Clients
Existing HTTP clients and user agents typically retain authentication
information indefinitely. HTTP/1.1. does not provide a method for a
server to direct clients to discard these cached credentials. This is
a significant defect that requires further extensions to HTTP.
Circumstances under which credential caching can interfere with the
application's security model include but are not limited to:
- Clients which have been idle for an extended period following
which the server might wish to cause the client to reprompt the
user for credentials.
- Applications which include a session termination indication
(such as a `logout' or `commit' button on a page) after which
the server side of the application `knows' that there is no
further reason for the client to retain the credentials.
This is currently under separate study. There are a number of work-
arounds to parts of this problem, and we encourage the use of
password protection in screen savers, idle time-outs, and other
methods which mitigate the security problems inherent in this
problem. In particular, user agents which cache credentials are
encouraged to provide a readily accessible mechanism for discarding
cached credentials under user control.
HTTP-authorization window cannot be customized. There is no way to place "forgot password?" link (as mentioned above). But the most important is that it could be easily bruteforced while HTML-form with captcha could not.
Dmitry, while implementing a captcha isn't easy, there's no reason you can't throttle authentication attempts.
I've also been dwelling with HTTP auth a lot.
Customization of the form could be as easy as :
If the server sends 401 and in the body of the response sends some HTML + CSS + Javascript + whatever, the browser might display it (as it does for 404). If inside this HTML there is a form with two fields with a certain default id/name/attribute/whatever, instead of posting those two fields the browser will use them as auth username/password, while the resto of the form fields will be posted as normal (captchas, additional login informations on that specific service etc..).
Having a logout button in the browser is an option, but still, where is the user redirected after he logs out? For marketing reasons, sites may want to redirect it to a "goodbye, come back soon" page, or do whatever else.
Adding an "Authentication-Info: terminated/logout/end" header with which the server can tell the browser to forget about auth stuff is so trivial that I cannot understand how in so many years nobody implemented it.
Also, javascript support needs to be implemented for :
- Knowing the username that is logged in
- Knowing wether or not it is logged in
- Returning 401 from an ajax call
As to point 1, yes, having it in the address bar as it happens for https infos would be a nice feature, but there are tons of way of doing it on the server (and with a better javascript support also from an html/js only application).
I don't understand the point 3.
"Less important, some javascript hooks that allow developers to still use html forms to setup HTTP authentication."