Parsing mobile app logon from security and experience

There are two problems to be solved during app login: security and experience. They correspond to the user authentication during logon and the operation complexity during user logon.

1. User Authentication during logon. Common means include encrypted transmission of passwords, dynamic passwords, and verification codes.

1. password encryption.
Many mobile apps in the Internet industry are currently using the simplest method: generate a hash value based on the password and send the hash value to the server. The hash value of the user password in the server computing database is then compared with the hash value sent from the client. If the hash value is the same, the logon is successful.
If security requirements are higher, public key encryption is a common practice. The specific method is as follows. Before logon, request a public key from the server, encrypt a string of hash values generated based on the password with the public key, and then send them to the server. The server uses the private key for decryption, and then compares it with the hash value calculated based on the user password in the database. If the hash value is consistent, the login is successful. Of course, you can also optimize it by controlling the validity period of the public key to enhance security. For example, the Public Key fails for 10 seconds and can only be used once.
For public key encryption, refer to this article.Article: Http://www.360doc.com/content/11/0406/17/4146412_107621805.shtml

2. Dynamic Password.
The essence of dynamic passwords is to use another method to identify the uniqueness of user identities and perform user authentication with the user's static passwords. Specific common implementation methods, can refer to this article: http://baike.soso.com/v5973952.htm
Currently, the most common method suitable for apps on the market is to use mobile phone text messages for dynamic password authentication. That is, if an exception is found on the server during regular logon, you can send a text message containing a dynamic password to the user's mobile phone. The validity period of the user is generally 30 seconds to 1 minute) the user name, user password, and dynamic password are sent to the server for verification. For users, the Operation threshold is relatively low and convenient.

3. Verification code.
Once the server detects an exception in logon, such as IP address changes and too many logins in a short period of time, it will send an image to the app, the user submits the data required in the image together with the user name and password to the server.

To reduce the complexity of the user login process, generally, you only need to enter the user name and password. Verification Code and dynamic password are enabled only when the server detects exceptions.

2. Reduce the number of user inputs for automatic logon.
After the app is successfully logged on, the server will tell the app a session, which will be used for subsequent communication. However, for the sake of security, the validity period of the session is usually set, from 1 week to 20 days. Therefore, in order to prevent users from logging on again after the session becomes invalid, and reduce the number of times the user manually enters the user name and password, the concept of "Automatic Logon" is introduced.
The process is as follows:
After successful login, the server sends sesion to the app and an authentication token. The client uses the token as the application.ProgramPrivate data is stored. After a session expires, the token is sent to the server to obtain a new session. The entire process is transparent to users. For users, after a user name and password are entered, they will no longer log on.
Of course, the premise of this automatic logon is that the token security is much higher than the Session Security. We know that due to the security mechanism of the mobile OS, tokens are private data of applications and are invisible to other applications, ensuring the security of tokens. We can also apply another lock to bind the token to the device where the user uses the app. The available Binding data includes imsi and Mac. In this way, as long as the user's mobile phone is not lost, it will be okay.

No security mechanism is absolutely secure, in the actual application process, we need to use various methods such as application scenarios, specific business types, and user habits to balance security, user experience, and important costs in commercial applications.