When you identify yourself, you are claiming that you are someone. But there is no proof of that. Authentication, on the other hand, is showing proof that you are what you claim to be, like showing your personal id or typing in your password.
More often than not, the websites need that proof to serve you sensitive resources.
HTTP has its own authentication mechanisms that allow the servers to issue challenges and get the proof they need. In this article, you are going to learn about what they are and how they work. We’re also going to cover the pros and cons of each one and find out if they are really good enough to use on their own (spoiler: they are not).
Before venturing deeper into the concrete HTTP authentication mechanisms, let’s explore what the HTTP authentication is.
How Does the HTTP Authentication Work?
Authentication is a way to identify yourself to the Web server. You need to show proof that you have the right to access the requested resources. Usually, this is done by using a combination of username and password (key and secret) which the server validates and then decides if you can access the resource.
HTTP offers two authentication protocols:
- Basic Authentication
- Digest Authentication
Before learning more about each one, let’s go through some of the basic concepts.
Challenge/Response Authentication Framework
What does this mean?
It means that when someone sends a request, instead of responding to it immediately, the server sends a challenge. It challenges the user to provide proof of identity by entering the secret information (username and password).
After that, the request is repeated using the provided credentials, and if they are correct, the user gets the expected response. In case the credentials are wrong, the server can reissue the challenge or just send the error message.
Authentication Related request/response headers
The server issues the challenge by utilizing the WWW-Authenticate response header. It contains information about the protocol and the security realm.
After the client inputs the credentials, the request is sent again. This time with the Authorization header containing the algorithm and the username/password combination.
If the credentials are correct, the server returns the response and additional info in an optional Authentication-Info response header.
Security Realms
Security realms provide a way to associate different access rights to different resource groups on the server. These are called protection spaces.
What this means effectively is that depending on the resource you want to access, you might need to enter different credentials.
The server can have multiple realms. For example, one would be for website statistics information that only website admins can access. Another would be for website images that other users can access and upload images to.
/admin/statistics/financials.txt -> Realm=”Admin Statistics”
/images/img1.jpg -> Realm = “Images”
When you try to access the financials.txt the server will challenge you and the response from would look like this:
Simple HTTP Authentication example
Now let’s connect the dots by looking at the simplest HTTP authentication example (Basic authentication, explained below):
1. User Agent -> Server
The user requests access to an image on the server.
The server sends the challenge to the user.
The user identifies itself via form input.
The server checks the credentials and sends the 200 OK status code and the image data.
Now let’s drill down and look into basic authentication.
Basic Authentication
The most prevalent and supported protocol out there. It has been around since the HTTP/1.0 and every major client implements it.
The example above depicts how to authenticate by using Basic authentication. It’s rather simple to implement and use, but it has some security flaws.
Before going to the security issues, let’s see how the Basic authentication deals with username and password.
Basic authentication packs the username and password into one string and separates them using the colon (:). After that, it encodes them using the Base64 encoding. Despite what it looks like, the scrambled sequence of characters is not secure and you can decode it easily.
The purpose of the Base64 encoding is not to encrypt, but to make the
username and password HTTP compatible. The main reason for that is
because you can’t use international characters in HTTP headers.
So anyone listening to the requests can easily decode and use the credentials.
Even worse than that, encoding the username and password wouldn’t help. A malicious third party could still send the scrambled sequence to achieve the same effect.
There is also no protection against proxies or any other type of attack that changes the request body and leaves the request headers intact.
So, as you can see, Basic authentication is less than perfect authentication mechanism.
Still, despite that, you can use it to prevent accidental access to protected resources, and to it offers a degree of personalization.
To make it more secure and usable, Basic authentication can be implemented by using HTTPS over SSL which we talk about in part 5 of the series.
Some would argue it’s only as secure as your transport mechanism.
Digest Authentication
Digest authentication is a more secure and reliable alternative to simple but insecure Basic authentication.
So, how does it work?
Digest authentication uses MD5 cryptographic hashing combined with the usage of nonces. That way it hides the password information to prevent different kinds of malicious attacks.
This might sound a bit complicated, but it will get clearer when you see how it works on a simple example.
Example
1. User Agent -> Server
2. Server -> User Agent
3. User Agent -> Server
Detailed Explanation
Let’s define these:
- nonce and opaque – the server defined strings that client returns upon receiving them
- qop (quality of protection) – one or more of the predefined values (“auth” | “auth-int” | token). These values affect the computation of the digest.
- cnonce – client nonce, must be generated if qop is set. It is used to avoid chosen plaintext attacks and to provide message integrity protection.
- nc – nonce count, must be sent if qop is set. This directive allows the server to detect request replays by maintaining its own copy of this count – if the same nc value appears twice, then the request is a replay.
The response attribute is calculated in the following way:
4. Server -> User Agent
Short Summary
As you can see the Digest authentication is more complicated to understand and implement.
It is also more secure than Basic authentication, but still vulnerable to a man-in-the-middle attack. RFC 2617 recommends that Digest authentication is used instead of the Basic authentication since it remedies some of its weaknesses. It also doesn’t hide the fact that Digest authentication is still weak by modern cryptographic standards. Its strength largely depends on the implementation.
So in summary digest authentication:
- Does not send plain text passwords over the network
- Prevents replay attacks
- Guards against message tampering
Some of the weaknesses:
- Vulnerability to the man-in-the-middle attack
- Many of the security options are not required and thus make Digest authentication function in a less secure manner if not set
- Prevents the use of strong password hashing algorithms when storing passwords
Due to these facts, the Digest authentication still hasn’t gained major traction. The Basic authentication is much simpler and combined with SSL still more secure than the Digest authentication.
Conclusion
This’s it for this part of the HTTP series.
We’ve gone through different authentication mechanisms that HTTP offers by default and talked about their advantages and disadvantages.
These concepts are hopefully not just the letters on the screen anymore, and the next time you hear about them you will know precisely what they are and when to apply them.
You are also aware that there are security risks that haven’t been solved by these authentication mechanisms. That’s why concepts like HTTPS and SSL/TLS exist.
No comments:
Post a Comment