Shulou(Shulou.com)06/01 Report--

Introduction

Has been interested in http head authentication, that is, the router's pop-up dialog box input account password has not been understood, recently, looked through the http protocol, found that this is an implementation of RFC 2617, so write an article to introduce it.

Http basic Certification

This is a login authentication used by web browsers or other clients to provide a user name and password upon request, which is simple to achieve:

Let's first take a look at how this authentication is defined in the agreement. 1. Encoding: append the user name with a colon (':') with the password, and encode the resulting string with the Base64 algorithm.

Request header: Authorization: authentication type encoding string

Let's take a look at how the client initiates a request, for example, if there is a user name: tom, and a password: 123456, how can I authenticate?

The steps are as follows. Coding

Base64 ('tom:123456') = = dG9tOjEyMzQ1Ng==

Put the coding result in the request header

Authorization: Basic dG9tOjEyMzQ1Ng==

Request sample client

GET / HTTP/1.1Host: localhostAuthorization: Basic dG9tOjEyMzQ1Ng

Server reply

HTTP/1.1 200 OKDate: Thu, 13 Jun 2013 20:25:37 GMTContent-Type: application/json; charset=utf-8Content-Length: 53

If there is no authentication information

HTTP/1.1 401 Authorization RequiredDate: Thu, 13 Jun 2013 20:25:37 GMTWWW-Authenticate: Basic realm= "Users"

When validation fails, add WWW-Authenticate: Basic realm= "request domain" in the response header.

This http is basically implemented and is supported by almost all browsers at present. However, you can find that it is actually not safe to encode the user name and password only once in base64, because it is very easy to reverse the base64, so this kind of authentication is simple, but it is rarely used on the Internet where public access is available. It is generally used in small private systems, such as routers in your home.

Http Digest Certification

This authentication can be seen as an enhanced version of the basic authentication, using random numbers + passwords for md5 to prevent cracking by directly analyzing the password MD5. Summary access authentication was originally defined by RFC 2069 (an extension of HTTP: summary access authentication):

Later, it turns out that even this is not safe (md5 can use rainbow tables for *), so a series of security enhancement options have been included in RFC 2617; "quality of protection" (qop), random number counters increased by the client, and customer-generated random numbers. These enhancements are designed to prevent cryptanalysis such as selecting plaintext.

If the qop value is "auth" or is not specified, then HA2 is

If the qop value is "auth-int", then HA2 is

If the qop value is "auth" or "auth-int", the response is calculated as follows:

If qop is not specified, the response is calculated as follows:

All right, we know the encryption steps, so let's describe it in words.

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

HA1 = MD5 ("tomVera Hibiscus d8ae91c6c50fabdac442ef8d6a68ae8c 123456") =

The MD5 hash values, such as "GET" and "/ index.html", are calculated for the combined values of the HTTP method and the URI summary, and the result is called HA2.

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

The final generated response code

Response = MD5 ("d8ae91c6c50fabdac442ef8d6a68ae8c:L4qfzASytyQJAC2B1Lvy2llPpj9R8Jd3:00000001:c2dc5b32ad69187a

: auth:71998c64aea37ae77020c49c00f73fa8 ") = 2f22e6d56dabb168702b8bb2d4e72453

The main ways to enhance the security of RFC2617 are:

When initiating a request, the server will generate a password random number (nonce) (which will only be updated after each "401"). In order to prevent the user from simply using the same authentication information to initiate the old request, there is a random number counter (cnonce) in the subsequent request, and each request must be called before. In this way, each time the server generates a new random number, it will be recorded and the counter will increase. In the RESPONSE code, we can see that the value of the counter results in different values, so that any wrong request can be rejected.

Sample request (server qop is set to "auth")

Client does not have authentication

GET / HTTP/1.1Host: localhost

Server response (qop is' auth')

HTTP/1.1 401 Authorization RequiredDate: Thu, 13 Jun 2013 20:25:37 GMTWWW-Authenticate: Digest realm= "Hi!", nonce= "HSfb5dy15hKejXAbZ2VXjVbgNC8sC1Gq", qop= "auth"

Client request (username: tom, password "123456")

GET / HTTP/1.1Host: localhostAuthorization: Digest username= "tom", realm= "Hi!", nonce= "L4qfzASytyQJAC2B1Lvy2llPpj9R8Jd3", uri= "/", qop=auth, nc=00000001, cnonce= "c2dc5b32ad69187a", response= "2f22e6d56dabb168702b8bb2d4e72453"

Server reply

HTTP/1.1 200 OKDate: Thu, 13 Jun 2013 20:25:37 GMTContent-Type: application/json; charset=utf-8Content-Length: 53

Be careful when setting qop: auth-int, because some common browsers and servers do not implement this protocol.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.