Security Design of local storage passwords

Security Design of local storage passwords

Some applications need to save the User Password locally. This solution designs a safer Local Password Storage Solution.

1. Security Requirements

1.1 What to implement

1. attackers can obtain the plaintext of user passwords to prevent them from logging on to the server all the time after obtaining the automatic logon token. Even if the passwords of the two users are the same, the server can clear the salt on the server, to invalidate the user's Automatic Logon token, you must manually log on to the user to log on to the same account on multiple terminals. The automatic logon function of each terminal takes effect.
1.2 not implemented

1. the more secure solution can achieve "Copy locally saved files to other clients" Login will fail, which relies on the client for processing. This solution does not implement some solutions using RSA asymmetric encryption, this scheme uses AES symmetric encryption directly
2. Application Scenario Analysis

2.1 At registration

AesKey = client-side agreed-upon key ClientSalt = the client generates 8 characters at random (selected from 0-9A-Za-z) HashedPassword = SHA1 (plaintext password) EncryptedPassword = Base64 (AesEncrypt (ClientSalt + HashedPassword, AesKey )) note:

1. When registering, the client submits EncryptedPassword in the registration interface. The server uses AesKey to solve ClientSalt + HashedPassword. Because ClientSalt is fixed to 22 bytes, it can calculate the HashedPassword.
After successful registration, the user password saved on the server is SavedPassword. The generation method is as follows:

ServerSalt = 8 characters randomly generated by the server (from 0-9A-Za-z) SavedPassword = Base64 (AesEncrypt (ServerSalt + HashedPassword, server-specific key) Description:

1. With ServerSalt, the final EncryptedPassword will be different even if the passwords of the two users are the same. The user password is not stored in plaintext in the database.
2.2 manual Logon

Note:

1. The client submits the EncryptedPassword in the manual logon interface (the generation method is the same as that at 2.1 Registration)

2. Server verification process:

1) Use AesKey to calculate the HashedPassword from the client's EncryptedPassword

2) use the dedicated server key to extract the HashedPassword from the SavedPassword of the database.

3) compare two hashedpasswords

4) after the verification is successful, return the SaltExpire and autologire Ken to the client. The generation method is as follows:

Salt = random 8 characters (selected from 0-9A-Za-z) SaltExpire = The Last validity period of the Salt AutoLoginToken = Base64 (AesEncrypt (Salt + HashedPassword, server-specific key) 5) save the user ID, Salt, and SaltExpire in the Salt cache table

3. The client locally stores SaltExpire and AutoLoginToken, without saving the plaintext Password

4. The client cannot solve the HashedPassword because it does not know the server's Aes key.

 

2.3 Automatic Logon
 

1. The client first checks whether it has expired Based on the locally saved SaltExpire. If it has expired, You need to log on manually.

2. If it does not expire, the client submits the AutoLoginToken in the Automatic Logon interface.

3. Server verification process:

1) solve the Salt and HashedPassword from the autologtailken

2) check whether the Salt of the user ID has expired in the Salt cache table.

3) compare two hashedpasswords without expiration

4) when the verification is successful, create a new Salt, SaltExpire, and autologire Ken, and return the SaltExpire and autologire Ken to the client.

5) Save the user ID, new Salt, and SaltExpire in redis, and delete the old Salt.

4. The client updates the SaltExpire and AutoLoginToken of the local storage.

5. When a user needs to log on manually when a risk occurs, the user's SaltExpire can be cleared.

2.4 Automatic Logon Time for multiple terminals

When multiple terminals perform the 2.2 manual login process, multiple Salt/SaltExpire will be generated. A new Salt (the old Salt will be cleared) will be generated after a terminal automatically logs in ), but it does not affect the automatic login of another terminal, because the Salt is different.