Basic Auth – Just Say No
One simply should not use basic auth. Period. And I am not talking about security here. Only functionality and what you can, and most importantly cannot do with basic auth.
Okay, I know that was a bit harsh, and I do use basic auth myself sometimes. Like for instance with something dead-simple on an intranet, where we just need to shut out the masses a bit.
But what is wrong with basic auth then?
Logout Not Possible
Because the browser remember the authentication data and keep resending it for each request to the host authenticated against, there can be no logout, aside from closing the browser. Often, this is seen done with Javascript (closing the browser window), but a) it is not safe as the client can say no and b) some browsers deny it.
It Does Not Present Itself Nicely to the Client
It is the browser, that pops up a dialog. Basically, you cannot as a developer, control how this dialog looks and behaves. And it looks different in each browser. So, you cannot even determine if it needs to ask for “username”, “login” or …
Also, the application cannot show meaningful information to the client, when authentication goes wrong. This could be “you have xx tries left, before the login is locked”.
No Way To Provide Extra Functionality
Like a “change password” option, when the login has expired. Or a “remember me” option. Or whatever the application would like. Again, it is the browser, that does it all.
All this stems from the fact that it is the browser, that controls the authentication. It is the browser, that stores the authentication data and send it on with each request. And it does not have an API or the like to clear it, hook into missing auth or anything like it. The application is out of the loop.
Just say no! 
December 4, 2009
В· 
polesen В· 
7 Comments
Tags: http, security В· Posted in: Programming
7 Responses
I agree… but I assume you’re speaking of the de-facto server-supplied basic auth right?
I imagine that all of the problems you identify above are solved if you have a server-side app emitting the basic auth headers.
Cheers,
Mike G.
Nope – none of the problems I mention are solveable by the application itself emitting the headers.
It will still be the browser, that pops up the dialog and does all the handling itself. No way to control that.
There are lots of HTTP clients besides browsers
In many cases HTTPS + Basic auth can be sufficient for confidential, authenticated access to resources.
An obvious example being the twitter API.
@johnstock: Yes, thats true.
I’m using basic auth in two instances.
In an internal private non-commercial network for squid authentication for proxy users. Change password is performed using a cgi running on the squid server.
I’m also using it on an externally facing web server; but the caveat is that I make apache httpd enforce use of HTTPS.
It’s useful for adhoc authentication for a small amount of users – as long as HTTPS is enforced for public networks.
That said, I would actually recommend other methods of authentication such as Kerberos or authpf; especially for external user authentication.
I’d never use basic auth for a client/frontend login but its great for walling-out users from backend pages, or more specifically directories with analytic scripts and other sensitive material (over HTTPS though).
It is good (better, easier, straight forward) as long as you use it within internal network (intranet environment), usually for admin related tool.
Leave a Reply