Authentication method, electronic equipment and storage medium

Abstract

The invention discloses an authentication method, electronic equipment and a storage medium, and relates to the technical field of security, and the method can respond to a service trigger event, send an authentication request to a server side, and receive a first timestamp fed back by the server side based on the authentication request. And in response to the first timestamp, executing a first verification operation to prompt the user to input the verification code. And responding to the input completion operation of the verification code, generating a first verification token, and sending the first verification token to the security processing module. And receiving a second verification token generated by the security processing module based on the first verification token, and sending the second verification token to the server, so that the client, the server and the security processing module complete identity authentication together. By applying the technical scheme of the invention, the replay attack can be prevented through the first timestamp, the double verification tokens are combined with the security processing module, the authentication is completed through multi-terminal cooperation, and the security and reliability of identity authentication are effectively improved.

Description

Technical Field

[0001] This application relates to the field of security technology, and more particularly to an authentication method, electronic device, and storage medium. Background Technology

[0002] With the rapid development of internet technology, a large number of diverse products have emerged online, covering multiple fields such as games, cloud storage, and payment tools, providing users with convenient and rich services. While these services meet users' daily needs, most of them involve users' digital assets, and the security of digital assets is directly related to users' vital interests. Therefore, different types of online services all have clear and necessary requirements for security protection, and ensuring the security of users' digital assets has become an important prerequisite for the development of online products.

[0003] To address the security requirements of online services, most online products currently use user mobile phone numbers for two-factor authentication, providing security for users' digital assets. The specific process is as follows: When a user logs into the product, they must enter their account and password to complete the first-factor authentication, confirming basic login permissions. When the user uses services with higher security requirements (such as asset transfer or information modification), they must receive a verification code via the linked mobile phone number, enter the code, and complete the second-factor authentication to further verify the legitimacy of their identity.

[0004] However, the two-factor authentication mentioned above relies on the mobile phone number level. If the mobile phone number verification code is obtained, the security of two-factor authentication will be reduced, thereby threatening the user's digital assets. Summary of the Invention

[0005] In view of this, this application provides an authentication method, electronic device, and storage medium to address the low security issue of two-factor authentication.

[0006] Firstly, this application provides an authentication method applied to a client, the method comprising: In response to a service-triggered event, an authentication request is sent to the server. Receive the first timestamp fed back by the server based on the authentication request; In response to the first timestamp, a first verification operation is performed, which prompts for the input of a verification code; Upon completion of the operation in response to the input of the verification code, a first verification token is generated; Send the first verification token to the security processing module; Receive the second verification token generated by the security processing module based on the first verification token; Send the second verification token to the server so that the client, the server, and the security processing module jointly complete the identity authentication.

[0007] In the above method, the client connects the server and the security processing module to construct a three-party collaborative authentication process: from initiating a request to receiving a timestamp, generating a token and then forwarding, each step forms a data interaction loop. It not only strengthens the user identity verification through the verification code input, but also realizes the linkage between the client and the security processing module with the help of the dual verification token, avoids the vulnerabilities of single-role authentication, effectively improves the integrity and security of identity authentication, and at the same time ensures the smooth connection of the process and reduces the risk of authentication interruption.

[0008] In some embodiments of the present application, the authentication request carries user information, identification information, a first random value, and a second timestamp of the previous authentication; the first random value is a random value generated by the client in response to a service trigger event; the user information includes a username and a user password; the identification information includes a client identification and a service identification; the service identification corresponds to the service associated with the trigger event.

[0009] In the above method, the authentication request carries multi-dimensional information: the user information ensures the basic identity verification, the identification information accurately matches the client and the target service to avoid service confusion; the first random value is dynamically generated for each authentication to prevent attackers from reusing the historical request format to forge requests; the second timestamp of the previous authentication provides a basis for subsequent validity period verification. The combination of multiple pieces of information makes the authentication request unique, accurate and secure, blocking risks such as request forgery and cross-service abuse from the source.

[0010] In some embodiments of the present application, before sending the authentication request to the server, it further includes: In response to a registration event, send a registration request to the security processing module; the registration request carries identification information; receive the first key and the third timestamp fed back by the security processing module based on the registration request; according to the user information, the identification information, the first key and the third timestamp, send registration data to the server; receive the second random value and the first count value fed back by the server based on the registration data; store the second random value and synchronize the first count value to the security processing module.

[0011] In the above method, the client completes multi-party synchronization of registration data before authentication: obtaining the key and timestamp from the security processing module, submitting registration data to the server and receiving random and count values, and then synchronizing it to the security processing module. This process ensures that the client, server, and security processing module achieve consistency of key data (such as keys and count values) during the registration phase, providing a unified data benchmark for subsequent authentication steps such as token generation and step calculation, avoiding authentication failures due to data inconsistency, and improving the security of registration data through keys and random values.

[0012] In some embodiments of this application, generating the first verification token includes: Using the client identifier and service identifier as an index, query the second random value stored locally; based on the user password and the second random value, calculate the first sub-token using the first one-way hash function; based on the client identifier, the service identifier, and the second random value, calculate the second sub-token using the second one-way hash function; and obtain the first verification token based on the first sub-token and the second sub-token.

[0013] In the above method, the dual-identifier index ensures the accuracy of the second random value query; the one-way hash function is irreversible, which can prevent the direct exposure of user passwords and identification information, reducing the risk of data leakage; the two sub-tokens are respectively bound to user identity (password) and terminal or service information, and the combination forms a more comprehensive identity verification basis, effectively blocking attacks that only forge user information or only forge identification information, and improving token security.

[0014] In some embodiments of this application, after sending the second verification token to the server, the method further includes: Receive the authentication result fed back by the server based on the second verification token; if the authentication result indicates success, store the first timestamp using the client identifier and service identifier as indexes; if the authentication result indicates failure, accumulate the number of authentication failures.

[0015] In the above method, the client performs differentiated operations based on the authentication result: upon success, the first timestamp is stored with dual identifiers, and the second timestamp from the previous authentication is used for the next authentication, ensuring that the timestamps accurately correspond to the service and the client, avoiding cross-scenario confusion; upon failure, the number of attempts is accumulated, providing data support for triggering re-registration when the number of attempts exceeds the limit. This design not only ensures the validity of the timestamps for subsequent authentications, but also forms a security fallback through failure count statistics, reducing the risk of continuous illegal attempts, and balancing process continuity and security.

[0016] In some embodiments of this application, the method further includes: if the number of authentication failures is greater than or equal to a preset threshold, then a registration event is triggered.

[0017] The above method sets a threshold for the number of failed attempts and triggers a re-registration process. When the number of failed attempts exceeds the limit, it indicates a potential risk of account theft or data tampering. In this case, a forced re-registration re-initializes the associated data (such as keys and counters) of the client, server, and security processing modules, clearing the impact of abnormal data. This mechanism can promptly block continuous attacks, preventing attackers from cracking authentication through multiple attempts, and further strengthening account security and the controllability of the authentication process.

[0018] Secondly, this application also provides an authentication method applied to a server, the method comprising: Receive authentication requests sent by clients; In response to the authentication request, the current timestamp is read to obtain the first timestamp; Generate a verification code based on the authentication request; Send the verification code to the security processing module and send the first timestamp to the client; The server receives a second verification token sent by the client, enabling the server, the client, and the security processing module to jointly complete identity authentication; the second verification token is a second verification token generated based on the first verification token; the first verification token is a verification token generated by the client in response to the input of the verification code.

[0019] In the above method, the server acts as the core coordinator of the authentication process: upon receiving a request, it generates a timestamp and a verification code, which are then synchronized to the client and the security processing module, respectively, achieving a two-way association between the verification code and the timestamp; subsequently, it completes the final verification by receiving a second verification token, promoting three-party collaborative authentication. This process not only achieves information synchronization between the server and the security processing module through the verification code, but also lays the foundation for subsequent validity period verification with the timestamp, ensuring data interoperability at each stage of authentication and improving process coordination and verification integrity.

[0020] In some embodiments of this application, the authentication request carries user information, identification information, a first random value, and a second timestamp of the previous authentication; the user information includes a username and a password; the identification information includes a client identifier and a service identifier; the service identifier corresponds to the service associated with the authentication request. Before reading the current timestamp based on the authentication request, the method further includes: querying pre-stored associated data locally using the username, client identifier, and service identifier as indexes; the associated data includes a second random value, a first key, a fourth verification token, a fifth verification token, a first count value, and a third timestamp.

[0021] In the above method, the server uses a composite index to query related data, which is more accurate than a single index and can avoid data mismatch caused by duplicate usernames or single identifiers. The related data covers core parameters such as random values, keys, tokens, and count values, providing complete data support for subsequent dual validity period verification, token calculation, step size calculation and other steps.

[0022] In some embodiments of this application, after reading the current timestamp, the method further includes: Calculate a first difference between the first timestamp and the third timestamp, and a second difference between the first timestamp and the second timestamp; if the first difference is less than a preset static time threshold, and the second difference is less than the product of the first count value and the preset time coefficient, mark the dual validity period verification as passed; if the first difference is greater than or equal to the preset static time threshold, or the second difference is greater than or equal to the product of the first count value and the preset time coefficient, mark the dual validity period verification as failed.

[0023] In the above method, dual validity period verification manages authentication timeliness from both long-term and short-term dimensions: the first difference verification (registration time and current time) prevents long-term idle accounts from being used illegally, and static thresholds ensure account validity; the second difference verification (previous authentication time and current authentication time) combined with a count value dynamically manages the frequency of short-term authentication to prevent frequent invalid requests within a short period. Verification is only passed if both conditions are met simultaneously, avoiding the vulnerabilities of single validity period verification and flexibly adapting to the timeliness requirements of different authentication scenarios, thus improving the accuracy and security of authentication.

[0024] In some embodiments of this application, if the dual validity period verification fails, the method further includes: stopping sending the first timestamp to the client; and sending an authentication result indicating failure to the client.

[0025] In the above method, when the dual validity period verification fails, the server quickly terminates the invalid process by interrupting the sending of the timestamp and providing feedback on the failure result: stopping the sending of the first timestamp can block the client from subsequent redundant operations such as verification code input and token generation based on the timestamp, reducing resource waste; timely feedback on the failure result allows the client to quickly notify the user (such as account expiration, excessive requests), improving the user experience.

[0026] In some embodiments of this application, if the dual validity period verification passes, before sending the first timestamp to the client, the method further includes: calculating a sixth verification token using a first one-way hash function based on the user password and the second random value; calculating a seventh verification token using a second one-way hash function based on the client identifier, the service identifier, and the locally stored second random value; if the sixth verification token matches the fourth verification token, and the seventh verification token matches the fifth verification token, then generating the verification code; if the sixth verification token does not match the fourth verification token, stopping the sending of the first timestamp to the client, and sending an authentication result indicating failure to the client.

[0027] In the above method, the server adds dual token verification before generating the verification code: the sixth token verifies the consistency of the user's password to ensure the user's identity is legitimate; the seventh token verifies the matching of the client and service identifiers to avoid cross-scenario reuse. Verification codes are only generated when both tokens match, which can intercept illegal requests (such as incorrect passwords or cross-client requests) before the verification code is sent, reducing the risk of verification code abuse; if verification fails, the process is interrupted, further strengthening source control of authentication and improving the security and accuracy of verification code generation.

[0028] In some embodiments of this application, after sending the first timestamp to the client, the method further includes: The step size is calculated based on the first random value, the third timestamp, the second timestamp, and the first timestamp; if the first count value is less than or equal to the step size, the authentication result indicating failure is fed back to the client; if the first count value is greater than the step size, an eighth verification token is generated through the third one-way hash function.

[0029] In the above method, the step size is dynamically generated based on multiple timestamps and random values ​​to ensure uniqueness; the count value is compared with the step size to avoid abnormal subsequent encryption attempts due to insufficient count value, thus preventing token generation failure. Only after successful verification is the eighth verification token generated, which not only ensures the legality of the premise for token generation, but also strongly binds the token to the authentication process by associating the step size with the data of the preceding steps, effectively blocking forged token attacks that skip intermediate steps and improving the security of the authentication process.

[0030] In some embodiments of this application, generating the eighth verification token through the third one-way hash function includes: Based on the third one-way hash function, the fourth verification token, the fifth verification token, the first random value, the fourth random value, and the verification code are encrypted a target number of times according to the first key; wherein, the target number of times is equal to the step size; the fourth random value is a random value generated by the server after the server sends the first timestamp to the client.

[0031] In the above method, multiple parameters (including a dynamic fourth random value and a verification code) ensure the uniqueness of the token and avoid predictability caused by a single parameter; the encryption count is bound to the step size, strengthening the correlation between the token and the previous step size calculation stage, ensuring that only the process that passes the step size verification can generate a matching token; the one-way hash function is irreversible, preventing the token from being reverse-engineered. This design gives the eighth verification token high security and unforgeability, providing a reliable basis for final verification.

[0032] In some embodiments of this application, the calculation step size includes: The hash values ​​of the first random value, the third timestamp, and the first timestamp are calculated using a third one-way hash function; the hash values ​​are traversed to obtain a first character and a second character; the first character is the first character greater than or equal to a first threshold, and the second character is the first character less than or equal to a second threshold; the first count value is divided equally according to the first character to obtain a first segment; a second segment containing the first timestamp is determined from the first segment; the second segment is divided equally according to the second character to obtain a third segment; a fourth segment containing the first timestamp is determined from the third segment; and the step size is determined based on the fourth segment.

[0033] In the above method, hash value filtering ensures that the first and second characters are random, preventing fixed segmentation patterns from being cracked; the first and second thresholds constrain the character range and control the granularity of segmentation (e.g., the first character guarantees the basic number of segments, and the second character limits the upper limit of encryption times); multiple rounds of segmentation combined with the first timestamp positioning make the step size strongly correlated with the current authentication time. This design allows the step size to have both randomness to prevent attacks and adaptability to the authentication process requirements.

[0034] In some embodiments of this application, after receiving the second verification token sent by the client, the method further includes: comparing the second verification token with the eighth verification token; if the second verification token is consistent with the eighth verification token, then sending a successful authentication result to the client and updating the first count value to the second count value; the second count value is equal to the first count value minus the step size; if the second verification token is inconsistent with the eighth verification token, then sending a failed authentication result to the client.

[0035] In the above method, the server completes the final verification by comparing the two tokens. If they match, the authentication is confirmed to be legitimate; if they do not match, the illegal request is blocked to ensure the accuracy of the authentication result. The count value is updated by decreasing the step size, which not only limits the number of valid authentications for the same account, but also makes the count value strongly correlated with each authentication scenario, avoiding mass attacks caused by a fixed count value.

[0036] In some embodiments of this application, before receiving the authentication request sent by the client, the method further includes: The system receives registration data sent by the client and generates the second random value; the registration data carries the user information, the identification information, the first key, and the third timestamp; based on the user password and the second random value, the system calculates the fourth verification token using a first one-way hash function; and based on the identification information and the second random value, the system calculates the fifth verification token using a second one-way hash function.

[0037] In the above method, the server generates a dual-authentication token during the registration phase: the fourth token is bound to the user's password and the second random value, and the fifth token is bound to the identifier information and the second random value. The one-way hash function ensures that the data is irreversible and avoids the direct storage of passwords and identifiers; the second random value is a dynamic factor, making the token unique for the same user in different registration scenarios.

[0038] In some embodiments of this application, after calculating the fifth verification token using the second one-way hash function, the method further includes: Query the preset mapping table to determine the corresponding counting range based on the service identifier; obtain the lower limit and length of the counting range; calculate the remainder between the first key and the length of the counting range; calculate the sum of the lower limit and the remainder to obtain the first count value.

[0039] In the above method, the service identifier is associated with a counting range, allowing high-security services (such as financial services) to match a small range and low-security services to match a large range, avoiding resource waste or frequent re-registration; the key calculation remainder ensures that the count values ​​of different users under the same service are randomly distributed, preventing mass attacks. This design makes the first count value both meet the service security requirements and have randomness, providing flexible and secure parameter support for subsequent dual validity period verification and step size verification.

[0040] In some embodiments of this application, the authentication method further includes: using the user information and the identification information as indexes, storing the second random value, the first key, the fourth verification token, the fifth verification token, the first count value, and the third timestamp to obtain the associated data; and sending the second random value and the first count value to the client.

[0041] Thirdly, this application also provides an authentication method applied to a security processing module, the method comprising: Receive the verification code sent by the server based on the authentication request; The authentication request is a request sent by the client to the server; Receive the first verification token sent by the client in response to the completion of the verification code input operation; Generate a second verification token based on the first verification token; The second verification token is sent to the client so that the client, the server, and the security processing module can jointly complete the identity authentication.

[0042] In the above method, a second verification token is generated after receiving the server-side verification code and the client's first verification token. The verification code ensures synchronization with the server-side information, and the first verification token ensures matching with the client's identity.

[0043] In some embodiments of this application, the authentication request carries user information, identification information, a first random value, and a second timestamp of the previous authentication; the first timestamp is the timestamp of the current authentication; generating a second verification token based on the first verification token includes: using the identification information as an index to query the locally stored first key, third timestamp, and first count value; calculating a step size based on the first random value, the third timestamp, the second timestamp, and the first timestamp; and encrypting and generating the second verification token according to the step size.

[0044] In the above method, when the security processing module generates the second verification token, it first accurately queries local sensitive data (such as the first key) through the identification information to avoid the risk of data transmission leakage; the step size calculation logic is consistent with the server to ensure that the number of encryption times of both parties matches, laying the foundation for the consistency of subsequent token verification; the token is generated based on step size encryption, so that the token is strongly associated with the authentication pre-process (timestamp, random value).

[0045] In some embodiments of this application, before the receiving server sends the verification code based on the authentication request, the method further includes: The system receives a registration request sent by a client; the registration request carries the identification information; generates the third random value within a preset security range; calculates the first key based on the identification information, user identification code, and the third random value using a key generation algorithm; reads the local timestamp to obtain the third timestamp; sends the first key and the third timestamp to the client, and receives the first count value synchronized by the client; and stores the first key, the third timestamp, and the first count value using the identification information as an index.

[0046] In the above method, the security processing module builds a secure data foundation during the registration phase: a third random value is generated within a preset security range to ensure the unpredictability of the key factor; a first key is generated using multi-dimensional factors (identifier, user identification code, random value) to strengthen key uniqueness and anti-cracking capabilities; sensitive data (key, count value) is stored locally to prevent leakage during transmission; and data is synchronized to the client to ensure consistency among the three parties. This process, from the initial registration stage, provides high-security data support for subsequent authentication token generation and step-size calculation through secure generation, storage, and synchronization mechanisms.

[0047] In some embodiments of this application, after sending the second verification token to the client, the method further includes: if a successful authentication result indicating successful authentication is received from the client, updating the first count value to a second count value; the second count value is equal to the first count value minus the step size.

[0048] In the above method, the security processing module synchronously updates the count value after successful authentication, and the update logic (count value minus step size) is completely consistent with that of the server. This ensures real-time synchronization of the count values ​​among the client, server, and security processing module, avoiding problems such as incorrect step size calculations and validity period verification failures caused by count value deviations in subsequent authentications. Updates are only made after receiving a successful result to prevent accidental modification of the count value. This design ensures the consistency of core parameters in the authentication process, provides data assurance for the smooth progress of subsequent authentications, and enhances the security of count value management.

[0049] Fourthly, this application provides an electronic device, comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the methods described in the foregoing first, second, or third aspect embodiments.

[0050] Fifthly, this application provides a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause the computer to perform the methods described in the embodiments of the first, second, or third aspects described above.

[0051] Sixthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the methods described in the foregoing first, second, or third aspect embodiments.

[0052] As can be seen from the above technical solutions, the authentication method, electronic device, and storage medium disclosed in this application allow the method to respond to a service trigger event by sending an authentication request to the server and receiving a first timestamp from the server based on the authentication request. Then, in response to the first timestamp, the user is prompted to enter a verification code. Upon completion of the verification code input, a first verification token is generated and sent to the security processing module. Finally, a second verification token generated by the security processing module based on the first verification token is received and sent to the server, enabling the client, server, and security processing module to jointly complete identity authentication. By applying the technical solution of this application, replay attacks can be prevented through the first timestamp, and the combination of dual verification tokens and the security processing module allows for multi-terminal collaborative authentication, effectively improving the security and reliability of identity authentication.

[0053] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0054] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0055] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0056] Figure 1 A scenario architecture diagram of the authentication method provided in the embodiments of this application is shown; Figure 2 A flowchart illustrating an authentication method provided in an embodiment of this application is shown; Figure 3 A flowchart illustrating another authentication method provided in an embodiment of this application is shown; Figure 4 A flowchart illustrating another authentication method provided in an embodiment of this application is shown; Figure 5 An interactive diagram of the registration phase provided in an embodiment of this application is shown; Figure 6 The diagram illustrates the interaction of the authentication phase provided in an embodiment of this application. Figure 7 A schematic diagram illustrating the time range provided in an embodiment of this application is shown; Figure 8 A schematic diagram of the authentication device structure provided in an embodiment of this application is shown; Figure 9 A schematic block diagram of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0057] The embodiments of this application will now be described in more detail with reference to the accompanying drawings. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.

[0058] This disclosure is not exhaustive, but merely illustrative of some embodiments, and is not intended to limit the scope of protection of this disclosure. Unless otherwise specified, each step in a particular embodiment can be implemented as an independent embodiment, and the steps can be arbitrarily combined. For example, a solution after removing some steps in a particular embodiment can also be implemented as an independent embodiment, and the order of the steps in a particular embodiment can be arbitrarily interchanged. Furthermore, the optional implementation methods in a particular embodiment can be arbitrarily combined; moreover, the embodiments can be arbitrarily combined, for example, some or all steps of different embodiments can be arbitrarily combined, and a particular embodiment can be arbitrarily combined with the optional implementation methods of other embodiments.

[0059] In each of the disclosed embodiments, unless otherwise specified or in case of logical conflict, the terminology and / or descriptions of the embodiments are consistent and can be referenced by each other. Technical features in different embodiments can be combined to form new embodiments based on their inherent logical relationships. The terminology used in the embodiments of this disclosure is for the purpose of describing particular embodiments only and is not intended to limit the scope of this disclosure. In this disclosure, unless otherwise stated, elements expressed in the singular form, such as "a," "an," "the," "the," "the," "the," "the," "the," "this," etc., can mean "one and only one," or "one or more," "at least one," etc. For example, when using articles such as "a," "an," "the," etc. in translation, the noun following the article can be understood as either a singular or a plural expression. In some embodiments, the terms “in response to…”, “in response to determining…”, “in the case of…”, “when…”, “if…”, “if…”, etc., can be used interchangeably. In some embodiments, the terms “greater than,” “greater than or equal to,” “not less than,” “more than,” “more than or equal to,” “not less than,” “higher than,” “higher than or equal to,” “not lower than,” and “above” can be used interchangeably, as can the terms “less than,” “less than or equal to,” “not greater than,” “less than,” “less than or equal to,” “not more than,” “lower than,” “lower than or equal to,” “not higher than,” and “below”. The prefixes such as "first" and "second" in the embodiments of this disclosure are only for distinguishing different descriptive objects and do not constitute restrictions on the position, order, priority, number or content of the descriptive objects. For the description of the descriptive objects, please refer to the description in the claims or the context of the embodiments. The use of prefixes should not constitute unnecessary restrictions.

[0060] In the embodiments disclosed herein, "multiple" refers to two or more. In the embodiments disclosed herein, terms such as “import”, “input”, and “read in” can be used interchangeably.

[0061] In some embodiments, devices, etc., can be interpreted as physical or virtual, and their names are not limited to the names recorded in the embodiments. Terms such as “device”, “equipment”, “circuit”, “network element”, “node”, “function”, “unit”, “section”, “system”, “network”, “chip”, “chip system”, “entity”, and “subject” can be used interchangeably.

[0062] In some embodiments, the terms "terminal", "terminal device", "user equipment (UE)", "user terminal", "mobile station (MS)", "mobile terminal (MT)", "subscriber station", "mobile unit", "subscriber unit", "wireless unit", "remote unit", "mobile device", "wireless device", "wireless communication device", "remote device", "mobile subscriber station", "access terminal", "mobile terminal", "wireless terminal", "remote terminal", "handset", "useragent", "mobile client", and "client" can be used interchangeably.

[0063] To address the security requirements of online services, network products employ a method of binding users' mobile phone numbers, relying on these numbers to implement two-factor authentication, thereby providing users with security guarantees. Specifically, when users log in to the network product, they need to use their account and password for the first factor authentication. When using services with security requirements within the product, they need to use their mobile phone number to receive a verification code for the second factor authentication.

[0064] However, the aforementioned two-factor authentication relies on the mobile phone number level. Since there are many ways to illegally obtain verification codes at the mobile phone number level, it poses certain security risks. For example, if a user's phone is inadvertently infected with malware, the software can directly intercept SMS messages containing verification codes, illegally obtaining them and bypassing the second-factor authentication. Furthermore, fraudsters can obtain user verification codes through manipulative tactics or by tricking users into logging into their accounts from different locations, both of which can successfully complete two-factor authentication, posing a security risk.

[0065] To address the aforementioned issues, some embodiments of this application provide authentication methods, such as... Figure 1As shown, the method enables the server, client, and SIM card (Subscriber Identity Module) to participate in two-factor authentication, binding the business layer with the hardware layer and improving authentication security.

[0066] Figure 2 This is a flowchart illustrating an authentication method provided in an embodiment of this application. Figure 2 As shown, the method is applied to the client, and the method includes steps S101-S107.

[0067] S101. In response to the service trigger event, send an authentication request to the server.

[0068] When a user performs an action on the client that triggers a high-security service, a service trigger event is generated. The client then responds to the service trigger event by sending an authentication request to the server.

[0069] In some implementations, the high-security services associated with the service triggering event include at least one of financial transfers, cloud drive file deletion, or game item transactions.

[0070] S102, Receive the first timestamp returned by the server based on the authentication request.

[0071] After the client sends an authentication request to the server, the server reads the current timestamp (i.e., the first timestamp) based on the first authentication request and sends it to the client. The client then receives the first timestamp (Timestamp) returned by the server.

[0072] S103. In response to the first timestamp, perform the first verification operation.

[0073] The first verification operation prompts the user to enter a verification code. After receiving the first timestamp, the client responds by prompting the user to enter the verification code, such as by displaying a prompt message through the user interface (UI).

[0074] In some implementations, the verification code is sent by the server to the security processing module (i.e., SIM) based on the authentication request.

[0075] S104. In response to the completion of the verification code input, generate the first verification token.

[0076] When the server detects that the verification code input has been completed, it generates the client's first verification token. This first verification token ensures that the verification code is bound to the current authentication request, preventing unauthorized reuse.

[0077] In some implementations, the first verification token may include a first sub-token and a second sub-token.

[0078] S105. Send the first verification token to the security processing module.

[0079] After the client generates the first verification token, it sends the first verification token to the SIM (security processing module), so that the SIM can generate the corresponding second verification token based on the first verification token and send the second verification token back to the client.

[0080] S106. Receive the second verification token generated by the security processing module based on the first verification token.

[0081] The client receives a second verification token generated by the SIM. This second verification token is used to bind authentication from the business layer to the SIM hardware layer, thereby blocking authentication paths caused by verification code leakage.

[0082] S107. Send the second verification token to the server so that the client, server and security processing module can jointly complete the identity authentication.

[0083] After receiving the second verification token generated by the SIM, the client sends it to the server for synchronization, thereby achieving collaborative identity authentication among the client, server, and SIM, which can improve authentication security.

[0084] According to the technical solution provided in the above embodiments, after the client responds to the high-security service trigger event, it sends an authentication request to the server and obtains the first timestamp, and then prompts the user to enter a verification code; after the verification code is entered, a first verification token is generated and sent to the SIM card (security processing module), and the SIM card generates a second verification token accordingly. Finally, the client sends the second verification token to the server, realizing the collaborative authentication of the client, server and SIM card.

[0085] In this embodiment, the client, server, and SIM card work together for authentication. The first timestamp helps to prevent replay attacks, the first verification token prevents the illegal reuse of verification codes, and the second verification token binds the authentication to the hardware layer. This multi-terminal collaboration blocks the risk of verification code leakage and can significantly improve the security and reliability of identity authentication.

[0086] Figure 3 This is a flowchart illustrating an authentication method provided in an embodiment of this application. Figure 3 As shown, the method is applied to the server side, and the method includes steps S201-S205.

[0087] S201. Receive the authentication request sent by the client.

[0088] The server receives authentication requests from the client. These authentication requests are sent by the client in response to a service-triggered event. When a user performs an operation on the client that triggers a high-security service, a service-triggered event is generated. The client then responds to this event by sending an authentication request to the server.

[0089] S202. In response to the authentication request, read the current timestamp to obtain the first timestamp.

[0090] Upon receiving an authentication request, the server reads the current timestamp from the request to obtain the first timestamp. This first timestamp can be used to verify the validity period and defend against replay attacks.

[0091] S203. Generate a verification code based on the authentication request.

[0092] The server also generates a corresponding verification code based on the authentication request, which serves as a verification factor for identity authentication.

[0093] S204. Send the verification code to the security processing module and send the first timestamp to the client.

[0094] After receiving the first timestamp and verification code, the server sends the verification code to the SIM and the first timestamp to the client, thus synchronizing the authentication information.

[0095] S205. Receive the second verification token sent by the client, so that the server, client, and security processing module can jointly complete identity authentication. The second verification token is generated based on the first verification token; the first verification token is generated by the client in response to the input of the verification code.

[0096] In other words, upon receiving the first timestamp, the client is prompted to enter a verification code. After the verification code is entered and the operation is completed, a first verification token is generated and sent to the SIM. The SIM receives the first verification token, generates a second verification token based on it, and sends the second verification token to the client. The client receives the second verification token generated by the SIM and sends it to the server for synchronization. This achieves collaborative identity authentication between the client, server, and SIM, improving authentication security.

[0097] According to the technical solution provided in the above embodiments, after receiving the authentication request from the client, the server generates a first timestamp and a verification code, sends the first timestamp to the client and the verification code to the SIM, and finally receives the second verification token forwarded by the client, and works with the client and SIM to complete the identity authentication process.

[0098] In this embodiment, a first timestamp is generated to resist replay attacks, a verification code is generated and distributed as the verification basis, and the reception and verification of the second verification token are combined to realize the synchronization and collaborative verification of information from the three ends, thereby strengthening the security of the authentication link.

[0099] Figure 4 This is a flowchart illustrating an authentication method provided in an embodiment of this application. Figure 4 As shown, the method is applied to a security processing module, i.e., SIM; and the method includes steps S301-S304.

[0100] S301, Receive the verification code sent by the server based on the authentication request.

[0101] The authentication request is a request sent from the client to the server. When a user performs an operation on the client and triggers a high-security service, a service trigger event is generated. The client then responds to the service trigger event by sending an authentication request to the server. The server receives the authentication request from the client, determines the first timestamp based on the authentication request, and sends it to the client; it also generates the corresponding verification code and sends it to the security processing module, i.e., SIM.

[0102] The client can respond with the first timestamp and prompt the user to enter the verification code received by the SIM card.

[0103] S302, Receive the first verification token sent by the client in response to the verification code input completion operation.

[0104] Once the client detects the verification code input and completes the operation, it generates a first verification token and sends it to the SIM. The SIM then receives the first verification token to prevent the verification code from being reused illegally.

[0105] S303. Generate a second verification token based on the first verification token.

[0106] After receiving the first verification token, the SIM generates a second verification token based on the first verification token. The second verification token can bind the authentication to the hardware layer.

[0107] S304. Send a second verification token to the client so that the client, server and security processing module can jointly complete the identity authentication.

[0108] After the SIM generates a second verification token, it can send it to the client, which then synchronizes the second verification token to the server. This enables collaborative identity authentication among the client, server, and SIM, thereby improving authentication security.

[0109] According to the technical solution provided in the above embodiments, the SIM first receives the verification code sent by the server based on the authentication request, then receives the first verification token generated by the client after the verification code is entered, and then generates a second verification token based on the first verification token and sends it to the client, providing hardware layer support for the three-terminal collaborative authentication of the client, the server and itself.

[0110] In this embodiment, by receiving and generating a hardware-bound second verification token based on the verification code and the first verification token, the authentication is extended from the business layer to the SIM hardware layer, blocking illegal authentication paths caused by verification code leakage, and cooperating with the client and server to strengthen the security of identity authentication.

[0111] In some embodiments, the authentication request carries user information, identification information, a first random value (Salt3) and a second timestamp (Timestamp2`) of the previous authentication; the first random value is a random value generated by the client in response to a service trigger event; the user information includes a username and a password; the identification information includes a client ID and a service ID; the service ID corresponds to the service associated with the trigger event.

[0112] For example, when a user operates on the Client and triggers a service, the Client queries the ServiceID of that service. The Client generates a random value Salt3 and sends Message1 (authentication request) to the Server, requesting the Server to authenticate in order to provide the corresponding service. Message1 carries the Username, Password, ClientID, ServiceID, Salt3, and the timestamp of the last successful authentication, Timestampe2, that is, Message1={Username, Password, ClientID, ServiceID, Salt3, Timestampe2}.

[0113] To achieve the above authentication, in some embodiments, the server, client, and security processing module also work together to perform the registration phase.

[0114] In some embodiments, during the client registration phase, the client responds to a registration event by sending a registration request to the security processing module. This registration request carries identification information, such as a client identifier and a service identifier. The client then receives a first key (sk) and a third timestamp (Timestamp1) from the security processing module based on the registration request, and sends registration data to the server according to the user information, identification information, the first key, and the third timestamp. The client then receives a second random value (Salt2) and a first count value (T1) from the server based on the registration data; subsequently, the client stores the second random value and synchronizes the first count value with the security processing module.

[0115] In this embodiment, the client responds to a registration event by sending a registration request carrying identification information to the security processing module, and receives a first key and a third timestamp from the module. Then, it generates registration data by combining this data with user information and sends it to the server. After receiving a second random value and a first count value from the server, the client stores the second random value and synchronizes the first count value with the security processing module. In this way, by exchanging keys, timestamps, random values, and count values, the client, security processing module, and server complete the binding of registration information and synchronization of security parameters. This lays the key foundation and data consistency prerequisite for subsequent three-terminal collaborative authentication, improving the overall security of the authentication system.

[0116] In the server-side registration phase, in some embodiments, the server receives registration data sent by the client and generates a second random value. The registration data carries user information, identification information, a first key, and a third timestamp. Then, based on the user password and the second random value, a fourth verification token (Token1 = H1(Password, Salt2)) is calculated using a first one-way hash function; and based on the identification information and the second random value, a fifth verification token (Token2 = H2(ClientID, ServiceID, Salt2)) is calculated using a second one-way hash function.

[0117] In this embodiment, the server receives registration data from the client, containing user information, identification information, a first key, and a third timestamp, and generates a second random value. Then, based on the user password and the second random value, and the identification information and the second random value, a fourth verification token and a fifth verification token are calculated using different one-way hash functions. This utilizes the irreversibility of one-way hash functions to protect the user password and identification information, combines the second random value to resist rainbow table attacks, and the generated verification tokens provide a secure verification basis for subsequent authentication, strengthening the confidentiality and integrity of the registration data.

[0118] In some embodiments, after the server calculates the fifth verification token using the second one-way hash function, it also queries a preset mapping table to determine the corresponding counting range based on the service identifier. Then, it obtains the lower limit (T0) and length (Long) of the counting range and calculates the remainder (SK%Long) between the first key and the length of the counting range. Finally, it calculates the sum of the lower limit and the remainder to obtain the first count value (T1).

[0119] In this embodiment, the server first looks up the corresponding counting range in a preset mapping table according to the service identifier, and extracts the lower limit and length of the range; then, it calculates the remainder of the length using the first key, and finally adds the remainder to the lower limit to obtain the first count value. This approach not only ensures that the counting range matches the service security requirements (e.g., a smaller range for high-security services) through service tiering, avoiding resource waste or frequent re-registration; it also uses dynamic key calculation to make the count value random, preventing mass attacks, and provides flexible parameters for subsequent dual-validity verification, thus enhancing authentication security.

[0120] In some embodiments, the server further stores a second random value, a first key, a fourth verification token, a fifth verification token, a first count value, and a third timestamp, using the user information and identification information as indexes, to obtain associated data. It also sends the second random value and the first count value to the client.

[0121] During the SIM-side registration phase, in some embodiments, the security processing module also receives registration data sent by the client and generates a second random value. The registration data carries user information, identification information, a first key, and a third timestamp. Based on the user password and the second random value, a fourth verification token is calculated using a first one-way hash function; and based on the identification information and the second random value, a fifth verification token is calculated using a second one-way hash function.

[0122] In this embodiment, the SIM terminal receives registration data from the client, containing user information, identification information, a first key, and a third timestamp, and generates a second random value. Then, based on the user password and the second random value, and the identification information and the second random value, a fourth verification token and a fifth verification token are calculated using corresponding one-way hash functions. This approach leverages the irreversibility of one-way hash functions to protect sensitive data, enhances anti-attack capabilities by combining the second random value, and ensures that the generated verification tokens corroborate the server's verification, thereby improving the security and data reliability of the registration process.

[0123] Based on the above embodiments, such as Figure 5 As shown, the registration phase may include the following steps S1-S6.

[0124] S1. The Client sends Message1 to the SIM. Message1 carries the Client ID and Service ID, that is, Message1={ClientID, ServiceID}.

[0125] Among them, ServiceID is the ID of a certain service provided by the Client or Server to the user. Different Servers provide different services, such as financial services like money transfer and lending, cloud storage services like file deletion, and game services like top-up and item trading.

[0126] S2, SIM reads IMSI (International Mobile Subscriber Identity) and generates key SK based on ClientID, ServiceID, and IMSI. Key SK is mainly used to encrypt data during the authentication process.

[0127] In some implementations, the SIM has a built-in secure zone, which can be a hardware-level security chip or a software-level trusted execution environment. The SIM performs two-factor authentication operations within the secure zone to improve authentication security.

[0128] The process of generating the key SK using the IMSI code is as follows: a random value Salt1 is generated, and the built-in key generation algorithm f is called to generate the key SK based on ClientID, ServiceID, and Salt1, that is, SK=f(ClientID,ServiceID, IMSI,Salt1); the SIM reads the local timestamp Timestampe1; the SIM sends Message2 to the Client, which carries SK and Timestampe1, that is, Message2={SK, Timestampe1}.

[0129] S3. The Client sends Message3 to the Server. Message3 carries the username, password, clientID, serviceID, SK, and timestampe1. That is, Message3={Username, Password, ClientID, ServiceID, SK, Timestampe1}.

[0130] S4, Server generates a random value Salt2.

[0131] Specifically, Token1 is generated using a one-way hash function H1 based on Password and Salt2, i.e., Token1 = H1(Password, Salt2); Token2 is generated using a one-way hash function H2 based on ClientID, ServiceID, and Salt2, i.e., Token2 = H2(ClientID, ServiceID, Salt2).

[0132] In one implementation, the server pre-configures a mapping table locally. The mapping table contains multiple mapping relationships, each of which includes a ServiceID and a counting range. The Range value itself represents the number of encryption attempts. Based on the average number of encryption attempts per authentication, the validity can be constrained based on the number of authentication attempts. Multiplying the value by a time coefficient converts it into an expiration period, which constrains the validity period. Based on the average daily authentication frequency, it is equivalent to time, and this time is equal to the expiration period.

[0133] In one implementation, the higher the security requirements of the ServiceID service, the smaller the Range, and the shorter the validity period of the registered information, thus improving security. Conversely, the lower the security requirements of the ServiceID service, the larger the Range, and the longer the validity period of the registered information, thus reducing the frequency of registration and reducing performance overhead.

[0134] For example, the table is as follows:

[0135] In this example, the security requirements are ServiceID_1 > ServiceID_2 > ServiceID_3. ServiceID_1 is the payment service, the Range is the midpoint of 125, each authentication encryption is about 3 times, the Range can support about 40 authentications, the daily payment frequency is about 2 times, and it can support a period of 20 days. Multiplying the Range by 10000 converts to the validity period, which is a maximum of about 20 days.

[0136] In one implementation, to improve randomness and prevent attacks such as dictionary attacks, a modulo algorithm can be used to take a value (i.e., remainder) from the Range mapped by ServiceID based on the Range length (Long) and SK. This value is then added to the lower limit value T0 of the Range mapped by ServiceID to obtain the count value T1, i.e., T1 = T0 + SK%Long.

[0137] The server locally persists Salt2, SK, Token1, Token2, T1, and Timestampe1, indexed by Username, ClientID, and ServiceID, i.e., Per = {Username, ClientID, ServiceID - Salt2, SK, Token1, Token2, T1, Timestampe1}. The server sends Message4 to the client, carrying the username Salt2 and T1, i.e., Message4 = {Salt2, T1}.

[0138] S5. The Client sends Message5 to the SIM, which carries the username T1, i.e., Message5 = {T1}. The Client stores Salt2 locally using ClientID and ServiceID as indexes, i.e., Per = {ClientID, ServiceID - Salt2}.

[0139] S6 and SIM use ClientID and ServiceID as indexes to store SK, T1, and Timestampe1, that is, Per={ClientID,ServiceID-SK,T1,Timestampe1}.

[0140] In the above steps S1-S6, the data used in the authentication phase includes Salt2, SK, T1 and Timestampe1, which are stored by SIM and Client respectively to provide data support for the authentication process.

[0141] For the client, in some embodiments, when generating the first verification token, the client queries a locally stored second random value using the client identifier and service identifier as indexes. Then, based on the user password and the second random value, a first sub-token (Token1`) is calculated using a first one-way hash function (H1). Based on the client identifier, service identifier, and the second random value, a second sub-token (Token2`) is calculated using a second one-way hash function (H2). The first verification token is obtained based on the first and second sub-tokens.

[0142] In this embodiment, when the client generates the first verification token, it first uses the client identifier and service identifier as indexes to find the second random value stored locally. Then, it calculates sub-tokens using two one-way hash functions: the first one-way hash function processes the user password and the second random value to obtain the first sub-token, and the second one-way hash function processes the client identifier, service identifier, and the second random value to obtain the second sub-token. This one-way hash function is irreversible, preventing the direct exposure of user passwords and identifier information, thus reducing the risk of data leakage. Using dual identifiers to index the second random value ensures a strong binding between the token and the specific user and service, preventing token reuse across services and clients. The dual-token combination also improves the integrity of subsequent verification.

[0143] In some embodiments, after the client sends the second authentication token to the server, the client also receives the authentication result fed back by the server based on the second authentication token. If the authentication result is successful, a first timestamp is stored using the client identifier and service identifier as indexes; if the authentication result is failed, the number of authentication failures is accumulated.

[0144] In some embodiments, if the number of authentication failures is greater than or equal to a preset threshold, the client triggers a registration event, i.e., re-initiates the registration process.

[0145] In this embodiment, after the client sends the second verification token to the server, it receives the authentication result returned by the server. If the result is successful, the first timestamp of the current authentication is stored using the client identifier and service identifier as indexes (to provide a second timestamp of the previous authentication for the next authentication). If the result is unsuccessful, the cumulative statistics of the number of authentication failures are initiated. In this way, storing the timestamp with dual identifiers upon success ensures that the previous timestamp called during the next authentication accurately corresponds to the current service and client, avoiding timestamp confusion across services or clients. Accumulating the number of failures provides data for triggering re-registration when the limit is exceeded, reducing the risk of continuous illegal attempts.

[0146] For the server side, in some embodiments, before reading the current timestamp based on the authentication request, the server also queries pre-stored associated data locally using the username, client identifier, and service identifier as indexes. This associated data includes a second random value, a first key, a fourth verification token, a fifth verification token, a first count value, and a third timestamp.

[0147] In this embodiment, the server uses the username, client identifier, and service identifier as a combined index to query pre-stored associated data locally. This associated data includes a second random value, a first key, a fourth verification token, a fifth verification token, a first count value, and a third timestamp, providing basic data support for verification and calculation in subsequent authentication steps. This ensures accurate location of associated data through the combined index, avoiding data mismatches caused by duplicate identifiers. Simultaneously, by querying and retrieving all core data in advance, it eliminates the need for repeated retrieval in subsequent steps such as dual validity period verification, token verification, and step size calculation, thereby improving the efficiency of the authentication process and ensuring data consistency across all stages.

[0148] In some embodiments, after reading the current timestamp, a first difference between the first timestamp and the third timestamp (Timestampe2-Timestampe1) and a second difference between the first timestamp and the second timestamp (Timestampe2'-Timestampe2) are also calculated.

[0149] If the first difference is less than the preset static time threshold (Tt) and the second difference is less than the product of the first count value and the preset time coefficient (T1×Ts), the dual validity period verification is marked as passed; if the first difference is greater than or equal to the preset static time threshold, or the second difference is greater than or equal to the product of the first count value and the preset time coefficient, the dual validity period verification is marked as failed.

[0150] In this embodiment of the disclosure, after the server reads the first timestamp of the current authentication, it calculates two differences: one is the first difference between the first timestamp (current) and the third timestamp (generated during the registration phase), and the other is the second difference between the first timestamp and the second timestamp (previous authentication). Then, the validity of the verification is judged by dual conditions: only when the first difference is less than the preset static time threshold (Tt) and the second difference is less than the product of the first count value and the preset time coefficient (T1×Ts), is the dual validity period verification marked as passed; otherwise, it is judged as failed.

[0151] In this way, the first difference check can limit the authentication to the valid period after registration, and prevent long-term idle accounts from being illegally reused; the dynamic calculation of the second difference (combined with the first count value) can flexibly control the authentication frequency and prevent frequent invalid authentication attempts in a short period of time.

[0152] In some embodiments, if the dual validity period verification fails, the server also stops sending the first timestamp to the client; and sends the authentication result indicating failure to the client.

[0153] In this embodiment of the disclosure, after the server determines that the dual validity period verification fails, it will stop sending the first timestamp of the current authentication to the client, interrupting the client's subsequent processes such as verification code prompting and first verification token generation based on the timestamp; and directly send the result indicating authentication failure to the client, clearly informing the client of the status of verification failure.

[0154] In some embodiments, if the dual validity period verification passes, before sending the first timestamp to the client, the server calculates the sixth verification token (Token1`=H1(Password,Salt2) using the first one-way hash function based on the user password and the second random value. Then, based on the client identifier, service identifier, and the locally stored second random value, the server calculates the seventh verification token (Token2`=H2(ClientID,ServiceID,Salt2)) using the second one-way hash function.

[0155] If the sixth verification token (Token1`) matches the fourth verification token (Token1), and the seventh verification token matches the fifth verification token, a verification code is generated; if the sixth verification token does not match the fourth verification token, the first timestamp is stopped from being sent to the client, and an authentication result indicating failure is sent to the client.

[0156] In this embodiment of the disclosure, after the dual validity period verification is passed, the server needs to complete dual token verification before generating the verification code: First, based on the user password and the second random value, the sixth verification token is calculated using the first one-way hash function; at the same time, based on the client identifier, the service identifier, and the second random value, the seventh verification token is calculated using the second one-way hash function; then, the sixth token is compared with the fourth verification token stored during registration, and the seventh token is compared with the fifth verification token. The verification code is generated only when both are consistent; if either is inconsistent, the first timestamp is stopped and a failure result is reported.

[0157] In this way, the sixth token verification ensures that the password entered by the user is consistent with the password used during registration, preventing unauthorized use after the password is leaked; the seventh token verification binds the client and service identifier to avoid the reuse of tokens across terminals or services.

[0158] In some embodiments, after sending the first timestamp to the client, the server also calculates a step size (ΔT) based on the first random value, the third timestamp, the second timestamp, and the first timestamp. If the first count value is less than or equal to the step size, the server sends an authentication result indicating failure to the client; if the first count value is greater than the step size, the server generates an eighth verification token (Token3) using a third one-way hash function.

[0159] In this embodiment of the disclosure, after the dual validity period verification is passed, the server needs to complete dual token verification before generating the verification code: First, based on the user password and the second random value, the sixth verification token is calculated using the first one-way hash function; at the same time, based on the client identifier, the service identifier, and the second random value, the seventh verification token is calculated using the second one-way hash function; then, the sixth token is compared with the fourth verification token stored during registration, and the seventh token is compared with the fifth verification token. The verification code is generated only when both are consistent; if either is inconsistent, the first timestamp is stopped and a failure result is reported.

[0160] In this way, the sixth token verification ensures that the password entered by the user is consistent with the password used during registration, preventing unauthorized use after the password is leaked; the seventh token verification binds the client and service identifier to avoid the reuse of tokens across terminals or services.

[0161] In some embodiments, when the server generates the eighth verification token (Token3) using the third one-way hash function, it encrypts the fourth verification token, the fifth verification token, the first random value, the fourth random value (Salt4), and the verification code a target number of times based on the third one-way hash function (H3) and the first key. The target number of times is equal to the step size; the fourth random value is a random value generated by the server after sending the first timestamp to the client.

[0162] For example, the server generates a random value Salt4, and uses a one-way hash function H3 to encrypt Token1, Token2, Salt3, Salt4 and Code ΔT times based on SK to obtain Token3, that is, Token3=H3ΔTSK (,Token1,Token2,Salt3,Salt4,Code).

[0163] In this embodiment of the disclosure, when the server generates the eighth verification token, it uses the third one-way hash function as an encryption tool to repeatedly encrypt the fourth verification token, the fifth verification token, the first random value, the fourth random value (Salt4) newly generated by the server, and the verification code as joint input parameters, according to the target number of times set by the step size; wherein, the number of encryption times is strictly bound to the step size calculated in the previous stage, and the fourth random value is a random factor dynamically generated by the server after sending the first timestamp.

[0164] In this way, multi-parameter joint encryption (including dynamic random values ​​and verification codes) makes the eighth verification token unique and unpredictable, and the irreversibility of the one-way hash function prevents the token from being reverse-engineered. Binding the number of encryptions to the step size strengthens the correlation between the token and the preceding steps of the authentication process, ensuring that only a legitimate process that passes the step size verification can generate a matching token, effectively blocking the attack path of forged tokens and improving the security of the final verification stage of authentication.

[0165] In some embodiments, when calculating the step size, a hash value (List) of the first random value, the third timestamp, and the first timestamp is calculated using a third one-way hash function. Then, the hash values ​​are traversed to obtain the first character and the second character. The first character is the first character greater than or equal to the first threshold, and the second character is the first character less than or equal to the second threshold.

[0166] For example, starting from the first character of the List, iterate through each character and determine whether the character is greater than or equal to the threshold N (first threshold). If not, iterate through the next character. If yes, record the character as n (first character). Continue iterating through the next character and determine whether the character is less than or equal to the threshold M (second threshold). If not, iterate through the next character. If yes, record the character as m (second character).

[0167] After receiving the first and second characters, the server divides the first count value equally according to the first character to obtain the first segment. Then, it determines the second segment containing the first timestamp from the first segment. The second segment is then divided equally according to the second character to obtain the third segment. Finally, a fourth segment containing the first timestamp is determined from the third segment. The step size is then determined based on the fourth segment.

[0168] For example, on the timeline, align T1 with the time interval [Timestampe2`, Timestampe2]. Divide T1 into n segments 1. Since n ≥ N, there is a basic number of segments 1. Find the segment 1 that ends at the end of [Timestampe2`, Timestampe2] among all segments 1, and denote it as segment 10. Divide segment 10 into m segments 2. Since m ≤ M, the number of segments 2 is constrained, thus constraining the number of encryption operations (2). Find the segment 2 that ends at the end of [Timestampe2`, Timestampe2] among all segments 2, and denote it as segment 20. Let the order of segment 20 among all segments 2 be ΔT.

[0169] In this embodiment, when the server calculates the step size, it first generates a list of hash values ​​(List) of a first random value, a third timestamp, and the first timestamp using a third one-way hash function. It then iterates through these hash values, selecting the first character n (≥ the first threshold N) and the first character m (≤ the second threshold M). Subsequently, the first count value T1 is divided equally by n to obtain a first segment, from which a second segment containing the first timestamp is located. The second segment is then divided equally by m to obtain a third segment, and a fourth segment containing the first timestamp is located. Finally, the step size ΔT is determined by the order of the fourth segment.

[0170] In this way, by dynamically generating n and m through hash values, the randomness of step size calculation is ensured, preventing fixed patterns from being cracked; by constraining the range of n and m with N and M, the number of fragments can be controlled (e.g., n≥N ensures the basic segmentation granularity, m≤M limits the upper limit of encryption times), balancing security and efficiency; the fragment segmentation is bound to the first timestamp, making the step size strongly correlated with the current authentication time, preventing the step size from being reused or predicted, providing a dynamic and unique benchmark for subsequent encryption times, and strengthening the uniqueness of authentication verification.

[0171] In some embodiments, after receiving the second verification token sent by the client, the server compares the second verification token with the eighth verification token. If the second verification token matches the eighth verification token, the server sends a successful authentication result to the client and updates the first count value to the second count value (T1 = T1 - ΔT); if the second verification token does not match the eighth verification token, the server sends a failed authentication result to the client. The second count value is equal to the first count value minus the step size.

[0172] In this embodiment of the disclosure, after receiving the second verification token sent by the client, the server compares it with the eighth verification token it generated itself. If the two are consistent, the authentication is deemed successful, a success result is sent to the client, and the first count value is updated to the original first count value minus the step size of the second count value. If they are inconsistent, the authentication is deemed to have failed, and a failure result is sent to the client.

[0173] In this way, token consistency comparison is the final verification of the authentication process, ensuring that only legitimate requests that pass through the entire process (client generation, encryption by the security processing module, and matching by the server) can pass, thus blocking unauthorized access by forged tokens; while the first count value decreases dynamically with the step size, which not only limits the number of valid authentications of the same registration information, but also provides an updated benchmark for the validity period verification of subsequent authentications, further enhancing the security and controllability of authentication.

[0174] For the SIM side, in some embodiments, when the security processing module generates a second verification token based on the first verification token, it uses the identification information as an index to query the locally stored first key, third timestamp, and first count value. Then, based on the first random value, third timestamp, second timestamp, and first timestamp, it calculates the step size. The second verification token is then encrypted and generated according to the step size.

[0175] In this embodiment of the disclosure, when the security processing module generates the second verification token, it first uses the identification information as an index to query the pre-stored first key, third timestamp, and first count value locally; then, based on the first random value (generated by the client), the third timestamp (registration stage), the second timestamp (previous authentication), and the first timestamp (current authentication), it calculates the step size according to the same logic as the server; finally, based on the step size, it generates the second verification token through encryption operations.

[0176] In this way, local data query avoids the risk of leakage of sensitive information (such as the first key) transmission, thus improving data security; step-size calculation is synchronized with the server to ensure that the number of encryptions by both parties is consistent, providing a foundation for the consistency of subsequent token verification; dynamic encryption based on step-size makes the second verification token strongly bound to the current authentication scenario, possessing uniqueness and timeliness, effectively preventing token forgery or reuse attacks, and ensuring the reliability of three-party collaborative authentication.

[0177] In some embodiments, after the security processing module sends the second verification token to the client, if it receives a successful authentication result from the client, it updates the first count value to the second count value. The second count value is equal to the first count value minus the step size.

[0178] In this embodiment of the disclosure, after the security processing module sends the second verification token to the client, if it receives the authentication success result forwarded by the client, it will trigger a local count value update: subtract the step size of this authentication calculation from the original first count value to obtain the second count value, thus completing the dynamic adjustment of the first count value.

[0179] Based on the above embodiments, such as Figure 6 As shown, the certification phase may include the following steps S1-S10.

[0180] S1. When a user performs an operation on the Client and triggers a service, the Client queries the ServiceID of that service.

[0181] The Client generates a random value Salt3 and sends Message1 to the Server to request authentication in order to provide the corresponding services. Message1 carries Username, Password, ClientID, ServiceID, Salt3, and the timestamp of the last successful authentication, Timestampe2, i.e., Message1={Username,Password,ClientID,ServiceID,Salt3,Timestampe2}.

[0182] S2, Server queries and stores Salt2, SK, Token1, Token2, T1, and Timestampe1 based on the current Username, ClientID, and ServiceID.

[0183] The server reads the timestamp Timestampe2 from the local machine and determines whether Timestampe2-Timestampe1<Tt and Timestampe2-Timestampe2`<T1×Ts based on Timestampe1, Timestampe2` and Timestampe2. Here, Tt is the time threshold, which is a fixed empirical value, and Ts is the time coefficient, which is a fixed empirical value, such as 10000.

[0184] In some implementations, the validity period can be set from both dynamic and static dimensions. Tt is the static dimension, which is a long and fixed validity period, while T1×Ts is a short and dynamic validity period.

[0185] Each authentication attempt consumes a number of encryption attempts, and T1 decays accordingly, meaning the validity period also decays. Therefore, the previously successfully authenticated Timestampe2 can be used to determine if the validity period has expired. If the conditions are not met, it indicates that the validity period has expired, and an authentication failure is returned to the Client, notifying the Client to re-register. If the conditions are met, it indicates that the validity period has not expired, and authentication can continue.

[0186] In some implementations, a one-way hash function H1 is used to generate Token1` based on Password and Salt2, that is, Token1` = H1(Password, Salt2).

[0187] In some implementations, a one-way hash function H2 is used to generate Token2' based on ClientID, ServiceID, and Salt2, i.e., Token2' = H2(ClientID, ServiceID, Salt2).

[0188] If Token1`=Token1 and Token2`=Token2, then determine whether the ServiceID service needs two-factor authentication based on other business rules. If it does, send Message2 to the Client, indicating that the ServiceID service needs two-factor authentication. Message2 carries Timestampe2, i.e., Message2={Timestampe2}. Otherwise, return Failure to the Client.

[0189] S3: The Server generates a verification code Code and sends Message3 to the SIM. Message3 carries the Code, i.e., Message3={Code}.

[0190] In some implementations, the server sends a code to the SIM via SMS.

[0191] S4. The Server uses the Sequence Algorithm Seq to calculate the step size ΔT based on Salt3, Timestampe1, Timestampe2` and Timestampe2, that is, ΔT=Seq(Salt3,Timestampe1,Timestampe2`,Timestampe2).

[0192] Use a one-way hash function H to calculate a sufficiently long (e.g., 256 or 512 bits) hash value List for Salt3, Timestampe1, and Timestampe2, i.e., List = H(Salt3, Timestampe1, Timestampe2).

[0193] Starting from the first character of the List, iterate through each character, checking if it is greater than or equal to the threshold N. If not, move on to the next character. If it is, record the character as n and continue iterating through the next character. Check if the character is less than or equal to the threshold M. If not, move on to the next character. If it is, record the character as m. Figure 7 As shown, on the timeline, T1 is aligned with the time interval [Timestampe2`, Timestampe2]. T1 is divided into n segments 1. Since n≥N, there is a basic number of segments 1. The segment 1 that ends at [Timestampe2`, Timestampe2] is found among all segments 1 and denoted as segment 10. Segment 10 is divided into m segments 2. Since m≤M, the number of segments 2 is constrained, thus constraining the number of encryption operations (2). The segment 2 that ends at [Timestampe2`, Timestampe2] is found among all segments 2 and denoted as segment 20. The order of segment 20 among all segments 2 is set as ΔT.

[0194] By reusing the distribution relationship between timestamps and setting ΔT, the amount of data transmitted between different roles can be reduced, which helps to reduce the possibility of being attacked. Furthermore, the randomness of the timestamps is sufficient to make ΔT difficult to predict, resulting in high security.

[0195] For example, n=4, m=7, that is, divide T1 into 4 segments 1, the second segment 1 is segment 10, divide segment 10 into 7 segments 2, the fourth segment 2 is segment 20, then ΔT=4.

[0196] Determine if T1 - ΔT > 0. If not, it indicates that the encryption attempts have expired, and an authentication failure is returned to the Client, notifying the Client to re-register. If the encryption attempts have expired, authentication can continue. The Server generates a random value Salt4 and uses a one-way hash function H3 to encrypt Token1, Token2, Salt3, Salt4, and Code ΔT times based on SK, obtaining the signature Token3, i.e., Token3 = H3ΔTSK(,Token1,Token2,Salt3,Salt4,Code).

[0197] For example, if ΔT=3, then Token3=H3 SK (H3 SK (H3 SK (Token1,Token2,Salt3,Salt4)).

[0198] S5. Based on Message2, the Client prompts the user to enter the verification code Code on the UI. When the user enters the verification code Code, the Client queries Salt2 locally using ClientID and ServiceID as indexes.

[0199] In some implementations, a one-way hash function H1 is used to generate Token1`` based on Password and Salt2, that is, Token1``=H1(Password,Salt2).

[0200] In some implementations, a one-way hash function H2 is used to generate Token2`` based on ClientID, ServiceID, and Salt2, i.e., Token2`` = H2(ClientID, ServiceID, Salt2). The Client sends Message4 to the SIM, which carries ClientID, ServiceID, Token1, Token2, Salt3, Salt4, Code, Timestampe2, and Code, i.e., Message4 = {ClientID, ServiceID, Token1``, Token2``, Salt3, Salt4, Timestampe2`, Timestampe2, Code}.

[0201] S6 and SIM query SK, T1, and Timestampe1 locally based on ClientID and ServiceID.

[0202] In some implementations, the sequence algorithm Seq is used to calculate the step size ΔT based on Salt3, Timestampe1, Timestampe2` and Timestampe2, that is, ΔT=Seq(Salt3,Timestampe1,Timestampe2`,Timestampe2).

[0203] In some implementations, a one-way hash function H is used to calculate a sufficiently long (e.g., 256 or 512 bits) hash value List for Salt3, Timestampe1, and Timestampe2, i.e., List = H(Salt3, Timestampe1, Timestampe2).

[0204] Starting from the first character of the List, iterate through each character, checking if it is greater than or equal to the threshold N. If not, move on to the next character; if it is, record it as n and continue iterating. Check if the character is less than or equal to the threshold M; if not, move on to the next character; if it is, record it as m. On the timeline, align T1 with the time interval [Timestampe2`, Timestampe2]. Divide T1 into n segments 1. Since n ≥ N, there is a basic number of segments 1. Find the segment 1 that ends at the endpoint of [Timestampe2`, Timestampe2] and denote it as segment 10. Divide segment 10 into m segments 2. Since m ≤ M, the number of segments 2 is constrained, thus constraining the number of encryption attempts (2). Find the segment 2 that ends at the endpoint of [Timestampe2`, Timestampe2] and denote it as segment 20. Set the order of segment 20 among all segments 2 as ΔT. Check if T1 - ΔT > 0. If the conditions are not met, it means the encryption attempt has expired, and an authentication failure is returned to the client, notifying the client to re-register. If the conditions are met, it means the encryption attempt has not expired, and authentication can continue.

[0205] In some implementations, a one-way hash function H3 is used to encrypt Token1``, Token2``, Salt3, Salt4 and Code ΔT times based on SK to obtain the signature Token3`, that is, Token3`=H3ΔTSK (Token1``,Token2``,Salt3,Salt4,Code).

[0206] For example, if ΔT=3, then Token3=H3 SK (H3 SK (H3 SK (Token1``,Token2``,Salt3,Salt4))).

[0207] SIM sends Message5 to Client, which carries Token3, i.e., Message5 = {Token3}.

[0208] S7. The Client sends Message6 to the Server. Message6 carries Token3, that is, Message6={Token3}.

[0209] S8. The Server checks if Token3 = Token3'. If yes, the verification is successful (Success); otherwise, it is unsuccessful (Failure). The Server sends Message7 to the Client, carrying the success / failure information, i.e., Message7 = {Success / Failure}. Upon successful verification, ΔT is deducted from T1, i.e., T1 = T1 - ΔT.

[0210] S9. Based on Success, the Client stores Timestampe2 using ClientID and ServiceID as indexes, which will be used as Timestampe2' for the next authentication, i.e., Per = {ClientID, ServiceID - Timestampe2'}. It then sends Message8 to the SIM, carrying Success / Failure, i.e., Message8 = {Success / Failure}.

[0211] S10 and SIM deduct ΔT from T1 based on the success, i.e., T1 = T1 - ΔT. For failures, the Client re-initiates authentication. If the number of failures exceeds Q, an error is reported, and registration is restarted.

[0212] Based on the above embodiments, such as Figure 8 As shown, some embodiments of this application also provide an authentication device 800, including a sending module 801, a receiving module 802, and a processing module 803, wherein: The sending module 801 is configured to send an authentication request to the server in response to a service trigger event; The receiving module 802 is configured to receive a first timestamp fed back by the server based on the authentication request; Processing module 803 is configured to perform a first verification operation in response to the first timestamp, the first verification operation being used to prompt for input of a verification code; and to generate a first verification token in response to the completion of input of the verification code. The sending module 801 is also configured to send the first verification token to the security processing module; The receiving module 802 is also configured to receive a second verification token generated by the security processing module based on the first verification token; The sending module 801 is also configured to send the second verification token to the server so that the client, the server and the security processing module can jointly complete the identity authentication.

[0213] It should be noted that the foregoing explanation of the method embodiments also applies to the apparatus of the embodiments of this disclosure, and the principle is the same. Therefore, the embodiments of this disclosure are not limited thereto.

[0214] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0215] Figure 9 A schematic block diagram of an example electronic device 900 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0216] like Figure 9 As shown, the electronic device 900 includes a computing unit 901, which can perform various appropriate actions and processes based on a computer program stored in ROM (Read-Only Memory) 902 or loaded from storage unit 908 into RAM (Random Access Memory) 903. The RAM 903 can also store various programs and data required for the operation of the electronic device 900. The computing unit 901, ROM 902, and RAM 903 are interconnected via bus 904. An I / O (Input / Output) interface 905 is also connected to bus 904.

[0217] Multiple components in electronic device 900 are connected to I / O interface 905, including: input unit 906, such as keyboard, mouse, etc.; output unit 907, such as various types of displays, speakers, etc.; storage unit 908, such as disk, optical disk, etc.; and communication unit 909, such as network card, modem, wireless transceiver, etc. Communication unit 909 allows electronic device 900 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0218] The computing unit 901 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 901 include, but are not limited to, CPUs (Central Processing Units), GPUs (Graphics Processing Units), various special-purpose AI (Artificial Intelligence) computing chips, various computing units running machine learning model algorithms, DSPs (Digital Signal Processors), and any suitable processor, controller, microcontroller, etc. The computing unit 901 performs the various methods and processes described above, such as authentication methods. For example, in some embodiments, the authentication method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 908. In some embodiments, part or all of the computer program may be loaded and / or installed on the electronic device 900 via ROM 902 and / or communication unit 909. When the computer program is loaded into RAM 903 and executed by the computing unit 901, one or more steps of the methods described above may be performed. Alternatively, in other embodiments, the computing unit 901 may be configured to perform the aforementioned authentication method by any other suitable means (e.g., by means of firmware).

[0219] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, FPGAs (Field Programmable Gate Arrays), ASICs (Application-Specific Integrated Circuits), ASSPs (Application-Specific Standard Products), SOCs (System-on-Chips), CPLDs (Complex Programmable Logic Devices), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0220] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0221] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, RAM, ROM, EPROM (Electrically Programmable Read-Only Memory) or flash memory, optical fiber, CD-ROM (Compact Disc Read-Only Memory), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0222] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (Cathode-Ray Tube) or LCD (Liquid Crystal Display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0223] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include LANs (Local Area Networks), WANs (Wide Area Networks), the Internet, and blockchain networks.

[0224] Computer systems can include clients and servers. Clients and servers are generally geographically separated and typically interact via communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. A server can be a cloud server, also known as a cloud computing server or cloud host, a hosting product within the cloud computing service system that addresses the shortcomings of traditional physical hosts and VPS (Virtual Private Server) services, such as high management difficulty and weak business scalability. Servers can also be servers for distributed systems or servers incorporating blockchain technology.

[0225] It's important to note that artificial intelligence (AI) is the study of enabling computers to simulate certain human thought processes and intelligent behaviors (such as learning, reasoning, thinking, and planning). It encompasses both hardware and software technologies. AI hardware technologies generally include sensors, dedicated AI chips, cloud computing, distributed storage, and big data processing. AI software technologies primarily include computer vision, speech recognition, natural language processing, machine learning / deep learning, big data processing, and knowledge graph technologies.

[0226] As can be seen from the above technical solutions, the authentication method, electronic device, and storage medium disclosed in this application allow the method to respond to a service trigger event by sending an authentication request to the server and receiving a first timestamp from the server based on the authentication request. Then, in response to the first timestamp, the user is prompted to enter a verification code. Upon completion of the verification code input, a first verification token is generated and sent to the security processing module. Finally, a second verification token generated by the security processing module based on the first verification token is received and sent to the server, enabling the client, server, and security processing module to jointly complete identity authentication. By applying the technical solution of this application, replay attacks can be prevented through the first timestamp, and the dual verification tokens combined with the security processing module enable multi-terminal collaborative authentication, thereby effectively improving the security and reliability of identity authentication.

[0227] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0228] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. An authentication method, characterized in that, Applied to a client, the method includes: In response to a service-triggered event, an authentication request is sent to the server. Receive the first timestamp fed back by the server based on the authentication request; In response to the first timestamp, a first verification operation is performed; the first verification operation is used to prompt for the input of a verification code. Upon completion of the operation in response to the input of the verification code, a first verification token is generated; Send the first verification token to the security processing module; Receive the second verification token generated by the security processing module based on the first verification token; The second verification token is sent to the server so that the client, the server, and the security processing module can jointly complete the identity authentication.

2. The method according to claim 1, characterized in that, The authentication request carries user information, identification information, a first random value, and a second timestamp of the previous authentication; the first random value is a random value generated by the client in response to a service trigger event; the user information includes a username and a password; the identification information includes a client identifier and a service identifier; the service identifier corresponds to the service associated with the trigger event.

3. The method according to claim 1 or 2, characterized in that, Before sending the authentication request to the server, the process also includes: In response to a registration event, a registration request is sent to the security processing module; the registration request carries identification information. Receive the first key and third timestamp fed back by the security processing module based on the registration request; The registration data is sent to the server based on the user information, the identification information, the first key, and the third timestamp. Receive the second random value and the first count value fed back by the server based on the registration data; The second random value is stored, and the first count value is synchronized to the security processing module.

4. The method according to claim 2, characterized in that, The generation of the first verification token includes: Using the client identifier and service identifier as an index, query the second random value stored locally; Based on the user password and the second random value, the first sub-token is calculated using the first one-way hash function; Based on the client identifier, the service identifier, and the second random value, the second sub-token is calculated using the second one-way hash function; The first verification token is obtained based on the first sub-token and the second sub-token.

5. The method according to claim 1, characterized in that, After sending the second verification token to the server, the process further includes: Receive the authentication result fed back by the server based on the second verification token; If the authentication result indicates success, the first timestamp is stored using the client identifier and service identifier as an index; If the authentication result is characterized as a failure, the cumulative number of authentication failures is counted.

6. The method according to claim 5, characterized in that, The method further includes: If the number of authentication failures is greater than or equal to a preset threshold, a registration event is triggered.

7. An authentication method, characterized in that, Applied to the server side, the method includes: Receive authentication requests sent by clients; In response to the authentication request, the current timestamp is read to obtain the first timestamp; Generate a verification code based on the authentication request; Send the verification code to the security processing module and send the first timestamp to the client; The server receives a second verification token sent by the client, enabling the server, the client, and the security processing module to jointly complete identity authentication; the second verification token is a second verification token generated based on the first verification token; the first verification token is a verification token generated by the client in response to the input of the verification code.

8. The method according to claim 7, characterized in that, The authentication request carries user information, identification information, a first random value, and a second timestamp of the previous authentication; the user information includes a username and a password; the identification information includes a client identifier and a service identifier; The service identifier corresponds to the service associated with the authentication request; Before reading the current timestamp based on the authentication request, the process also includes: Using the username, client identifier, and service identifier as indexes, query the pre-stored related data locally; The associated data includes a second random value, a first key, a fourth verification token, a fifth verification token, a first count value, and a third timestamp.

9. The method according to claim 8, characterized in that, After reading the current timestamp, the process also includes: Calculate a first difference between the first timestamp and the third timestamp, and a second difference between the first timestamp and the second timestamp; If the first difference is less than the preset static time threshold, and the second difference is less than the product of the first count value and the preset time coefficient, the dual validity period verification is marked as passed. If the first difference is greater than or equal to a preset static time threshold, or the second difference is greater than or equal to the product of the first count value and the preset time coefficient, the dual validity period verification is marked as failed.

10. The method according to claim 9, characterized in that, If the dual validity period verification fails, the following also applies: Stop sending the first timestamp to the client; and send the authentication result indicating failure to the client.

11. The method according to claim 9, characterized in that, If the dual validity period verification passes, the step of sending the first timestamp to the client further includes: The sixth verification token is calculated using the first one-way hash function based on the user password and the second random value. Based on the client identifier, the service identifier, and the second random value stored locally, the seventh verification token is calculated using the second one-way hash function; If the sixth verification token matches the fourth verification token, and the seventh verification token matches the fifth verification token, then the verification code is generated; If the sixth verification token is inconsistent with the fourth verification token, stop sending the first timestamp to the client and send an authentication result indicating failure to the client.

12. The method according to claim 8, characterized in that, After sending the first timestamp to the client, the method further includes: The step size is calculated based on the first random value, the third timestamp, the second timestamp, and the first timestamp. If the first count value is less than or equal to the step size, then the authentication result indicating failure is returned to the client. If the first count value is greater than the step size, an eighth verification token is generated using the third one-way hash function.

13. The method according to claim 12, characterized in that, The generation of the eighth verification token through the third one-way hash function includes: Based on the third one-way hash function, the fourth verification token, the fifth verification token, the first random value, the fourth random value, and the verification code are encrypted a target number of times according to the first key; Wherein, the target number is equal to the step size; the fourth random value is a random value generated by the server after sending the first timestamp to the client.

14. The method according to claim 12, characterized in that, The calculation step size includes: The hash value of the first random value, the third timestamp, and the first timestamp is calculated using the third one-way hash function. The hash values ​​are traversed to obtain the first character and the second character; the first character is the first character greater than or equal to the first threshold, and the second character is the first character less than or equal to the second threshold; Divide the first count value equally according to the first character to obtain the first segment; A second segment containing the first timestamp is determined from the first segment; Divide the second segment into two equal parts according to the second character to obtain the third segment; A fourth segment containing the first timestamp is determined in the third segment; The step size is determined based on the fourth segment.

15. The method according to claim 12, characterized in that, After receiving the second verification token sent by the client, the process further includes: Compare the second verification token with the eighth verification token; If the second verification token matches the eighth verification token, a successful authentication result is sent to the client, and the first count value is updated to the second count value; the second count value is equal to the first count value minus the step size; If the second verification token is inconsistent with the eighth verification token, an authentication failure result is sent to the client.

16. The method according to claim 8, characterized in that, Before receiving the authentication request sent by the client, the method further includes: The system receives registration data sent by the client and generates the second random value; the registration data carries the user information, the identification information, the first key, and the third timestamp. The fourth verification token is calculated using the first one-way hash function based on the user password and the second random value. Furthermore, based on the identification information and the second random value, the fifth verification token is calculated using a second one-way hash function.

17. The method according to claim 16, characterized in that, After calculating the fifth verification token using the second one-way hash function, the process further includes: Query the preset mapping table and determine the corresponding counting range based on the service identifier; Obtain the lower limit and length of the counting range; Calculate the remainder between the first key and the length of the counting range; The first count value is obtained by summing the lower limit value and the remainder.

18. The method according to claim 17, characterized in that, Also includes: Using the user information and the identification information as indexes, the second random value, the first key, the fourth verification token, the fifth verification token, the first count value, and the third timestamp are stored to obtain the associated data; In addition, the second random value and the first count value are sent to the client.

19. An authentication method, characterized in that, Applied to a security processing module, the method includes: Receive the verification code sent by the server based on the authentication request; the authentication request is a request sent by the client to the server; Receive the first verification token sent by the client in response to the completion of the verification code input operation; Generate a second verification token based on the first verification token; The second verification token is sent to the client so that the client, the server, and the security processing module can jointly complete the identity authentication.

20. The method according to claim 19, characterized in that, The authentication request carries user information, identification information, a first random value, and a second timestamp of the previous authentication. The first timestamp is the timestamp of the current authentication; The step of generating a second verification token based on the first verification token includes: Using the identification information as an index, query the locally stored first key, third timestamp, and first count value; Calculate the step size based on the first random value, the third timestamp, the second timestamp, and the first timestamp; The second verification token is generated by encrypting according to the stated step size.

21. The method according to claim 20, characterized in that, Before the receiving server sends the verification code based on the authentication request, it also includes: Receive a registration request sent by the client; the registration request carries the identification information; The third random value is generated within a preset safety interval; Based on the identification information, user identification code, and the third random value, the first key is calculated using a key generation algorithm; Read the local timestamp to obtain the third timestamp; Send the first key and the third timestamp to the client, and receive the first count value synchronized by the client; The first key, the third timestamp, and the first count value are stored using the identification information as an index.

22. The method according to claim 20, characterized in that, After sending the second verification token to the client, the method further includes: If a successful authentication result is received from the client, the first count value is updated to a second count value; the second count value is equal to the first count value minus the step size.

23. An electronic device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the method of any one of claims 1-6, 7-18, or 20-22.

24. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-6, 7-18 or 20-22.

25. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method according to any one of claims 1-6, 7-18, or 20-22.

Images