The role of nonce and timestamp in HTTP security protocol

Some time ago to the customer site to do Sina Weibo account login function, the OAuth protocol and some related security protocols to do some research, the way to record the learning experience it. This is not intended to specifically address the OAuth protocol process, but rather to summarize the functions of the nonce (random number), timestamp (timestamp), Signatrue (signature) in the OAuth request.

First look at the Basic authentication defined in the HTTP specification.

Basic authentication and its security issues

Basic certification is a simple process protocol, the entire process can be divided into the following three steps:

A) The client uses the Get method to request resources from the server.

b) The server returns a 401 response code and the Www-authentication:basic realm= "Family" response header requires the client to authenticate. Where realm declares the domain in which the resource resides.

c) After the browser receives the above HTTP response header, the popup login box asks the user to enter a user name and password, and the user's user name and password are concatenated with a colon and BASE64 encoded before committing to the server, and the server validates the BASE64 string that is submitted. Returns a 200 response code if validation is passed.

Basic certification is simple and convenient, but it can only be used as a non-sensitive resource access authentication, because it is not secure, mainly in the following aspects:

1. The user name and password submitted by the client are simply encoded, and the attacker can easily encode the packet to the original user name and password as long as it is tapped.

2. Even if the client uses a more complex encoding than BASE64, which prevents an attacker from deserializing it, the attacker can use tools such as Fiddler to re-submit the intercepted HTTP message to the server, which validates the encoded string only, so the validation can pass. This attack method is called replay attack (Replay-attack).

The above two issues are also security issues to be considered in various authentication protocols, including OAuth, Digest authentication, NTLM authentication, and so on, using nonce and timestamp to solve these problems.

Nonce, timestamp--solve replay-attack problem

A nonce is a random number generated by the server that is sent back to the client the first time the client requests the page, and the client gets the nonce, concatenates it with the user's password and makes non-reversible encryption (MD5, SHA1, and so on), and then converts the encrypted string and user name, Nonce, The encryption algorithm name is sent back to the server, the server uses the received user name to the database to search for the password, and then encrypts it with the client using the same algorithm, and then compares it with the encrypted string submitted by the client, if the two strings are consistent, indicating that the user identity is valid. This solves the problem that the user password plaintext is stolen, even if the attacker knows the algorithm name and nonce can not decrypt the password.

Each nonce can be used only once for one user, which prevents an attacker from using replay attacks because the HTTP message is invalid. The optional implementation is to save the nonce of each request to the database, and the client submits the request again to compare the nonce in the request header with the data in the database, and if the nonce already exists, proves that the request could be malicious. However, this solution also has a problem, it is likely that in two normal resource requests, the resulting random number is the same, so that the normal request is also considered an attack, as the number of random data stored in the database is increasing, the problem becomes obvious. Therefore, you need to add another parameter, timestamp (timestamp).

Timestamp is a string generated based on the current time of the server, which, together with the nonce, can represent a random number generated by the server at a point in time. This allows for the same random number generated, but because they generate different points of time, they are also counted as valid random numbers.

Again, as user access increases, the amount of nonce/timestamp/username data stored in the database becomes very large. For this problem, the optional solution is to set an "Expiration Time" for the data, such as storing data for more than one day in the database will be erased. If so, the attacker could wait a day before committing the intercepted HTTP message to the server, and the request would be considered valid because the Nonce/timestamp/username data had been purged by the server. To solve this problem, you need to set a time-stamp timeout, such as comparing the timestamp to the current time of the server, and if the time difference is considered invalid for one day.

Encryption of the HTTP message body

Unfortunately, after these complex processing, our data transmission is still unsafe. We all know that HTTP messages are transmitted in clear text in the network, including Basic authentication, Digest authentication, OAuth, NTLM, and so on, authentication mechanisms are only to protect the HTTP header information, and the HTTP message body data is not encrypted. In the case of Sina homepage login, its account is transmitted in clear text, as shown in:

Such a way is very insecure, the user name and password are completely in the clear way submitted. Sina Weibo, the same Sina website, was encrypted before it was signed in, as shown in:

The encryption method can refer to the Nonce+timestamp scenario mentioned earlier. However, this only solves the problem of login, can not be submitted at the time of registration using nonce and timestamp non-reversible encryption, this time to use asymmetric encryption. When the user opens the registration page, the server generates a public/private key pair and returns the public key to the client, which the client uses to encrypt the password and submit it to the server, which is decrypted and then saved to the database by using the private key. Asymmetric encryption algorithm is characterized by each public and private key is one by one corresponding to the use of public key encryption, only the person with the private key to decrypt, so the attacker intercepts the HTTP message is useless.

Of course, you can use SSL to encrypt HTTP messages when conditions permit, which is to add an SSL layer between the application layer and the transport layer, which encrypts the HTTP message and then passes it to the transport layer using a symmetric encryption method, as shown in:

Until then, the client and the server need to use asymmetric encryption to negotiate the public key for symmetric encryption, which requires the encryption and decryption to have the same key (that is, the public key). When the client first accesses the page, it needs to generate a public key to the server, and the public key is not to be known to the third party (the public key can be decrypted), so the server needs to generate a public key/key pair, and use the generated public key to encrypt the client generated public key (asymmetric encryption), This process is similar to the one previously mentioned in the password encryption method.

Because of the need for a few rounds of negotiation between the server and the client before the official data transfer, HTTPS is more secure and less performance than HTTP.

Transferred from: http://www.cnblogs.com/bestzrz/archive/2011/09/03/2164620.html

The role of nonce and timestamp in HTTP security protocol