During normal development, when encountering information such as user's mobile phone number, name, ID card, etc., there are the following commonly used solutions in the transmission and storage nodes.
Front and backend transmission
AES Symmetric Encryption
The encryption and decryption keys of symmetric encryption are the same. Put the key in the front end and if it is cracked, there are certain risks and it is not recommended to use it.
RSA Asymmetric Encryption
Generate a pair of public and private keys in advance.
The front-end uses public key to encrypt. The public key is public. The back-end uses private key to decrypt. The private key should not be written in the code in the configuration center, as long as the back-end private key is not leaked, there is no problem.
RSA encryption and decryption speed is relatively slow, and data exceeding 10KB must be segmented, or hybrid encryption is used.
Hybrid encryption
When encrypting large files, using RSA alone is very inefficient, and you can use RSA + AES hybrid encryption method.
First of all, just like the RSA step, the front-end stores the public key and the back-end stores the private key.
Then the front end randomly generates the AES key, encrypts the AES key using RSA, and then encrypts the large file data with AES.
Then pass the encrypted AES key and encrypted large file data to the backend together.
The backend uses RSA to decrypt the AES key and then decrypt the data with the AES key.
I only use encrypted ID card, mobile phone number and other data, and use RSA asymmetric encryption.
Database encryption
Database encrypted storage should take into account query efficiency and the convenience of checking cases in daily life.
MD5 + Salt/SHA + Salt
For scenarios such as user's password, which does not require decryption, it can be encrypted using SHA + Salt.
Due to the rainbow table attack (exhaustrated before and after MD5 encryption, such as MD5 cracking on the website), MD5 is no longer so safe, especially when there is no salt added, it is no longer recommended.
AES Encryption
Taking mobile phone numbers as an example, after encrypting the mobile phone number, it is impossible to use the plain text query of the mobile phone number, and the added index is also ciphertext.
In the business, you will encounter scenarios where you query through mobile phone numbers or batch queries, such as determining whether the user has registered.
It is recommended to use AES encryption, and the key is equipped in the configuration center.
Encapsulate additional query interfaces, such as getByPhone.
import ;
import ;
import ;
import ;
import ;
@Service
public class UserServiceImpl extends ServiceImpl<UserMapper, User> {
private static final String SECRET_KEY = "your-encryption-key"; // Replace with your encryption key
/**
* Check individual user information based on plain text mobile number
*
* @param plainPhone
* @return Matching user information (the database ciphertext is decrypted and the plaintext mobile number information is carried)
*/
public User getByPhone(String plainPhone) {
// 1. Encrypt the plain text mobile phone number into a cipher text String encryptedPhone = encryptPhone(plainPhone);
// 2. Construct query conditions and match through ciphertext QueryWrapper<User> queryWrapper = new QueryWrapper<>();
("encrypted_phone", encryptedPhone);
// 3. Query and return the result User user = (queryWrapper);
// 4. Inject a plain text mobile phone number and pass it back so that the client knows the original mobile phone number if (user != null) {
(plainPhone); // Suppose there is this field in the entity class User }
return user;
}
/**
* Check the corresponding user information based on the plain text mobile number list
*
* @param plainPhones list of mobile phone numbers
* @return Matched user information list (the database ciphertext is decrypted and the plaintext mobile number information is carried)
*/
public List<User> listByPhoneIn(List<String> plainPhones) {
// 1. Encrypt the plain text mobile phone number list into a cipher text list List<String> encryptedPhones = ()
.map(this::encryptPhone) // Call the encryption method .collect(());
// 2. Construct query conditions and match through ciphertext list QueryWrapper<User> queryWrapper = new QueryWrapper<>();
("encrypted_phone", encryptedPhones);
// 3. Query and return the result List<User> users = (queryWrapper);
// 4. Bind the original plain text mobile phone number with the corresponding cipher text and inject it into the return result for (User user : users) {
// Find the plain text mobile phone number that matches the current ciphertext String plainPhone = ((()));
(plainPhone); // Suppose there is this field in the entity class User }
return users;
}
/**
* Methods to encrypt mobile phone number (symmetric encryption, AES)
*
* @param plainPhone
* @return Encrypted cipher text mobile number
*/
private String encryptPhone(String plainPhone) {
// The encryption logic is omitted here, and the corresponding AES encryption method can be implemented by yourself. // Suppose there is a tool class here calling AES encryption, and the example passes in key and data for encryption return (plainPhone, SECRET_KEY); // The example is pseudo-code, please use actual tools to implement it }
}
When querying a case, you can encrypt the query with database aes.
-- Query a specific mobile phone number SELECT * FROM users WHERE phone_encrypted = AES_ENCRYPT(plainPhone, SECRET_KEY);
Do not use MySQL AES to decrypt the query directly, as this will scan the entire table to decrypt and compare, and the database will wait for explosion.
For special scenarios such as mobile phone numbers, additional prefixes and suffixes can be stored according to the service, which facilitates scope query.
If there are higher requirements for encryption, you can set the version number on the front and back ends and when initing the library, and modify the RSA public and private keys and AES keys regularly.
The front-end obtains the public key through the interface, and the back-end stores the public and private keys in the database, attaching the version number and effective date.
When decrypting the backend, the corresponding private key is obtained based on the version passed in by the frontend.
When entering the database, the version number is also stored, and when decrypting, the version number is queried and then decrypted.
At present, I have not encountered such high requirements. I plan to use RSA encryption on the front and back end transmission and use AES encryption on the database, which is enough.
This is the end of this article about detailed explanation of sensitive information processing in Java. For more relevant Java sensitive information processing content, please search for my previous articles or continue browsing the related articles below. I hope everyone will support me in the future!