Why HTTP Basic Auth is Bad
The most simple way to restrict access to a resource on a web server is to use a method called HTTP Basic Authentication. This dates back to the 1996 definition of HTTP/1.0 which became the first widely accepted authentication scheme. This approach was not as secure as other schemes that were developed later. The current prevailing mechanism is to use token based authentication. The token is either provided by the web server, or a dedicated authentication service. The client either stores the token in a cookie value kept in the web browser, or sends it in specific HTTP request header for each web request. This is the prevailing method of authentication for cloud API services today. Another popular one is OAuth.
I don’t like HTTP Basic Auth for a number of different reasons, and have avoided it for many years. When asked by a colleague today why I don’t like it, I began thinking of all the reasons why. Here is the full list:
1) HTTP Basic is less secure than a token based system because the username and password credentials are carried by every single request between the client and the server. Username and password credentials do not typically expire, and if they do, it’s not very often. Using a token allows the token to be regularly expired (typically in a number of minutes), and the actual account credentials are only ever transmitted between the client and the authentication service to acquire the valid token to start with, and upon expiration.
2) HTTP Basic is typically protected by routing all content over SSL/TLS protocols. Although SSL/TLS is assumed to be secure, it is possible to defeat their security, and it’s better not to depend on it for every request.
3) The effective attack surface for a system that supports HTTP Basic is much bigger than one that uses tokens issued from a central auth service.
- With HTTP Basic Auth, each web server needs to be able to validate usernames and passwords. This means that it must have a copy of the password hashes, or that it must have access to a remote system that can validate them. An attacker need only compromise any one of the service endpoints in order to intercept the credentials and potentially re-exploit a given account even after a significant period of time has elapsed.
- The amount of server-side source code that could contain bugs that are vulnerable to security exploits will continue to grow over time as the system grows and new features are added, whereas if the auth service is standardized and centralized, it can be more easily protected, is less subject to change, and does not need to be scaled out to the same extent.
4) For performance reasons, security credentials may need to be cached on the servers that handle high volumes of requests. This raises another set of concerns about keeping the cached data secure, and adds complexity to operational tasks such as the revocation of access to an account. If account information is widely cached, it may be complicated to remove it everywhere.
5) Systems that use token based authentication could offer a service over HTTP that does not use SSL/TLS for high performance use cases where the overhead of encryption is not acceptable. Special encrypted read-only tokens could be issued for this purpose. Such tokens could be carried in web browsers using cookies. With HTTP Basic, special read-only accounts would be needed to produce the equivalent. Automated password expiration in that case would be awkward, and usually impractical.
6) For web use cases, there is no good way to allow a web user to “log out” of an HTTP Basic Auth session. Although there are some convoluted and stupid workarounds, the only reliable method is to ask users to quit their web browser in order to log out. Yuck!
If there is any doubt, please don’t use HTTP Basic Auth. I’m asking you nicely.
You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.