In the past, I was responsible for the user management module of the project. In order to ensure the security of user data, the module involved a variety of data encryption algorithms
Writing in the front
Before introducing specific schemes, we first introduce common encryption algorithms. Encryption algorithms can be divided into three broad categories:
- Symmetric encryption algorithm
- Asymmetric encryption algorithm
- The Hash algorithm
Symmetric encryption algorithm
Encryption and decryption use the same key. Symmetric encryption algorithm Provides high encryption and decryption speed but poor security. Common symmetric encryption algorithms include DES, 3DES, DESX, Blowfish, IDEA, RC4, RC5, RC6 and AES
Asymmetric encryption algorithm
Encryption and decryption use different keys, also known as public-private key encryption. The disadvantage of asymmetric encryption is that the encryption and decryption speed is much slower than symmetric encryption, in some extreme cases, up to 1000 times slower than asymmetric encryption. Common asymmetric encryption algorithms with higher security than symmetric encryption algorithms: RSA, ECC (for mobile devices), Diffie-Hellman, El Gamal, DSA (for digital signature)
The Hash algorithm
The Hash algorithm is unique in that it is a one-way algorithm. Users can use the Hash algorithm to generate a unique Hash value of a specific length for the target information, but cannot use the Hash value to retrieve the target information. Hash algorithm Common Hash algorithms, such as MD2, MD4, MD5, HAVAL, SHA, SHA-1, HMAC, HMAC-MD5, and HMAC-SHA1, are used for irrecoverable password storage and information integrity verification
The user management module needs to be encrypted
In the user management module, any place involving password needs to be encrypted
Activating the admin Account
The platform contains an admin account by default. The admin account requires an activation password when it is used for the first time. The password transferred from the front end to the back end must be encrypted when the activation interface is invoked
The user login
Only after the activation is complete, the admin account can log in. If the login interface is invoked, the password is not encrypted and transmitted in plain text, which may be used by criminals, resulting in data leakage and other security problems
The user to create
When creating a common user with the admin account, you need to set an initial password for the common user. Therefore, data transmitted from the front-end to the back-end must be encrypted when invoking the user creation interface
Modifying User Information
The password can be changed when the user information is modified. Therefore, the data transmitted from the front-end to the back-end needs to be encrypted when the interface for modifying user information is invoked
Data warehousing
When the admin account is created for a common user, an initial password is set for the common user. This data is saved in the database, and the password used for activating the admin account is also saved in the database. The database is not a coffer and may be attacked, which may lead to user data theft. Therefore, the data with high security level in the database is encrypted. It is obvious that the user’s password needs to be encrypted before entering the database
How to select an encryption algorithm to implement encryption
Activating the Admin Account
The admin account must decrypt the password, so it can only be used in symmetric and asymmetric encryption algorithms. Therefore, the RSA encryption algorithm and AES128 encryption algorithm are used to activate the admin account, and the public and private keys are managed on the Web side. The steps are as follows:
- The Web sends the public key generated by the BASE64 encoded RSA encryption algorithm
- Server Base64 decoding public key
- The server generates a random 16-bit string
- The server uses the public key to encrypt the generated random string
- The server encodes the encrypted random string in Base64 and sends it to the Web server
- Web base64 decodes random strings
- The Web side decodes the base64 character string using the private key
- On the Web side, the password is concatenated into a new string. The new string is a random string plus the password
- The Web end encrypts the random string as the password of the AES algorithm and sends the password to the server end
- The server decrypts the new string using random strings
- The server parses the decrypted string to verify whether the random string is consistent
- The server parses the password in the string and encrypts the password into the database
Note: The key for data entry encryption is different from that for random string encryption. The sequence diagram is as follows:
The server side manages the public key and private key, the Web side obtains the public key and encrypts the password to the server side, and the server side uses the private key to decrypt the password, so there is no problem
A man-in-the-middle attack (MITM) is when an attacker creates an independent connection with two ends of a communication and exchanges the data they receive so that the two ends think they are talking directly to each other over a private connection. But in fact the entire session is completely controlled by the attacker. In a man-in-the-middle attack, an attacker can intercept a conversation and insert new content. A man-in-the-middle attack is a (lack of) mutual authentication attack. Most encryption protocols incorporate special authentication methods to prevent man-in-the-middle attacks. For example, SSL can verify that the certificates used by one or both parties involved in communication are issued by an authoritative trusted digital certificate authority and can perform a bidirectional authentication man-in-the-middle attack as follows:
- The client sends a request to the server and the request is intercepted by an intermediary
- The server sends the public key to the client
- The middleman intercepts the public key and keeps it for himself. Then generate a fake public key and send it to the client
- After receiving the forged public key, the client generates an encrypted hash value and sends it to the server
- The middleman gets the encrypted hash value and decrypts the real secret key with his own private key. Generates a fake encrypted hash value and sends it to the server
- The server decrypts the private key to obtain the fake key. The encrypted data is then transmitted to the client
The user login
The user login verifies the password without decryption, so the user login selects THE MD5 encryption algorithm of the Hash algorithm. Although MD5 can be cracked, only the MD5 encryption algorithm can be used for interconnection with other departments. The detailed steps are as follows:
- Front-end MD5 encryption password
- The server queries the password of the specified user
- Decrypt the database query password with the private key
- The decrypted password is encrypted by MD5 and compared with the incoming password
The sequence diagram is as follows:
User creation & User information modification
Use the AES128 encryption algorithm, and activate using the same public key
Data warehousing
The AES128 encryption algorithm is used, and the public key used for activation is different
Note: the above process omitted part of the business logic, such as password format verification, this paper mainly introduces the encryption and decryption to grasp the key
summary
HTTPS can solve the above user data encryption problem, but it will cost a lot of money. It is the first time to contact user data encryption in the project, and there may still be some shortcomings that need to be improved. If there is any mistake, please point out that I have not written an article for half a year, and I feel that I am not familiar with my writing style. Give me a thumb-up to support it
