Method for managing passwords in centralized mode and then killing passwords in internet application

Abstract

The invention aims to solve the problem that the password used by a person is too many at present. Firstly, a scheme for managing all passwords in a centralized mode without passwords is provided for an individual user. Different from an existing scheme, a'local 'concept is introduced and is combined with human body biological feature recognition for use, the contradiction between safety and convenience of password centralized management is solved, and the highest level allowed by the prior art is achieved in the two aspects. Wherein the security is all-around, not only is the reliability of user identity authentication achieved, but also the strict requirement that implementation personnel cannot obtain confidential information of the user is met, and it is ensured that the user can reconstruct the local machine after the terminal equipment used as the local machine is lost / damaged; it continues to manage its personal confidential information in a highly secure and highly convenient manner. The user identity authentication service in the scheme can be shared by other internet applications, and has the advantages of replacing passwords, eliminating risks generated due to the fact that the internet applications respectively collect the biological characteristic information of the user and the like.

Description

Technical Field

[0001] The present invention belongs to the field of mobile Internet application technology, and in particular to the combined use of user-set security questions and answers and human biometric identification technology to simultaneously improve the security of password management and the convenience of use, and provide a shared user identity authentication method that can replace passwords for various Internet applications. Background Art

[0002] With the development of the Internet, the average number of passwords used by individual users is increasing, which is becoming more and more inconvenient, and the risk of leakage is also increasing. It is a consensus in the IT industry that this problem needs to be solved urgently. There are not only solutions launched by major manufacturers in the world, but also independent solutions such as FIDO (Fast Identity Online) that are specifically designed to eliminate passwords. In this regard, human biometric (face, iris, or fingerprint) recognition technology has matured and is increasingly used in Internet user identity authentication together with methods such as mobile phone verification codes; in some applications, it is to replace passwords, and in some applications, it is a second or third authentication factor added to passwords to enhance the reliability of identity authentication. In such a technical background, there are still the following problems: First, the goal of eliminating passwords is far from being achieved, and for many people it is not even closer to this goal than in the past; second, it is very difficult and troublesome to restore Internet services that rely on mobile phone authentication when the mobile phone is lost; third, too many types of Internet services collect and use user personal information including human biometrics, which increases the risk of illegal use of user personal information. The present invention takes helping individual users to centrally manage their various passwords as a starting point and proposes a set of solutions to these three problems at the same time. Summary of the invention

[0003] The solution of the present invention needs to be implemented in the form of a mobile Internet application with a C / S architecture, including a mobile terminal (mobile phone or tablet) APP and a cloud server, and requires the mobile terminal device to have hardware configuration for human biometric recognition such as fingerprint, face, or iris (such as most current models of smart phones). This application and APP are referred to as "this application" and "this APP" respectively in the following.

[0004] The first basic function of this APP is to allow users to centrally store their various passwords (hereinafter referred to as password sets). That is, it does not directly aim to eliminate passwords, but accepts the fact that passwords are still indispensable to ordinary people, and first helps users manage their password sets. The security and convenience of this function are contradictory, that is, the higher the protection strength of the password set, the more inconvenient it is to view the passwords in it. There is no shortage of APPs that provide this function in the market, and world-renowned Internet giants also have their own solutions, but they cannot avoid this contradiction. The function of this invention is to solve this contradiction, and a preliminary explanation is given below.

[0005] The present invention requires the user to select a terminal device that is mainly used to use this APP, hereinafter referred to as "this machine". As can be seen below, this allows users to use this APP from this machine in a particularly convenient but safe way. Users can also use this APP on any device that meets the same configuration requirements, but because the security unique to using this machine is missing, additional security measures must be added; and because users only need to use this APP from other devices in the occasional case of loss or damage of the machine, the design of this additional security measure only needs to focus on the effectiveness of the security measures, and there is no need to take into account the convenience of use. In this way, the two originally contradictory aspects of security and convenience can be strengthened separately without restricting each other. This is the idea of ​​resolving the above contradiction, and it is feasible because there is the fact that people nowadays generally carry smartphones with them.

[0006] The above paragraph is only about the main function module of this APP. In addition, a module is required for users to make necessary settings before using the main function, which is referred to as the registration module below. Each user of this APP must have a permanent user identity ID that is independent of the terminal device (including the local device) used by him. The registration module first communicates with the server to generate a permanent identity ID for the user and persists it on the server. This ID is the primary key of all user-related data in the server-side database, that is, all user-related information is collected and saved for a certain user identity ID. In addition, as mentioned in the above paragraph, each user must also have a local ID, which is an attribute that cannot be empty in the data about each user. The registration module allows users to choose to set the terminal device being used to run this APP as the local device. The mobile phone number and the device number (device IMEI, MAC address, or device ID from the device operating system) equipped with it can be combined in some way to set it as the local ID, which will be explained in the next section. Here, only two functions of the local ID are clarified. One is that it allows users to use it as a login ID, and the other is that it allows the system to identify whether the terminal device the user is using is his local device. After setting the local ID, the registration module sends it to the server for persistent storage and binds it to the user's permanent identity ID. The registration module has some other tasks, which are listed below.

[0007] The primary task of the main function module of this APP is to help users centrally manage their password sets. On the surface, it allows users to update and view their password sets in this APP after logging in. In fact, it also includes encrypting the updated password set and sending it to the server for storage, and obtaining, decrypting, and displaying the password set from the server when the user requests it. Where the key used for encryption and decryption comes from will be discussed later. Now it is only pointed out that it does not come from the password, that is, the present invention does not use the password (called the master password in some applications) to manage the password. This also means that the password is not used to log in to this APP, that is, the password is not used as a security authentication element of this APP. As a security authentication element, human biometric identification replaces the password in the present invention. First of all, it is because the software and hardware configuration required by this technology has been popularized in today's smart phones; more importantly, it is because (see the next paragraph) this technology can make the use of this APP on the local machine have both high convenience and high security. The corresponding requirement for the registration module is to collect the required human biometric information and send it to the server for storage in an encrypted state (the key used is shown below) so that the biometric information can be used for user identity security authentication on different terminal devices.

[0008] Human biometrics is the only user authentication method required by this APP on the local machine, that is, when a user uses this APP on the local machine, he can log in by simply doing facial feature (face or iris) recognition or fingerprint recognition. This is the ultimate in convenience. Looking at security, there are two senses of security involved here. In one sense, the use of human biometrics eliminates the risk of losing the entire password set due to forgetting the master password. Security in another sense refers to preventing leaks due to intentional or unintentional misentry by others. Security in this sense comes from the three effects that can be achieved simultaneously by using human biometrics on the local machine: first, the user is identified (because the local ID is bound to the user's identity ID in this application), second, it proves that the person trying to log in has the hardware specified by the user (that is, the set local machine), and third, it proves that the person trying to log in has the same human biometrics as the user. Adding more effects (the fourth, fifth, ...) will not substantially improve the security strength of user authentication. In this specific sense, the above-mentioned solution using this machine has basically reached the upper limit of security allowed by existing technologies (including human biometrics).

[0009] The above is only about how to use this machine. Although it is highly convenient and highly secure, it is incomplete. It is also necessary to solve the problem of how to not rely on the machine, so that users can use this APP even if the machine is lost or damaged; in addition, how to generate or obtain the keys used to encrypt and decrypt user information has not been mentioned so far, and it is only clear that the keys are generated without passwords. What needs to be done next is not only to solve these two problems for the completeness of the solution, but also to meet a more stringent requirement in terms of security, that is, even the implementers of the present invention cannot obtain the user's confidential information (in a decrypted state). The following method is used to achieve the above dual purposes.

[0010] Let's start with how to achieve independence from the local device. In the event that the local device is lost or damaged, the user can install this APP on any other terminal device (that meets the hardware configuration requirements) and use the original local ID to let the newly installed APP identify itself (the identity ID in this application). This is only the first of the three effects that can be achieved by using the local device for identity authentication. With this effect, the user's human biometric information can be obtained from the cloud, but it needs to be decrypted by the key before it can be used for human biometric identification. Because there will be a solution to the key acquisition later, it is better to assume here that human biometric identification can be performed on the newly installed APP, that is, the third effect of the convenient identity authentication method on the local device mentioned above can be achieved. However, the second effect is no longer possible: because the local device has been lost / damaged, it is impossible to verify whether the person trying to log in has the local device pre-set by the identified user. Therefore, some compensatory security measures should be added for using this APP from non-local devices. Moreover, (as mentioned above) this compensatory security measure can be designed only for security, and does not have to be restricted by taking into account convenience.

[0011] The above compensatory security measures specifically adopt user-set security questions and answers, which is to let users set some unforgettable questions and answers about personal experiences in advance, such as "Who was my first secret crush?", etc., and use the correct answer to these questions as one of the conditions to log in to this APP from a non-local device. Setting such questions and answers is an operation that users must complete in the registration module. Users can set any number of such questions and answers; they also need to set multiple such questions and answers to make themselves the only person who knows all the answers. The more such security questions and answers are set, the stronger the compensatory security measures on non-local devices will be. How strong it should be is controlled by each user.

[0012] The questions in the user-set security questions and answers must be sent to the server for storage. Only in this way can these questions be obtained from the cloud on any device (not the local device that meets the hardware configuration requirements), and the correct answers to these questions can be used as an element of user identity authentication. However, the answers in the user-set security questions and answers are not sent to the server, mainly for the strict security requirement mentioned above that the implementers of the present invention are not allowed to obtain the user's confidential information. Although there is no answer in the server, it is necessary to determine whether the user can successfully log in based on whether the user's answer is correct or not. The above two requirements seem to contradict each other, but they are feasible. The method is to send a certain characteristic parameter of the answer to each question to the server to achieve two effects: first, the answer itself cannot be known by these parameters alone; second, these parameters can be used to check whether the user's answer is wrong. The hash function widely used in cryptography can be used to solve this problem. The hash value generated by this function for each answer in the self-set security question and answer can be used as such a detection parameter, as detailed in the next section.

[0013] There can be any number of questions in the user-set security question and answer, and there will generally be multiple questions (see above). These questions are in order: they are stored in order in the cloud, and the characteristic parameters used to check the answers are also stored in the same order. The way to use this authentication method is that the user (not on the local computer) answers these questions sent from the cloud one by one in order. After each answer, the client uses the verification parameters of the answer to the question sent from the cloud to check the answer, and reminds the user to correct the answer if an error is detected. If it is not checked one by one in order and reminded in time, the user can only know whether the answer is wrong after all the answers are completed. If it is indeed wrong, it can only start over, which is very troublesome. The accuracy of answer detection according to the above method is not 100%. That is, the probability that a wrong answer to a question happens to have the same characteristic parameters as the correct answer, and the user happens to choose this wrong answer when answering this question is not zero. This probability is obviously very low and can be almost ignored. It can also be made lower by using methods similar to solving hash value conflicts, as described in the next section.

[0014] The user identity authentication method including the above-mentioned user-set security questions and answers is obviously inconvenient. After the user logs in to this APP on a non-native device in this way, he can set the terminal device he is using as the new native device, which is the same as the method of setting up the native device mentioned above. After that, he can log in to this APP on this device with a simple face or other biometric recognition.

[0015] In this application, user confidential information is transmitted between the client and the server in an encrypted state and stored in the server. The following problem needs to be solved on how to obtain the key for encryption / decryption. It has been made clear above that the key does not come from the password. Now it can also be made clear that this application does not use the public key-private key asymmetric encryption method, because it does not meet the security requirement that the implementer of the present invention cannot access the user confidential information in the decrypted state. Combined with the previous description, the required key can be described as follows: only one private key is used to encrypt and decrypt the user confidential information, and the key does not come from information that the user needs to remember deliberately like a password, so it must be stored in this application (the device on which it is running), but it cannot be sent to the server to prevent the implementer from obtaining it, that is, the key is only stored in the local machine for use, but it must also be able to be restored in a non-local device to prevent it from being lost with the loss / damage of the local machine.

[0016] Let's look at the user-set security questions and answers introduced earlier in order not to rely on the local machine. The answers to each question can be used to generate the key described above. Specifically, a mapping that converts strings into keys is placed in this APP. After the user completes the setting of the security questions and answers in this APP, this mapping will map the strings that constitute the answers to each security question in a certain order and method to a longer string that is mapped into a key, and stored on the local machine for automatic use: when updated confidential information needs to be sent to the cloud for storage, this key is used to encrypt the information first; when encrypted information is sent from the cloud to the local machine for viewing, this key is used to decrypt the information first. When the user uses this APP on a non-local machine, he must first answer the security questions he set to verify his identity. The answers given are also used to copy the key that was originally stored only in the local machine on this non-local device.

[0017] In addition to meeting the requirements already mentioned, the key generated in this way can also be replaced by the user himself and the implementer of the present invention at any time or regularly. Every time the user adds, subtracts, or modifies the self-set security questions and answers, the string composed of the answers to each question will change, and the key mapped by this APP will be different. Even if the user's self-set security questions and answers do not change, the answers to each question can be combined into different strings in different order and mixing methods to map different keys. Considering only the order of arrangement, and using A(n,m) to represent the number of different arrangements of m elements that can be made with n elements, if the user sets n security questions, the number of different arrangements that can be made is A(n,1) + A(n,2) +…+ A(n,n). For n=4, n=5, and n=6, this number is 64, 325, and 1956, respectively. In addition, the implementer can also provide different character mixing methods for users to choose, that is, in addition to selecting an arrangement order for the security question number, check a mixing method (method A, method B, method C, etc., and the user does not need to know how each method specifically mixes the strings of different security question answers together). In short, only a few security questions can be used to generate enough different keys. The implementer can also periodically update the mapping used to generate keys (see the next section for details), and install the new mapping to the client each time by updating the client software.

[0018] So far, this application has become a complete solution in helping users centrally manage their various passwords, and has reached the highest standards of security and convenience that can be achieved by existing technologies. The security here refers to all aspects, including the reliability of user identity authentication and the protection of user confidential information, and also eliminates the risk of users having difficulty or even no way to recover data due to hardware loss / damage.

[0019] The highly secure and convenient user authentication method designed for the first function can be shared by other Internet applications. The second function of this application is to provide this sharing service. Its core is to provide an API so that any Internet application (hereinafter referred to as other applications) that has certain requirements for the security of user authentication can borrow the user authentication method of this APP through this API. The first advantage is that other applications can save most of the development work related to user identity security authentication, while still enjoying the same security and convenience as the user authentication of this APP; the second advantage is that other applications no longer need auxiliary authentication elements such as mobile phone verification codes or dynamic QR codes, which solves the problem of difficulty in restoring services in the event of mobile phone loss / damage; the third advantage is that other applications that originally used human biometrics for user authentication no longer need to collect user human biometric information, thereby eliminating the risk of improper use of such personal information (against the will of the information owner); the fourth advantage is that the goal of eliminating passwords in Internet applications can be achieved.

[0020] If another application chooses to use this shared service of this application, it will be reflected on its login interface that after the user ID is identified, there will be an option to continue identity authentication using this service of this application, for those users who are also users of this application and have bound their identity ID in this application. After such a user makes this choice, they only need to do human biometric recognition on their local machine, and after passing, the identity authentication in this other application is completed. The network communication between the two clients and the two servers behind this is described in the API below.

[0021] From the perspective of other applications (users), this shared user identity authentication is obviously more convenient than using passwords or other existing authentication methods. In terms of security, it also has the three effects mentioned above: first, it identifies the user; second, it proves that the person trying to log in has the hardware specified by the user in advance; third, it proves that the person trying to log in has the same human biometrics as the user. The latter two effects rely on the binding of the user's two identity IDs in this other application and this application. On the surface, this shared identity authentication is somewhat similar to the binding of mobile phones to many Internet applications and using mobile phone verification codes or dynamic QR codes to authenticate user identities. The difference in convenience may not be that big; but in terms of security, the security strength of the above three effects is higher; in addition, once the mobile phone is lost or damaged, those Internet applications that are bound to the mobile phone need to rebind the mobile phone one by one to resume use, which is not only extremely troublesome, but some cannot even be restored and can only be re-registered. If these Internet applications all use this shared service of this application, users only need to rebuild the local machine according to the above method after the mobile phone used as the local machine is lost / damaged, and the normal use of all these applications can be restored.

[0022] The main work of implementing this shared service is to design and provide an API for implementing this function. In addition to the necessary communication protocol that allows other applications to communicate with the server of this application, this API mainly contains two functions. One is used to bind the user of other applications with their identity ID in this application. The input values ​​accepted by this function are two ID values ​​sent from other application servers: the user's login ID (local ID) in this application and the user's identity ID in other applications. The output value is a returned Boolean "yes" or "no". The former means that a one-to-one binding between the two identity IDs has been successfully established in the server of this application. The use of this function is started by the user entering his local ID in this application on the client of other applications. After the above input value is passed to the server of this application, it contacts the local machine and requests human biometric recognition. The local machine notifies the server of this application of the success or failure of the recognition, and the latter notifies other application servers. The second function is used to use the shared identity authentication service for users who have completed the above binding. The input value is the user identity ID of other applications, which is carried in the identity authentication request sent by the other application server to this application server when a user of other applications clicks to select this shared identity authentication on the login interface; then this application server sends a human biometric recognition request to this machine based on the above binding information; the Boolean value of whether the recognition is successful is returned to the other application server through this application server.

[0023] Not all other applications require the above security strength in user identity authentication. Some only need the security strength that can be achieved by using mobile phone verification as the second authentication factor, that is, they do not need the third security effect that can be achieved by the shared user identity authentication just mentioned above. For these applications, it is enough to replace human biometric recognition with clicking the confirmation button on the local machine in the second function of the above API. Therefore, it is best to provide this option for other applications in API design; although there is not much difference in convenience, it can reduce network communication overhead. The lower security strength requirements for user identity authentication does not mean that these applications do not need this shared service. At least it can solve the problem of restoring service after the mobile phone is lost / damaged and the anxiety caused by it.

[0024] Summary. In the present invention, the use of the concept of "native" and human biometrics complement each other. Compared with FIDO, FIDO also uses human biometrics (fingerprint) recognition to allow users to complete identity authentication with the same security strength with just a little effort, but users are required to carry hardware such as FIDO security keys, which is obviously inconvenient for users, and they also face more inconveniences and even risks caused by hardware loss / damage. These problems are all solved in the present invention because of the application of the concept of "native". Nowadays, people generally carry smartphones with them, so there is no need and inconvenience to carry other hardware. An important part of this concept is how to rebuild the local machine after it is lost / damaged. The key part of the method of rebuilding the local machine is the user's self-set security question and answer. The user's self-set security question and answer has a dual role in the present invention. In addition to being indispensable for realizing the concept of the local machine, it is also used to generate the key required for the present invention. Under the two restrictive conditions that the key cannot come from the password (which the present invention aims to eliminate) and the key cannot be mastered by the implementer of the present invention, the key can only be generated in this way. Unlike FIDO, the present invention does not directly aim to eliminate passwords, but rather provides an all-round solution to the password problem; because it solves the contradiction between security and convenience in personal password management, it is expected that the solution of the present invention will be widely adopted; and this gives other Internet applications reasons and conditions to use the shared user identity security authentication service of the present invention instead of passwords, which is actually closer to the goal of eliminating passwords. In addition, there are too many existing Internet applications that collect and use users' human biometric information, which itself constitutes a new risk, and the method used by the present invention to achieve the above-mentioned goal can also eliminate this new risk at the same time. Specific implementation methods

[0025] The present invention is implemented as a mobile Internet application with a C / S architecture, that is, the application mentioned in the previous section, and the APP is a client developed for mobile intelligent communication devices of different operating systems (iOS, Android, Hongmeng, etc.), which is used to implement the display layer of the application and network communication with the server. The core of the server is the database, which is used to store confidential information for users and store information about users required to implement the functions described in the previous section, such as human biometrics; the data and business layer logic of the server is mainly to save data from the client and receive and respond to data requests from the client. The Internet communication required by this application is two-way, that is, not all requests are initiated from the client. For example, in the shared user identity authentication function, the server (after receiving requests from other applications) needs to send a request to this APP first. There are many mature web service architectures / protocols that support two-way communication, such as WebSocket and RESTful services containing sse. This application can be developed on the basis of some such architectures / protocols; in particular, REST is most suitable for JSON data transmission mainly used by this application (see below).

[0026] From the previous section, we know that the following information from or about users needs to be stored on the server side: 1) encrypted user password set, 2) encrypted user biometric information, 3) user's permanent identity ID in this application, 4) user's local ID, 5) each question in the user's self-set security question and answer, 6) verification parameters for each answer in the user's self-set security question and answer, 7) user's identity ID in each other Internet application that uses the shared user identity authentication of this application. This information of each user can be regarded as forming a tuple. Each user's client operation only involves its own tuple, and there are no various problems that various paradigms of relational databases are used to deal with, so it is suitable to use NoSQL database. Specifically, tuple storage can be used, with the user's permanent identity ID in this application as the primary key of each tuple. The tuple itself and each piece of data in it do not have a fixed length, which is suitable for storing any number of user-set security questions of any length and any number of identity IDs in other applications. The JSON standard data used by most NoSQL also matches the data type accepted / generated by RESTful services; if the server program is developed based on REST as mentioned in the previous paragraph, the data type conversion link between network transmission and database storage can be omitted.

[0027] Two supplements to the previous paragraph. First, for the sake of convenience, the user's local ID has been treated as a number in the above text, which is not appropriate from an implementation perspective. As can be seen from the previous section, the local ID has two functions: one is the login ID for users to log in to this application, and the other is used for this application to identify whether the terminal device the user is using is the local device. The mobile phone number is suitable for the former, and the device number (device IMEI, or MAC address, or device ID from the device operating system) is suitable for the latter, but not vice versa. Therefore, the local ID should be two numbers in the database, although from the user's perspective it is just a mobile phone number. The so-called establishment of the local device is actually to bind the two numbers that constitute the local ID and persist them together as the data in the tuple referred to by the user's permanent identity ID in this application. Once the application finds that one of the two numbers that constitute the local ID does not match the terminal device in use, it requires the user to log in to this APP using the identity authentication method on a non-local device (described in the previous section), and also allows and reminds the user to set the device used (using the method described in the previous section) as the new local device after logging in.

[0028] The requirements of this application for the client software (this APP) are scattered in the previous section and are summarized as follows. First, this APP has two built-in mappings, one of which maps the string formed by concatenating the answers in the user-set security question and answer into a key, and the other generates a verification parameter for each answer in the user-set security question and answer that can verify the correctness of the answer but cannot reveal the answer itself. The implementer must at least update the former regularly or irregularly. Second, this APP contains the registration module mentioned in the previous section, that is, it can perform the operations of writing the data mentioned in paragraph 0026 except the user password set into the server-side database, including: user registration (obtaining a permanent identity ID in this application); allowing users to set their own security questions and answers, using all the answers to generate a key, generating a verification parameter for each answer, and sending the questions and answer verification parameters in sequence to the server for storage; collecting the user's human biometric information, encrypting it with the above key, and sending it to the server for storage; asking the user whether to set the terminal device in use as the local device, and after answering affirmatively, combining the mobile phone number used by the device with the device number (IMEI, MAC, or device ID from the operating system) as the local ID and sending it to the server for storage, and saving the above key in the local device. Third, if this APP installed on a certain device does not have a key stored in it, after it is started for a certain login ID, it requests the server for the questions and verification answer parameters of the security questions set by the user of the ID, requiring the user to answer these questions one by one, and verify whether the answer is correct after each answer. After all the correct answers are given, the answers are mapped to generate a key, and then the key is used to decrypt the biometric information of the ID user sent from the server, and the user is tested for biometrics based on this. After passing the test, the key is used to decrypt the password set of the ID user sent from the server for viewing and updating. Fourth, after the APP with the key stored in it is started for a certain login ID, it first communicates with the server to verify whether the device is the local device. If not, the next step is the same as the last (third item) described above. If it is the local device, the stored key is first used to decrypt the biometric information of the ID user sent from the server for the user's biometric test. After passing the test, the password set of the user sent from the server is decrypted, and the user has successfully logged in. Fifth, the logged-in user can view and update his password set. After logging out or closing this APP, the data sent from the server will be deleted from this APP, but if the user has updated the data, this APP will first encrypt the updated data and send it back to the server for storage, and then delete the data locally after receiving the confirmation information returned by the server. Sixth, respond to the request for identity authentication sent by the server.This is a request sent by the server to the local machine of this application after receiving a request from other Internet applications to verify the identity of its user in this application. The APP on the local machine decrypts the biometric information sent together, and performs a biometric test on the current owner of the local machine based on it. The result of whether the test passes or not is then sent to the server, which forwards it to other applications.

[0029] Extracting all the parts that mention the server in the previous paragraph is a description of the logic of this application server. In summary, it responds to requests from clients. Some responses receive and save data, while others send data. Only the last item (the sixth item) is a request from the server to the local client.

[0030] The encryption and decryption in this application are all completed on the client, and it is advisable to use a symmetric encryption method. The AES (Advanced Encryption Standards) encryption scheme can be used. The same is true for encrypting the user's plaintext information and the user's biometric information. Regarding the key, the mapping that needs to be installed in this APP for generating the key is in principle the same as the password-based key generation function such as PBKDF2. In the present invention, only the string of answers to each question in the user's self-set security question and answer is used as (or used to obtain) the input value of such function, rather than the password. A certain secure hash function can be used for such functions, which irreversibly maps a string of arbitrary length into a hash value of a fixed byte length, so that the mapping is superimposed to generate a key of a fixed length (such as 256 bits). The hash algorithm can use SHA-2, SHA-3 of the American Institute of Standards and Technology, and SM3 of the China National Cryptography Administration. This mapping of this application needs to be updated from time to time, which can be achieved by rotating between several existing similar key generation functions, combining the rotation between several existing hash algorithms, and then supplemented by the transformation of the number and method of superposition between hash algorithms.

[0031] In the design of user-set security questions and answers, how to make the system detect whether the answer is correct without storing the answer is also solved by hash functions; specifically, another mapping that is essentially a hash function is placed in this APP, and the answer to each question in the user-set security question and answer is irreversibly mapped into a hash value. The algorithm used is also selected from the existing SHA-2, SHA-3, SM3 and new standards that may appear in the future. This detection is not 100% accurate in theory, and there is a possibility of hash collision. But specifically in this link of the present invention, only the following situation needs to be avoided: the correct answer to a question happens to have the same hash value as a wrong answer, and the user happens to give this wrong answer when answering the question; this will cause the key generated by the answer mapping to be incorrect and the user is unaware of it, and cannot continue the following steps. In fact, by properly selecting the existing hash algorithm, the probability of hash collision can be reduced to a very low level; and the probability of the above situation will be even lower, because the answer itself is something that the user will never forget, even if the input is wrong, it is only a slight difference, and the two answers with only slight differences are less likely to have hash collisions. In summary, the detection accuracy problem of this link of the present invention can be ignored. If the implementer is willing to further reduce the probability of hash collision at the cost of increasing system overhead, there are several common measures in the industry to choose from; consider using dual mapping to generate two different detection parameters for each answer and use them together.

[0032] The human biometrics recognition in this application is used in conjunction with other security measures. Specifically, it is an additional layer of security protection after verifying that the registrant has the pre-specified hardware or correctly answers the pre-set security questions. In addition, it is sufficient to distinguish one person's biometrics from all other people. Therefore, the recognition accuracy requirement is much lower than that of existing related technologies such as VGG in convolutional neural networks; so lightweight neural network models such as MobileNet can be used, which can meet the requirements after simple parameter training. Also, because this application is for human biometrics recognition on mobile terminals, the available computing power and memory are small, but the requirements for running speed are high, so it is only suitable to choose lightweight models. The versions of this APP developed for large platforms such as iOS and Android, of course, use the biometrics recognition API of these platforms, which has many advantages in performance and other aspects.

[0033] The description of the implementation methods in this section is for illustrative purposes only. Any changes that can be made to the various implementation methods described in this section by a person of ordinary skill in the art without creative thinking, as long as they do not depart from the overall concept of the present invention and the implementation scheme in spirit, do not constitute a change or transcendence of the present invention.

Claims

1. A method for centrally managing passwords and eliminating passwords in Internet applications, implemented by a mobile Internet application with a C / S architecture (referred to as "this application", and its mobile client is referred to as "this APP"), characterized in that: 1) This application requires the user to set a mobile smart terminal device used to run this APP as his or her so-called "local device". After receiving this instruction, this APP combines the mobile phone number used by the device and the device number (IMEI, MAC address, or device number assigned by the operating system) as the local ID. Its functions are twofold: it allows the system to identify whether the terminal device the user is using is the local device, and allows the user to use the mobile phone number as the login ID; 2) The settings of this application for each user and their local machine include user-defined security questions and answers, that is, let the user set some questions that they will never forget but no one else can answer in full, as well as the answers to these questions. This APP will send the questions to the server for storage in sequence, and generate detection parameters for each answer that can detect whether the answer is correct but does not disclose the answer, which are also sent to the server for storage. The strings that constitute the various answers are mixed in a certain way to form a longer string that can be mapped into a key that can be used to encrypt plain text and human biometric information, and this (or these) keys are stored in the local machine; 3) Another setting of this application related to each user and their local machine is that in order to use human biometrics (such as face, iris, fingerprint) in user identity security authentication, the user is required to use this APP to collect his or her own biometric information in advance on the local machine, and then this APP will encrypt the collected information with the key mentioned above and send it to the server for storage; 4) After this APP is started for a certain login ID, it will first communicate with the server to verify whether the terminal device used is the local device of the ID user. If so, it will request the server to send the user's biometric information in encrypted state to the local device, decrypt it with the key stored in the local device, and then perform a biometric recognition test based on it. If it passes, it will decrypt the user's confidential information such as password sent from the server for viewing and updating; 5) After this APP is started for a certain login ID, if it is verified with the server that the terminal device used is not the local device of the ID user, it will request the server for the questions and test answer parameters of the security question and answer set by the user in advance, and require the user to answer these questions one by one, and check whether the answer is correct after each answer. After all the answers are correct, the answers are mapped to generate a key to decrypt the user's biometric information sent from the server, and the user is tested for biometric identification based on it. After passing the test, the 5 keys are used to decrypt the user's confidential information sent from the server for viewing and updating; 6) After this APP is started for a certain login ID on a non-native device and completes the above-mentioned user identity authentication procedure, it will ask the user on the operation interface whether to set the current terminal device as the local device. After receiving an affirmative answer, it will set a new local ID based on the mobile phone number and device number (IMEI, MAC address, or device number assigned by the operating system) used by the current device and send it to the server for persistent storage; 7) After this APP is launched and run for any user, if the user has not updated his or her data during operation, this APP will delete the data obtained and decrypted from the server during the startup and operation process from the device used after the user logs out. However, if the user has updated the data, the updated data will be encrypted with the above-mentioned key when the user logs out and sent back to the server for storage, and then the data will be deleted from the device used.

2. A method for centrally managing passwords and eliminating passwords in Internet applications as claimed in claim 1, characterized in that: This application provides an API to allow any other Internet application to select those of its users who are also users of this application to use their user identity in this application as an identity authentication factor in this other Internet application. During use, other applications send an authentication request for this authentication factor to this application, and then this application performs authentication in the manner described in Claim 1 and returns the authentication result to other applications.