Introduction and implementation of authentication based on HTTP protocol

Introduction

has been interested in HTTP header authentication, that is, the type of the router popup dialog input account password How to realize has not understood, recently, turned over the HTTP protocol, found that this is an implementation of RFC 2617, so write an article about it.

HTTP Basic Authentication

This is a login authentication for a Web browser or other client that provides a user name and password when requested, and it is easy to implement this authentication:

Let's start by looking at how the protocol defines this authentication. 1. Encoding: Appends the username with a colon (': ') to the password, and the resulting string is encoded using the BASE64 algorithm.

1. Request Header: Authorization: Authentication type encoded string

Take a look at how the client initiates the request for example, there is a user named: Tom, the password is: 123456 How to certify it?

The steps are as follows 1. Coding

Base64 (' tom:123456 ') = = dg9tojeymzq1ng==;

1. Put the coding results in the request header

   Authorization:basic dg9tojeymzq1ng==

Request Sample Client

123	/http/1.1localhostBasic dg9tojeymzq1ng

Service-side response

1234	$ OKThu, June 20:25:37 GMTApplication/json; charset=utf-8

If there is no authentication information

123	401 Authorization RequiredThu, June 20:25:37 GMTBasic realm= "Users"

When the validation fails, the response header plus www-authenticate:basic realm= "request Domain".

This HTTP basic implementation is supported by almost all browsers. However, it can be found that directly the user name and password only once Base64 encoding is actually very insecure, because the Base64 is very easy to de-encode, so this verification, although simple, But rarely in public access to the Internet use, generally used in small private systems, such as the head of your home routers, multi-use this authentication method.

Http Digest Authentication

This certification can be seen as an enhanced version of the basic certification, using random numbers + passwords to MD5, to prevent the direct analysis of password MD5 to prevent cracking. Digest access authentication is initially defined by the RFC 2069 (an extension of http: Digest access authentication) that is the encryption step:

Later found, even if this is still unsafe (MD5 can be used to attack with a rainbow table), so in RFC 2617 into a series of security enhanced options, "Quality of Protection" (QOP), the number of random counters by the client, and the customer generated random number. These enhancements are designed to prevent password parsing such as selecting plaintext attacks.

1. If the Qop value is "auth" or unspecified, then the HA2 is

2. If the Qop value is "Auth-int", then the HA2 is

3. If the Qop value is "auth" or "auth-int", then the response is calculated as follows:

4. If Qop is not specified, then the following calculation is response:

Well, know the encryption step, below we use text to describe;

Finally, our response is calculated from three steps. 1. Computes the MD5 hash for the combined value of the user name, authentication domain (realm), and password, and the result is called HA1.

HA1 = MD5 ("tom:hi!:123456") = d8ae91c6c50fabdac442ef8d6a68ae8c

1. The combined value of the HTTP method and the digest of the URI computes the MD5 hash value, for example, "GET" and "/index.html", and the result is called HA2.

   HA2 = MD5 ("get:/") = 71998c64aea37ae77020c49c00f73fa8

2. The last generated response code

   Response = MD5 ("d8ae91c6c50fabdac442ef8d6a68ae8c:l4qfzasytyqjac2b1lvy2llppj9r8jd3:00000001:c2dc5b32ad69187a
   : auth:71998c64aea37ae77020c49c00f73fa8 ") = 2f22e6d56dabb168702b8bb2d4e72453;

The main ways to RFC2617 security enhancements are:

When the request is initiated, the server generates a random number (nonce) (the random number is only updated each time "401" corresponds), in order to prevent the attacker from simply using the same authentication information to initiate the old request, so in subsequent requests there is a random number counter (cnonce), And each request must be used before the hit. This way, each time a new random number is generated by the server, it is recorded and the counter is incremented. In response code we can see that the value of the counter results in a different value, so that any wrong requests can be rejected.

Request sample (server-side Qop set to "auth")

No client Authentication

12	/http/1.1localhost

Server response (Qop is ' auth ')

123	401 Authorization RequiredThu, June 20:25:37 GMTDigest realm= "hi!", nonce= " Hsfb5dy15hkejxabz2vxjvbgnc8sc1gq ", qop=" auth "

Client request (Username: "Tom", Password "123456")

123456789

get/http/1.1host:localhostauthorization:digest username="Tom", realm="hi!", nonce= "L4qfzasytyqjac2b1lvy2llppj9r8jd3", uri="/", Qop=auth, nc=00000001, cnonce="c2dc5b32ad69187a", response="2f22e6d56dabb168702b8bb2d4e72453"

Service-side response

1234	$ OKThu, June 20:25:37 GMTApplication/json; charset=utf-8

Note The Qop settings are used with caution: Auth-int, because some popular browsers and services do not implement this protocol.

Introduction and implementation of authentication based on HTTP protocol