H5 web front end separation interface signature security-CodePudding

As is known to all, the APP is based on the interface to transmit data, because it is if I cannot get the source code, decompiled, so the APP client save a secret key, interface, and then call the background to the secret key and post field encryption as a sign to the background, the secret key does not pass,

Background according to the field of the APP and agreed upon before the secret key encryption, than signs are consistent, which guarantee the data consistency,

, so the question comes, in the h5 website source encryption methods are all visible and can be caught to tamper with, how to ensure data security, HTTPS can be solved, but the cost is expensive,

Others say put a token in the header, so is visible change, or each request dynamic background for the secret key signature scheme for reference to the APP, is also visible,

Conventional view are the background, only in a few pages with Ajax from the background data, output page is the background,

If h5 website as separation before and after the end, fully USES the APP interface signature, do you have any good Suggestions,,

CodePudding user response:

Use token, tampering with the useless, decrypt the validation is done on the server side, the key on the server side, has nothing to do with passing, token generally used only for authorized verification,
If it is passed to encrypt data, you can consider using symmetric encryption to encrypt data, using asymmetric encryption transmission of the symmetric encryption key,
The client with js dynamically generated a pair of keys, pass the client's public key to the server,
The server with the client public key encryption randomly generated symmetric encryption key, and pass the client, the server public key
Client with their own private key solutions for the symmetric encryption key, to encrypt data, and then use the server public key encryption random symmetric encryption key,
Server side with their own private key solutions for the symmetric encryption key, then work out data,
The above data can add asymmetrical way sign,

CodePudding user response:

reference 1st floor hookee response:

use token, tampering with the useless, decrypt the validation is done on the server side, the key on the server side, has nothing to do with passing, token generally used only for authorized verification,
If it is passed to encrypt data, you can consider using symmetric encryption to encrypt data, using asymmetric encryption transmission of the symmetric encryption key,
The client with js dynamically generated a pair of keys, pass the client's public key to the server,
The server with the client public key encryption randomly generated symmetric encryption key, and pass the client, the server public key
Client with their own private key solutions for the symmetric encryption key, to encrypt data, and then use the server public key encryption random symmetric encryption key,
Server side with their own private key solutions for the symmetric encryption key, then work out data,
The above data can add asymmetrical way sign,

Thank you for your reply,

After landing back to the client an encrypted token, every time the client a request token to carry, server decrypts the token or from the cache or database to find the token information, if no record is authorization failure, token changed useless, but if caught changed other transmission field, because the other fields, who was not involved in the signature, don't change the background can't perceive,

The second method USES symmetric encryption and asymmetric encryption, and increase the complexity of tampering with reference to this article https://blog.csdn.net/qq812858143/article/details/81035497

The first client to generate a client secret key, private key in the cache, and then request to the server, the server generates a server secret key, and returns the public key, the client with the server public key encryption

His client's public key and login information request to the server, the server according to the server private key to decrypt the data get login information and client public key, and the client public key encryption aes symmetric encryption key value is returned to the client,

Client again with his own private key to decrypt the client data, get the aes encryption key as well as other token value, then the signature,
Key is here, where the client private key exists, if it is in the cache or local storage is visible, you can steal the client private key, and then decrypt the server returns the value of the
If the interface is one-time verification is no problem, through interfaces are passed back and forth, there is no store, but the token each interface are used, the signature can't prevent the alteration,
So the individual thinks, this method is only suitable for a one-time authorization, or increase the difficulty of the alteration caught,

CodePudding user response:

Token ACTS as short-term password, if the password leaked, natural what protection is ineffective,

CodePudding user response:

reference qq_271648298 reply: 3/f

token ACTS as short-term password, if the password leaked, natural what protection is ineffective,

We now do is parameter signature + time limit, increase the difficulty of crack, signature parameters will change, the timestamp will have to follow the change, and the timestamp with backend sends the request of real time stamp, request it pass more than 1 second intervals, basic can't cracked, so manual for manual word absolutely done these actions, 1 SEC algorithm what doesn't matter, writing can be seen in js, no absolutely safe, as long as the targeted by bosses, pay treasure to also have to go to, we increase the difficulty of crack, as far as possible put these minnows filters out, bosses, does our system

CodePudding user response:

reference 4 floor qq_271648298 response:

Quote: reference qq_271648298 reply: 3/f

Token ACTS as short-term password, if the password leaked, natural what protection is ineffective,

We now do is parameter signature + time limit, increase the difficulty of crack, signature parameters will change, the timestamp will have to follow the change, and the timestamp with backend sends the request of real time stamp, request it pass more than 1 second intervals, basic can't cracked, so manual for manual word absolutely done these actions, 1 SEC algorithm what doesn't matter, writing can be seen in js, no absolutely safe, as long as the targeted by bosses, pay treasure to also have to go to, we increase the difficulty of crack, as far as possible put these minnows filters out, bosses, does our system

If concurrent up, how to consider these points

CodePudding user response:

If you want to use symmetric encryption, there will be no end to write before and after death do encrypted. The encryption key to request back end, back end give you key in the encryption

CodePudding user response:

The reply, please ignore the above, you must first solve the problem of what, what's your scene fear others see your data

CodePudding user response:

If you want to solve the data during transmission will not be modified or crack, you can only use HTTPS (which means that the third party to intercept). If you just don't think user analysis of data, you can dynamically obtain the key, but you said the other people all resolve to your source code, in fact, the key also useless.

CodePudding user response:

For Java JAX - the WS and JAX - the realization of the RS code has certification and safety part of the implementation.

CodePudding user response:

refer to the second floor Shinyung response:

Quote: refer to 1st floor hookee response:

Use token, tampering with the useless, decrypt the validation is done on the server side, the key on the server side, has nothing to do with passing, token generally used only for authorized verification,
If it is passed to encrypt data, you can consider using symmetric encryption to encrypt data, using asymmetric encryption transmission of the symmetric encryption key,
The client with js dynamically generated a pair of keys, pass the client's public key to the server,
The server with the client public key encryption randomly generated symmetric encryption key, and pass the client, the server public key
Client with their own private key solutions for the symmetric encryption key, to encrypt data, and then use the server public key encryption random symmetric encryption key,
Server side with their own private key solutions for the symmetric encryption key, then work out data,
The above data can add asymmetrical way sign,

Thank you for your reply,

After landing back to the client an encrypted token, every time the client a request token to carry, server decrypts the token or from the cache or database to find the token information, if no record is authorization failure, token changed useless, but if caught changed other transmission field, because the other fields, who was not involved in the signature, don't change the background can't perceive,

The second method USES symmetric encryption and asymmetric encryption, and increase the complexity of tampering with reference to this article https://blog.csdn.net/qq812858143/article/details/81035497

The first client to generate a client secret key, private key in the cache, and then request to the server, the server generates a server secret key, and returns the public key, the client with the server public key encryption

His client's public key and login information request to the server, the server according to the server private key to decrypt the data get login information and client public key, and the client public key encryption aes symmetric encryption key value is returned to the client,

Client again with his own private key to decrypt the client data, get the aes encryption key as well as other token value, then the signature,
Key is here, where the client private key exists, if it is in the cache or local storage is visible, you can steal the client private key, and then decrypt the server returns the value of the
If the interface is one-time verification is no problem, through interfaces are passed back and forth, there is no store, but the token each interface are used, the signature can't prevent the alteration,
So the individual thinks, this method is only suitable for a one-time authorization, or increase the difficulty of the alteration caught,

The recently concluded also in thinking about this, then you said, the client access to aes encryption key is identified through the background after security (transfer process are obtained by the), you said aes key in the client cache will be seen, I think that it doesn't matter, see also login the user see, if the user is a malicious person, what also can change data in its own session, he won't change others, tampering with their own data can bring what benefit? Put in the sessionStorage best aes key, only in this session,
But that won't prevent his simulated packet to send,