HTTP Lessons – Lesson 4 – Client Authentication Mechanisms
HTTP Lessons – Lesson 1 – Overview of basic concepts
HTTP Lessons – Lesson 2 – Architectural Aspects
HTTP Lessons – Lesson 3 – Client Identity
HTTP Lessons – Lesson 4 – Client Authentication Mechanisms
HTTP Lessons – Lesson 5 – Security
HTTP Lessons – Glossary
In the previous sectionWe talked about the different ways websites can identify the visiting user.
But a definition is merely a claim. When you define yourself, you're claiming to be someone. But there's no proof.
With authentication, you show proof that you are who you claim to be, such as showing your personal ID or entering your password.
Often, websites need this proof to reveal their sensitive resources.
HTTP has its own authentication mechanisms that allow servers to challenge and obtain the evidence they need. You'll learn what they are and how they work. We'll also cover the pros and cons of each and explore whether they're good enough to use on their own (spoiler: they're not).
In this article, you will learn about the following topics:
- How does HTTP authentication work?
- Basic authentication
- Digest authentication
Before we delve deeper into HTTP authentication mechanisms, let's talk about what HTTP authentication is.
How does HTTP authentication work?
Authentication is a way to identify yourself to a web server. You must provide proof that you have the right to access the requested resources. This is typically done using a combination of username and password (key and secret), which is then verified by the server, which then determines whether you can access the resource.
HTTP offers two authentication protocols:
- Basic authentication
- Digest authentication
Before we learn more about each one, let's review some basic concepts.
1. HTTP uses a challenge/response authentication framework
What does it mean?
When someone sends a request, instead of responding immediately, the server sends an authentication request, forcing the user to prove their identity by entering secret information (username and password).
The request is then repeated using the provided credentials, and if correct, the user receives the expected response. If the credentials are incorrect, the server resubmits the challenge or simply sends an error message.
2. Authentication-related request/response headers
The server resolves the issue by using the WWW-Authenticate response header, which contains information about the authentication protocol and security realm.
After the client enters its credentials, the request is sent again, this time with an Authorization header containing the authentication algorithm and username/password combination.
If the credentials are correct, the server responds and provides additional information in an optional Authentication-Information response header.
3. Security areas
Security zones provide a way to associate different access resources with different resource groups on the server. These are called protection zones.
This is effective so you may need to enter different credentials depending on the resource you want to access.
A server might consist of multiple domains. For example, there should be one for website statistics, which only website administrators can access, and one for website images, which other users can access and download.
/admin/statistics/financials.txt -> Field = “Admin Statistics”
/images/img1.jpg -> Field = “Images”
When you try to access the Financials.txt file, you will be challenged by the server and the response will look like this:
HTTP/1.0 401 Unauthorized WWW-Authenticate: Basic realm="Admin Statistics"
More information on security areas: https://tools.ietf.org/html/rfc7235#section-2.2
Simple HTTP authentication example
Now let's connect the dots by looking at the simplest example of HTTP authentication (Basic authentication, explained below):
1. User Agent -> Server
A user requests access to some images on the server.
GET /gallery/personal/images/image1.jpg HTTP/1.1 Host: www.somedomain.com
2. Server -> User Agent
The server sends the authentication challenge to the user.
HTTP/1.1 401 Access Denied WWW-Authenticate: Basic realm="gallery"
3. User Agent -> Server
The user identifies himself through form input.
GET /gallery/personal/images/image1.jpg HTTP/1.1 Authorization: Basic Zm9vOmJhcg==
4. Server -> User Agent
The server checks the credentials and 200 OK status code and sends the image data.
HTTP/1.1 200 OK Content-type: image/jpeg ...
It's not that complicated, is it?
Now let's dive in below and look at basic authentication.
Basic authentication
It is the most common and supported authentication protocol. It has been around since HTTP/1.0, and every major client implements it.
The example above demonstrates how to authenticate using Basic authentication. It's fairly simple to implement and use, but it has some security flaws.
Before we get into the security issues, let's see how Basic authentication deals with username and password.
Basic authentication packages the username and password into a string and separates them using a colon (:). It then encodes them using Base64 encoding. While it may appear complex, the scrambled string is not secure and is easily decrypted. The purpose of Base64 encoding is not encryption, but rather to ensure the username and password are compatible, as international characters are not allowed in HTTP headers.
GET /gallery/personal/images/image1.jpg HTTP/1.1 Authorization: Basic Zm9vOmJhcg==
From this example, “Zm9vOmJhcg ==" is nothing but the Base64 encoded string “foo:bar”.
Therefore, anyone listening to the requests can easily decipher and use the credentials.
Worse than that, encoding the username and password won't help. A malicious third party could still send the encrypted string to achieve the same effect.
Additionally, there is no protection against proxies or any other attacks that modify the request body and leave the request headers intact.
As you can see, Basic authentication is not a perfect method.
However, it can still be used to prevent accidental access to protected resources and offer some level of customization.
To make it more secure and convenient, basic authentication can be performed using HTTPS over SSL, which we talked about in part 5 of the series.
Some, The security of your system is as important as the security of your transfer mechanism..
Digest authentication
Digest authentication was made as a more secure and reliable alternative to the simple but insecure Basic authentication.
So, how does it work?
Digest authentication uses MD5 cryptographic hashing combined with the use of nonces to hide password information and prevent different types of malicious attacks.
This may sound a little complicated, but it will become clearer once you see how it works in a simple example.
1. User Agent -> Server
GET /dir/index.html HTTP/1.0 Host: localhost
The client sends an unauthenticated request.
2. Server -> User Agent
HTTP/1.0 401 Unauthorized WWW-Authenticate: Digest realm="shire@middleearth.com", qop="auth,auth-int", nonce="cmFuZG9tbHlnZW5lcmF0ZWRub25jZQ", opaque="c29tZXJhbmRvbW9wYXF1ZXN0cmluZw" Content-Type: text/html Content-Length: 153 <!DOCTYPE html> <html> <head> <meta charset="UTF-8" /> <title>Error</title> </head> <body> <h1>401 Unauthorized.</h1> </body> </html>
The server forces the client to authenticate using Digest authentication and sends the necessary information to the client.
3. User Agent -> Server
GET /dir/index.html HTTP/1.0 Host: localhost Authorization: Digest username="Gandalf", realm="shire@middleearth.com", nonce="cmFuZG9tbHlnZW5lcmF0ZWRub25jZQ", uri="/dir/index.html", qop=auth, nc=00000001, cnonce="0a4f113b", response="5a1c3bb349cf6986abf985257d968d86", opaque="c29tZXJhbmRvbW9wYXF1ZXN0cmluZw"
The client calculates the response value and sends it along with the username, realm, URI, nonce, opque, qop, nc, and cnonce. Lots of things.
Let's define these:
- nonce and opaque – server-defined strings that should be returned as received by the client
- qop (protection quality) – one or more of the predefined values (“auth” | “auth-int” | token). These values affect the digest calculation.
- cnonce – The client nonce must be generated if qop is set. It is used to avoid chosen-plaintext attacks and to protect message integrity.
- nc – If qcp is set, a nonce number must be sent. This directive allows the server to detect request duplications by maintaining its own copy of this number – if the same nc value appears twice, the request is replayed.
The response attribute is calculated as follows:
HA1 = MD5("Gandalf:shire@middleearth.com:Lord Of The Rings") = 681028410e804a5b60f69e894701d4b4 HA2 = MD5("GET:/dir/index.html") = 39aff3a2bab6126f332b942af96d3366 Response = MD5( ) = 5a1c3bb349cf6986abf985257d968d86
If you are wondering how to calculate the answer depending on Qop, RFC 2617You can find it at.
4. Server -> User Agent
HTTP/1.0 200 OK Content-Type: text/html Content-Length: 2345 ...
The server calculates the hash on its own and compares the two. If they match, it serves the client with the requested data.
As you can see, Digest authentication is more complex to understand and implement.
It is also more secure than Basic authentication, but is still vulnerable to a man-in-the-middle attack. RFC 2617 recommends using Digest authentication instead of Basic authentication because it addresses some of its weaknesses. It also does not conceal that Digest authentication is still weak compared to modern cryptographic standards and its strength depends largely on its implementation.
So the summary of Digest authentication is:
- Does not send plaintext passwords over the network
- Prevents replay attacks
- Guards against message interception
Some weaknesses:
- Vulnerability to man-in-the-middle attack
- Many of the security options are not required and thus Digest authentication will function less securely if not set
- Prevents the use of strong password hashing algorithms when storing passwords
Because of these factors, Digest authentication hasn't gained much traction yet. Basic authentication is much simpler and more secure than Digest authentication, combined with SSL.
Conclusion
This conclusion is for this part of the HTTP series.
We went through the different authentication mechanisms that HTTP offers by default and talked about their advantages and disadvantages.
Hopefully, these concepts are no longer just letters on a screen for you, so you know what they are and when to apply them for the next time.
You're aware that there are security risks that aren't addressed with these mechanisms, and that's why concepts like HTTPS and SSL/TLS exist. We'll talk more about these security risks and how to address them in the next installment of our series.
If you find some of the concepts in this chapter unclear, see part 1, part 2, and part 3 of the HTTP series.
Next Lesson: HTTP Lessons – Lesson 5 – Security
References;
- HTTP Authentication: Basic and Digest Access Authentication RFC: https://www.ietf.org/rfc/rfc2617.txt
- HTTP: The Definitive Guide: http://shop.oreilly.com/product/9781565925090.do
- Man-in-the-middle attack: https://en.wikipedia.org/wiki/Man-in-the-middle_attack
- Base64 encoding: https://en.wikipedia.org/wiki/Base64
