Small words HTTP Authentication

What is authentication?

First explain two long, easy-to-confuse words,authentication (identification, authentication) , and Authorization (authorization).

authentication is to prove who you are. Give me a sample example. You tell people your name is Alice, how to convince others that you are Alice, this is authentication.

Authorization is when someone else already believes you are. You are not allowed to do sth. For example, when you have proved that you are Alice, you can check your own credit card record, but not Bob's card record, this is authorization (of course, assuming Alice is Bob's wife, except for the case ).

This blog will mainly look at the HTTP authentication what is going on.

Then there are two common authentication mechanisms: HTTP basic and Digest.

HTTP Basic

As the name implies, HTTP Basic refers to the simplest authentication protocol. What's a simple thing to do? The direct way tells the server your username (username) and password (password).

Here if our username is Alice,password is 123456.

We use Curl to access the server

Curl-u alice:123456 Http://kiwiserver.com/secret-v

Request Header:

Get/secret http/1.1
Authorization:basic QWXPY2U6MTIZNDU2
...

We see here that the sent request header contains the authentication field, which has a value of basic qwxpy2u6mtizndu2. Basic represents the use of HTTP Basic authentication. and QWXPY2U6MTIZNDU2. Is the result of the BASE64 encoding "alice:123456".

Response Head:

http/1.1 OK
...

Because we are entering the correct usernamepassword. So the server returns 200, indicating that the validation was successful. Suppose we use the wrong user's password to send the request, we get a similar example of the following response header with a 401 error:

http/1.1 401 Bad credentials
Www-authenticate:basic realm= "Spring Security Application"
...

At first glance it looks like HTTP basic is pretty good. QWXPY2U6MTIZNDU2 has made people very ugly out of what Usernamepassword is. However, we need to know that the BASE64 encoding is reversible. That is, we can restore username and password by decode Base64 's code.

At the command line, enter for example the following command:

echo QWXPY2U6MTIZNDU2 | Base64-d

Get:

alice:123456

Easy decryption. Imagine. Suppose a person intercepts a request that Alice sends to the server in a certain way, is it not very easy to get her username and password? Therefore, in order to ensure the security of users. We do not use Basic authentication directly in HTTP mode. Instead, it uses HTTPS, which is more secure.

Replay Attack

Through the previous introduction, we know that through the reversible Base64 encoding method is not too reliable. So before we send the password, will the password be encoded in an irreversible way?

Example. The password in front of Alice is 123456 and is MD5 encoded

Md5-s 123456

And what I get later is

e10adc3949ba59abbe56e057f20f883e

Is this not irreversible? Well. Even though a guy named Craig intercepted the Usernamepassword I sent to the server. He had no idea what my password was.

Indeed, Craig got e10adc3949ba59abbe56e057f20f883e , the MD5 hash password, who did not know what Alice's password was. However, suppose Craig is holding the string directly on the HTTP header. Send it to the server again, OK? Craig does not have to decrypt this password can also be installed as "Alice" to communicate with the server.

This is called Replay Attack.

HTTP Digest

In order to avoid being used by the bad guys replay Attack, a simple idea is. Each time we send the server the authentication information "must" is not the same, so that Craig even get this authentication information can not be replay attack. How does it make Alice every time the authentication information sent to the server is different. At the same time, you can let the server know that this is Alice?

This leads to the Digest authentication.

When Alice first visits the server, she does not carry password. At this point, the server tells Alice a randomly generated string (nonce). Alice then combines the string with her password123456 for MD5 encoding, sending the encoded results to the server as a validation message.

Because the nonce is "every time" (and not necessarily every time) randomly generated. So Alice visits the server at different times, and the nonce value used for the encoding should be different. Assuming that the same nonce code results are carried, the server finds it illegal. will be denied access to the interview. Such Even if Craig can intercept Alice's request to the server, there is no way to impersonate Alice with replay attack.

We can still use curl to see the process:

curl-u alice:123456 http://kiwiserver.com/secret-v--digest

Curl and server communication process

Curl--------request1:get------->> Server

Curl <<------response1:nonce-------Server

Curl----request2:digest Auth----> Server

Curl <<-------Response2:ok--------Server

request1 Header:
 get/secret http/1.1
  ....
No username and password information is included in Request 1

response1 header:
 http/1.1 401 full authentication are required to access this resource
  www-authenticate : Digest realm= "Contacts realm via Digest authentication", qop= "auth", nonce= " mtqwmtk3otkwmdkxmzo3mjdjndm2ntyzmtu2nta2nwezowu2nzblnzhmmjkwoa== "
  ...

After the server receives the REQUEST1. Feel Request1 no matter what the authentication information. So return 401, and tell curl that the value of the nonce is MTQWMTK3OTKWMDKXMZO3MJDJNDM2NTYZMTU2NTA2NWEZOWU2NZBLNZHMMJKWOA

REQUEST2 Head:
Get/secret http/1.1
Authorization:digest username= "Alice", realm= "Contacts realm via Digest authentication",nonce= " mtqwmtk3otkwmdkxmzo3mjdjndm2ntyzmtu2nta2nwezowu2nzblnzhmmjkwoa== ", uri="/secret ", cnonce=" MTQwMTk3 ", nc= 00000001, qop= "auth",response= "Fd5798940c32e51c128ecf88472151af"
...

After curl receives the nonce value of the server, it is able to put information such as password and nonce values together and then MD5 encode, to get a response value, as seen in the red mark above, This allows the server to verify that Alice's password is correct.

RESPONSE2 Head:

http/1.1 OK
...

When we are finished authentication, let's say we use the Nonce value again:

Curl-x GET Http://kiwisecrect.com/secret-H ' authorization:digest username= "Alice", realm= "Contacts realm via Digest Aut Hentication ", nonce=" mtqwmtk3otkwmdkxmzo3mjdjndm2ntyzmtu2nta2nwezowu2nzblnzhmmjkwoa== ", uri="/secret ", cnonce=" MTQwMTk3 ", nc=00000001, qop=" auth ", response=" Fd5798940c32e51c128ecf88472151af "'-V

Receive error message:

http/1.1 401 Incorrect response
Www-authenticate:digest realm= "Contacts realm via Digest authentication", qop= "auth", nonce= " mtqwmtk4mjg4mjq5njpjzmninzi2zmflnza4nzg3zduxnjk2yteymtu3otc0yg== "

Digest authentication is safer than basic, but not really afraid of anything. Digest authentication This easy way to get the man in the middle attack.

adjourned

Copyright notice: This article blog original articles, blogs, without consent, may not be reproduced.

Small words HTTP Authentication