Interface security

  • Is the request for identity legal?
  • Have request parameters been tampered with?
  • Is the request unique?

AccessKey&SecretKey (open platform)

The request status

Assign developers an AccessKey (developer identity, to ensure that it is unique) and a SecretKey (for interface encryption, to ensure that it is not exhaustive and that the generated algorithm is not easy to guess).

To prevent tampering

Parameters of the signature

  • Non-empty request parameters (including AccessKey) are arranged alphabetically in ascending order of request parameter names, using the format of URL key-value pairs (that is, key1= Value1 & Key2 =value2…) Concatenated to string stringA;
  • Secretkey on stringA final concatenation yields string stringSignTemp;
  • An MD5 operation is performed on stringSignTemp and all characters of the resulting string are converted to uppercase to obtain the value sign.

The request carries the AccessKey and Sign parameters. Only a valid AccessKey and a correct signature Sign can permit the request. This solves the authentication and parameter tampering problems. Even if the request parameters are hijacked, legitimate requests cannot be forged because the SecretKey cannot be obtained (used only for local encryption, not for network transmission).

Replay attack

Although the hidden danger of request parameters being tampered is solved, the hidden danger of request parameters being used repeatedly to forge a second request still exists.

Timestamp + nonce

A nonce is a unique random string that identifies each signed request. By providing a unique identifier for each request, the server can prevent the request from being used more than once (logging all used Nonce to prevent them from being used twice).

However, the cost to the server of permanently storing all received Nonce is very high. You can use TIMESTAMP to optimize the storage of nonce.

Assume that the time difference between the client and server can exist at most 15 minutes, and the nonce collection recorded on the server can be traced simultaneously. When a new request is entered, first check whether the timestamp carried is within 15 minutes, and reject it if it is beyond the time range. Then query the nonce carried, and reject it if there is an existing set. Otherwise, record the nonce and delete the nonce in the collection with a timestamp greater than 15 minutes (you can use Redis expire to add nonce and set its expiration time to 15 minutes).

implementation

Request interface: api.test.com/test?name=h…

The client

  • Generate current timestamp=now and unique random string nonce=random
  • StringA =”AccessKey=access&home=world&name=hello&work= Java ×tamp=now&nonce=random”; stringA=”AccessKey=access&home=world&name=hello&work= Java ×tamp=now&nonce=random”;
  • SecretKeystringSignTemp=”AccessKey= Access&HOME = World&Name =hello&work= Java ×tamp= now&Nonce =random&SecretKey=secret”;
  • MD5 and convert toUpperCase sign=MD5(stringSignTemp).touppercase ();
  • Final request api.test.com/test?name=h… ;

The service side

Token&AppKey (APP)

In the design of the APP open API interface, since most interface involves the user’s personal information and sensitive data, should to the authentication of these interfaces, so to be on the safe side exposing the user number of plaintext password as little as possible, however, the client and server interaction between requests are stateless, that is, when it comes to the state of the user, Bring authentication information with each request.

Token Authentication

  • After a user logs in, the user provides authentication information (such as the account and password) to the server. After the authentication succeeds, the server returns the Token to the client.
  • The client saves the Token locally and carries the Token in subsequent requests.
  • The server checks the validity of the Token, releases it if it is valid, and rejects it if it is invalid (the Token is incorrect or expired).
  • Security risks: Token hijacking, forged requests and tampering with parameters.

Token+AppKey signature verification

Similar to the verification method of the above development platform, AppKey is assigned to the client (the key is used for interface encryption and does not participate in transmission), AppKey and all request parameters are combined into a source string, signature values are generated according to the signature algorithm, and the signature values are sent to the server for verification when the request is sent.

This way, even if the Token is hijacked, the other party does not know the AppKey and signature algorithm and cannot forge the request and tamper with the parameters. Combined with the retransmission attack solution described above, it is impossible to forge a second repeat request even if the request parameters are hijacked.

implementation

Login and exit requests

Log in and log out process

Subsequent requests

The client

  • Similar to the open platform client behavior, change the AccessKey to a token.

The service side

Server-side process