For those not yet familiar with the Simple Security Fails series – previous posts are located here: part 1, part 2, part 3, part 4
Lately I have tested a number of web applications that make use of Basic Authentication. For those unfamiliar, “HTTP basic authentication is a simple challenge and response mechanism with which a server can request authentication information (a user ID and password) from a client. The client passes the authentication information to the server in an Authorization header. The authentication information is in base-64 encoding.” You might be wondering – why is this a security issue? Let’s get into the detail.
The Breakdown
If you’ve ever run into a prompt like the one in the screenshot below, then you’ve seen Basic Authentication in practice. As you can see, the server is asking a user for their credentials.
If you had proxied your traffic to view the HTTP request that was generating this page, you would have seen something similar to the HTTP request shown in the screenshot below. The “Authorization” header in the request contains the Basic Authentication value.
The “Authorization” header in the request above contains the Basic Authentication token. The token is constructed by taking the string “Basic “ and appending it will the base64 encoded value of the username and password.
If you took the Basic Authorization token from the HTTP request above, and base64 decoded the encoded portion of the string, you would obtain the cleartext username and password of the application user:
Command Line Usage
echo 'TGVnaXRVc2VyOlN1cGVyU2VjdXJlUGFzc3dvcmQ=' | base64 -D
LegitUser:SuperSecurePassword
The Issue
As you may be able to infer from the section above, there is at least one obvious issue with Basic Authentication: the transmission of credentials in cleartext. Because we’re encoding the credentials, rather than encrypting or tokenizing, it’s trivial for an attacker to reverse the process and to obtain the cleartext credentials. Not only could the credentials be stolen during transmission, but it’s actually possible to obtain them from the user’s browser cache as well. The credentials are typically cached there for the duration of the session window.
A common rebuttal that teams have toward these issues is SSL. If the application communicates over HTTP rather than HTTPS, is this still a problem? Afterall, an attacker would not be able to obtain the header value from the message, if it’s encrypted.
Unfortunately, even if SSL is used, Basic Authentication is still flawed.
- No session management
- No logout functionality
- No support for account lockout
- Attackers can continuously brute force account passwords
What options do we have?
So, if we can’t use Basic Authentication, what can we use? There are a couple of other authentication platforms that can be implemented depending on the application or APIs:
- OAuth
- JSON Web Tokens (JWT), SAML, Bearer Tokens, etc.
- Form Based Authentication
- Utilizes cookies for session management
One last tip before ending this post would be to ensure to implement additional security controls on top of these authentication platforms. If you choose to use a highly sophisticated authentication platform, yet still use HTTP instead of HTTPS, attackers would still be able to compromise sensitive information being sent to the server.