Analysis of HTTP Authentication Algorithm in Cloud Storage

Base64-coded HTTP Basic Authentication is no longer widely used due to security issues. In the cloud storage, the security of the data has been widely concerned. Amazon’s AWS S3 and OpenStack SWIFT have taken different algorithms to authenticate each HTTP request. Here is a simple analysis and summary of the authentication process of the two.

First, the HTTP request authentication process of AWS S3

The authentication algorithm taken by AWS is similar to HTTP basic certification. We know that Base64 is just a conversion storage for the string, which can reverse the source string, so the username and password used by the base64 encoded in basic authentication can be intercepted, once the username and password leak, hacker can be constructed Any requested request for data stealing and rewritten. AWS uses the idea of ??signature authentication to solve this problem, see the detailed process See: Link.


1. The client will make a string;

2. The HASH value is ultimately transmitted in the HTTP request. Where AccessKey (hereinafter referred to as AK) is transferred in a request;

3. After the server gets the request, first extract AK, then query the user’s SK when checking out the account in the database of the AK to the server;

4, the server extracts universal information from the request, with the SK obtained by the query, calculate a signature using the same signature calculation process, then compares the signature carried in the request, the two consistent, the request is legal request, authentication pass through. Otherwise returns 403 authentication failure.

If the entire HTTP request is intercepted, the hacker can get the authentication weight, but cannot be reversed to the SK of the user because SHA is an irreversible hash algorithm. Therefore, the worst case: You can repeatedly send the request (no parameters in the request) to the server, the attack range is limited. Assume that hacker wants to use this authentication weight for new requests, then modify the general information in the request, and the signature value has not changed, and final authentication cannot be passed.

So hacking can always use this authentication to send the request? NOTE, the AWS S3 will compare the difference between the time and the time of the request after the request, if the request is issued 15 minutes earlier than the server, it is considered to be illegal requests.

From the above process, AWS’s authentication algorithm is very good to solve key leakages and every request can get authentication.

Second, then look at the HTTP request authentication process based on Keystone OpenStack SWIFT

KeyStone is relatively simple, and the entire system provides global unique Keystone service. Before sending HTTP requests, first need to apply to KeyStone, the TOKEN’s validity period is specified by the KeyStone server. When you apply for token, you need to provide username and password to KeyStone. Here you can understand AK and SK in AWS, KeyStone authentication is issued to the client. The client must be carried after each time the HTTP request is sent each time, SWIFT will then get the token and username information, and it is also as effective as Keystone. Token is valid, continue to process the service, token is invalid, then return authentication failed. The specific process can be seen from the following sequence diagram:

There are some problems in such authentication processes:

1, compared to the authentication of AWS, this will cause more serious consequences, although Token has a validity period, but every time you need to apply, frequent applications may cause a key to leakage;

2. Each request requires Swift and KeyStone to make an interaction, and there may be problems.

In fact, OpenStack has happened to be a long-active bug that will occur, causing data to be destroyed. Of course, such architectures also have their advantages, KeyStone can share in multiple services, centralize authentication logic, to achieve service-level reuse, and AWS must resolve and generate signatures in each service, can only do modules or Code level reuse.