Roles of nonce and timestamp in Http Security Protocol

Some time ago, I made a Sina Weibo account logon function for the customer's website, and made some research on the OAuth Protocol and related security protocols. By the way, I will record my learning experience. Here, we do not want to talk about the OAuth Protocol process in detail, but for the nonce (random number), timestamp (timestamp), signatrue (Signature) in the OAuth request header) the functions of these parameters are summarized.

 

First, let's take a look at the Basic Authentication defined in the HTTP specification.

Basic authentication and security issues

Basic authentication is a simple 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 the 401 response code and WWW-Authentication: Basic realm = "Family" response header, which requires the client to perform Authentication. Realm declares the domain where the resource is located.

C) after the browser receives the above HTTP response header, the pop-up logon box asks the user to enter the user name and password; the user name and password submitted by the user are connected by a colon and BASE64 encoded before being submitted to the server. The server verifies the submitted BASE64 string, if the verification succeeds, the system returns the 200 response code.

 

 

 

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

1. the user name and password submitted by the client are only encoded. As long as the attacker eavesdroppers on the data packet, the user name and password can be easily reversed as the original user name and password.

2. Even if the client uses a more complex encoding method than BASE64, attackers cannot decomcode it, attackers can also use tools such as fiddler to re-submit the intercepted HTTP packets to the server. The server only verifies the encoded strings, so the verification can also pass. This Attack method is called a Replay Attack (Replay-Attack ).

The above two problems are also the security issues that need to be taken into account for various authentication protocols, including OAuth, Digest authentication, NTLM authentication, and other authentication mechanisms all use nonce and timestamp to solve these problems.

Nonce and Timestamp -- solve the Replay-Attack Problem

Nonce is a random number generated by the server. It is sent back to the client when the client first requests the page. The client obtains the Nonce, connect the encrypted string with the user password and perform non-reversible encryption (MD5, SHA1, etc.). Then, the encrypted string, user name, Nonce, and encryption algorithm name are sent back to the server together; the server uses the user name received to search for the password in the database, encrypts it with the same algorithm as the client, and then compares it with the encrypted string submitted by the client, if the two strings are consistent, the user identity is valid. In this way, the plaintext of the user's password is stolen. Even if Attackers know the algorithm name and nonce, they cannot decrypt the password.

 

Each nonce can only be used once by one user, so that attackers can prevent replay attacks because the Http message is invalid. The optional method is to save the Nonce of each request to the database. When the client submits the request again, it compares the Nonce in the request header with the data in the database. If the Nonce already exists, the request may be malicious. However, this solution also has a problem. It is very likely that the random numbers generated in two normal resource requests are the same, which leads to normal requests being attacked, this problem becomes obvious as the number of random numbers stored in the database increases. Therefore, you must add another Timestamp parameter ).

 

Timestamp is a string generated based on the current time of the server. It is put together with nonce to indicate the random number generated by the server at a certain time point. In this way, even if the generated random numbers are the same, but they are generated at different time points, they are also valid random numbers.

 

The problem arises again. As user access increases, the amount of nonce, timestamp, and username stored in the database will become very large. For this problem, an optional solution is to set an "expiration time" for the data. For example, data that has been stored in the database for more than one day will be cleared. In this case, the attacker can wait a day before submitting the intercepted HTTP packet to the server. At this time, the nonce/timestamp/username data has been cleared by the server, the request will be considered valid. To solve this problem, you need to set a timeout time for the timestamp. For example, compare the timestamp with the current time of the server. If the difference is one day, the timestamp is considered invalid.

Encryption of HTTP message bodies

Unfortunately, after the complex processing above, our data transmission is still insecure. We all know that http packets are transmitted in plaintext over the network, some authentication mechanisms, such as Basic authentication, Digest authentication, OAuth, and NTLM authentication, only protect the information of the HTTP header, but do not encrypt the data of the Http message body. Take logon on the Sina homepage as an example. Its account is sent in plaintext, as shown in:

 

 

 

This method is insecure. the user name and password are submitted in plain text. Sina Weibo, also the Sina website, was encrypted before login, as shown in:

 

 

 

 

For the encryption method, refer to the nonce + timestamp solution mentioned above. However, this only solves the login issue. During registration, nonce and timestamp cannot be submitted for non-reversible encryption. asymmetric encryption is required. When a user opens the registration page, the server generates a public/private key pair and returns the public key to the client. The client uses the public key to encrypt the password and then submits it to the server, the server uses the private key for decryption and then saves it to the database. The asymmetric encryption algorithm is characterized by a one-to-one correspondence between each public key and the private key. After public key encryption is used, only people with the private key can decrypt the data. Therefore, it is useless for attackers to intercept http packets.

Of course, if conditions permit, you can use SSL to Encrypt HTTP packets. This solution adds an SSL layer between the application layer and the transport layer, this layer uses symmetric encryption to Encrypt HTTP packets and then send them to the transport layer, as shown in:

 

 

 

Before that, the client and server need to use asymmetric encryption to negotiate the public key used for symmetric encryption. symmetric encryption requires that the encryptor and the decrypted have the same key (that is, the Public Key ). When the client accesses the page for the first time, it needs to generate a public key to the server, which cannot be known to a third party (the data can be decrypted once the Public Key is known ), therefore, the server must first generate a public key/key pair and use the generated public key to encrypt the Public Key (asymmetric encryption) generated by the client. This process is similar to the encryption method of the registration password mentioned above.

It is because several rounds of negotiation between the server and the client need to be performed before the formal data transmission, so HTTPS is more secure than HTTP, and the performance will be worse.