I don’t know how everyone thinks about interface security, but for products that provide services to the public network, this can be said to be fatal. So, how to design a more secure interface access policy?

1. Token and signature
   Generally, in the design process of client and server, most of them are divided into stateful and stateless interfaces. Generally, when a user is logged in, whether the user has permission or can request the interface is controlled by the token granted by the server after the user logs in successfully. But it does not mean that with the token, the request is safe, so what if the token is leaked? Can anyone call my service?
   Just like going to the bank to withdraw money, you need a bank card. But just because you accidentally lost your bank card, the person who finds it can take your bank card to the bank for business. They also need to verify your identity, and you also need to know your bank card PIN.
   Therefore, the token is only the credentials of the user authority and the session. In addition to the credentials of the session, we also need to verify the legitimacy of the request to prevent the loss of the client due to the leakage of the token.
   The signature digest calculation is used to verify the validity of the request. Students often confuse the two. It is safe to use tokens.

2. Signature calculation design
   The calculation of the signature digest is generally divided into the signature value and the signature key. The signature generation method is as follows:
   signature = Base64(HMAC-SHA256(LOWER(MD5(key)), StringToSign))
   copy code
   2.1 Design of Signature String
   When designing the signature string, we need to think about what kind of request headers we need to design for different attack strategies.
   Commonly used signature strings are designed as follows:
   StringToSign = Content-MD5 + “\n”

• CanonicalizedHeaders
  copy code
  The CanonicalizedHeaders construction method is as follows:

Headers prefixed with service, but not including service-signature, as follows

service-nonce: The client generates a 32-bit random string, which cannot be repeated for all clients within 5 minutes. If the platform replies with a repeated nonce, the client needs to re-request.
service-date: The time when the request is generated is more than 5 minutes away from the local time of the server, and the authentication fails.
service-session-id: Client session id, which is used for all request session IDs after this login.
service-client: Client information, including client type, client version, operating system, etc.

Header names are all lowercase, and there should be no spaces before and after the value
The name and value of the Header are separated by “:” to form a complete header
Sort headers lexicographically from small to large according to the character order of the header names
Each header is followed by a “\n”

StringToSign generation example
eB5eJF1ptWaXm4bijSPyxw==\n
service-client:ewogICAgImRhdGEiOiB7CiAgICAgICAgImNsaWVudFR5cGUiOiAieHh4IiwKICAgICAgICAiY2xpZW50VmVyc2lvbiI6ICIzLjAiCiAgICB9Cn0=\n
service-date:2022-07-22T14:43:07Z\n
service-nonce:d36e316282959a9ed4c89851497a717f\n
service-session-id: 0123456\n

2.3. Signature key design
Generally, there are three types of interfaces requested by the client, namely login status and no login status, and login as a special interface. The interfaces before the no-login state are all interfaces made by the service to provide capabilities. In contrast, they all provide general capabilities. No customer personal information is involved. Less security risk. The interface after the user logs in is generally an interface involving customer information, and the risk of privacy leakage is high. Therefore, different key value designs can be used for each state. Minimize risk.
2.3.1. User not logged in signature key value
When the user is not logged in, the platform provides general capabilities. When calling the server interface, the agreed fixed SK can be used for interface signature authentication. Fixed SK provided by the backend as a 16-bit random string.
2.3.2. User login signature key value
We know that all the key values ​​stored in the client and the front end are never the safest, and may be unpacked to find the corresponding encrypted SK, which will be cracked by criminals. Therefore, when the user logs in and transmits the password, if a fixed key is used , there is a risk that the body may be unlocked and the password leaked.
When logging in, the user will enter a password, and the server also knows the encrypted password of the user, so using the password entered by the user as the key is the safest way. And during the interaction process, there is no need to put the user password in the body and send it to the back-end for verification, just verify the accuracy of the signature. This can greatly increase the security of user passwords.
The user’s password will be entered during login verification, and then the user password will be used as the signature key for authentication verification during login. The encryption key is: SHA256(LOWER(MD5(passwd)),salt), salt is the user’s salt value, and the user’s mobile phone number can be used.

2.3.3. User login signature key value
After a user logs in successfully, all interfaces must be authenticated. For the security of each user, each user is issued their own SK, which is obtained after the login is successful. In this way, the client saves the sercet in memory, which can effectively prevent SK leakage.

1. After the user is successfully registered, a 16-bit sercet is generated for the user account in the background
2. After the user logs in successfully, the background returns the user’s sercet
3. The interface authentication after login uses sercet for authentication.
4. First, check whether the nonce of the request header of the interface is repeated within 5 minutes, which can effectively prevent replay attacks
5. Then verify the timestamp to prevent client time tampering attacks
6. After that, verify the MD5 of the request to prevent tampering with the request body.
7. Finally, perform combined signature verification on nonce, date, md5 and session to verify whether the signature value is successful. It can effectively prevent the problem that the above single modification verification passes, but the signature value verification fails.
8. Based on the above verification, most attack scenarios can be basically prevented. Of course, in order to be more secure, you can also add security designs to protect users’ property, such as black and white list restrictions, interface access current restrictions, user common device binding, and user remote login.
9. Well, I wonder if everyone in this article has a deeper understanding of security design? Do you have a better interface security design solution, you can chat together.