How to ensure the security of sign signature on the client side (ios,android,web)

S = key + url_encode(path) + T
 SIGN = md5(S).to_lower()to_lower ;

When developing the

API interface, if you take into account the security of the interface and the non-serialization of the parameters, the usual practice is to send the sign value of the signature to the server after the parameter is signed by a certain algorithm, so that the server can judge whether the signature passed by the customer server matches after removing the sign parameter and signing all the parameters. This is solved

but there is a problem, the signature algorithm is basically the same, what can be done is to add a key value to the signature, but how to ensure the security of this key value on the client side. For example, if you put it on the web side, the js code can be seen directly, which is definitely not safe, and it doesn"t seem safe to put it on android, because apk can be decompiled.

have any friends ever solved this problem?

Algorithm sign golang php java

Apr.01,2021

adding these encryption can only make it more difficult to crack. There is no 100% security, even if you use RSA encryption. Just guard against most people.
if you think about it, people can guess your encryption algorithm through decompilation, but this can still be ordinary people? Such people generally can't resist

it is definitely not good to put symmetrically encrypted key on the client side. You can see that almost all open platforms do not recommend putting secret on the APP side.

you can consider the combination of symmetric encryption and asymmetric encryption:

1. The RSA public key is given to the APP side, and the private key is left on the server side

2. When the APP side submits the data, it only generates a random string in memory and uses it as the symmetrically encrypted key to encrypt the data; then the key is asymmetrically encrypted with the RSA public key, and the two are submitted to the server together

3. After receiving the data, the server first decrypts the key, with the private key and then decrypts the business data using key

the same is true of the data that the server gives to the client. Why not encrypt business data directly with RSA? It is mainly the problem of block efficiency.

first determine what sign does.

The main purpose of

sign is to ensure the integrity of the data and prevent the data from being tampered with in the process of network transmission.

name=kevin
height=170
key=$$key$$

if the above data signature string is name=kevin&height=170$$key$$ signature, the result is c5c05d54d25791b0551b25a482d8c2e2 . This key is visible on the client side, and others can easily get this parameter.
but what's the point of getting this key ?

because key will not be transmitted in the network, so the server will eventually generate the signature key will also use $$key$$ , even if you modify the data, also modify the client key but you did not modify the server key , and finally the server will generate sign in its own way. If you modify the data, in the end, the result of the signature is not consistent.

our practice uses JNI, in Android to store key in cPP and generate signatures. There is no need to hide in IOS, and the OC decompilation of IOS is extremely difficult.

I also want to know if there is a more secure and scientific approach

this usually adds a timestamp timestamp at the end, then encrypts it, and then decrypts it to the backend. The time stamp is valid if the difference between the timestamp and the current time is no more than 10 minutes (we default to 10 minutes, which you can set), otherwise it is invalid. In

api, you should not expose key and encryption methods to the client. You should use https + user token to access your backend interface

this key seems to be useless.

sign stores confidential information, such as the user's id or other parameters used to verify the validity of api. The request parameters of the
API are generally not placed in sign. Direct plaintext transmission can be encrypted with https communication process.
sign is encrypted by the server and passed to the client for storage. When requesting api, it is taken to the server to verify the validity of the identity. There is no request information for the interface. The two are to be separated

you don't need to go to so much trouble at all, just https

if the tampering in your question refers to the middleman tampering with the user's request, using https is enough. If you invent a set of https yourself, it will not be easier to use
if you mean that the user tampers with his own request to achieve the purpose of ultra vires operation, it means that there is something wrong with the permission test of the interface pair, and you should do a good permission test instead of a completely useless signature. When writing an interface, it is necessary to suspect with the greatest malice that all user input is correct.
generally speaking, tampering refers to the former, and the latter is not called tampering with data, but is called ultra vires attack

. < hr >

signature usually refers to the server-side signature, even if the client signature is a certificate for each person, there is no way to package the certificate into the client. The private key is public
google login password is plaintext transmission, and https is enough for friends who step on
. Read more books if you don't understand, don't step on J8 blindly, it will only make you look bad

Previous: IntelliJ IDEA error connecting to remote Weblogic server

Next: [JAVA rookie] ask the question about whether JAVA must have main method.