A server, a client, an identity authentication method, system and device

Abstract

The application discloses a server identity authentication method, a client identity authentication method, a server, a client, a dynamic authentication system, a computer device and a computer program product. The server identity authentication method comprises the following steps: receiving a login request sent by a client and containing a user credential; performing verification processing on the user credential to obtain a verification result; when the verification result is successful, performing risk assessment to obtain a risk assessment result; when the risk assessment result is a high-risk environment, temporarily storing state information of successful verification and sending an authentication failure response message to the client, the authentication failure response message being consistent with a real authentication failure response in preset characteristics; receiving environment verification information; performing identity authenticity verification based on the environment verification information; and when the identity verification result is passed, returning an authentication success response to the client, the authentication failure response message being consistent with the real authentication failure response in the preset characteristics, so that runtime fraud prevention is realized and security is improved.

Description

Technical Field

[0001] This application relates to the fields of network security and identity authentication, specifically to a server identity authentication method, a client identity authentication method, a server, a client, a dynamic authentication system, a computer device, and a computer program product. Background Technology

[0002] With the widespread adoption of internet services, user authentication has become a core component of system security. Among current mainstream authentication methods, password-based methods have fixed logic, making them vulnerable to brute-force attacks, credential stuffing, or exploitation by batch scripts. Adaptive authentication methods typically expose risk states explicitly, allowing attackers to circumvent detection by analyzing responses or page changes to infer risk control strategies. Multi-factor authentication significantly degrades user experience and increases communication latency and interaction costs. Local security verification methods are usually executed on every login, leading to excessive terminal computing power consumption, which is detrimental to performance-sensitive mobile applications. Therefore, current mainstream authentication methods fail to balance security, performance, and user experience. Summary of the Invention

[0003] This application provides a server authentication method, a client authentication method, a server, a client, a dynamic authentication system, a computer device, and a computer program product.

[0004] In a first aspect, embodiments of this application provide a server authentication method. The server authentication method includes: receiving a login request containing user credentials sent by a client; verifying the user credentials to obtain a verification result; when the verification result is successful, performing a risk assessment based on the current login environment to obtain a risk assessment result; when the risk assessment result determines the environment to be high-risk, temporarily storing the successful verification status information and sending an authentication failure response message to the client, the authentication failure response message being consistent with a genuine authentication failure response in preset characteristics; receiving environment verification information sent by the client based on the authentication failure response message; performing identity verification based on the environment verification information to obtain an identity verification result; when the identity verification result is successful, activating the temporarily stored status information and returning an authentication success response to the client.

[0005] Secondly, embodiments of this application provide a client authentication method, the client authentication method comprising: sending a login request containing user credentials to a server, the login request being used by the server to verify the user credentials; receiving an authentication failure response message returned by the server; wherein the authentication failure response message is a message sent by the server to the client after temporarily storing the successful verification status information when the user credentials are successfully verified and the current login environment is determined to be high-risk, and the authentication failure response message is consistent with the real authentication failure response in preset characteristics; generating environment verification information based on the authentication failure response message; sending the environment verification information to the server so that the server performs identity authenticity verification based on the environment verification information; and receiving an authentication success response returned by the server; wherein the authentication success response is returned by the server after the identity authenticity verification is passed and the temporarily stored status information is activated.

[0006] Thirdly, embodiments of this application provide a server, the server including a processor and a memory. The memory stores a computer program, and the processor executes a server authentication method by calling the computer program stored in the memory. The server authentication method includes: receiving a login request containing user credentials sent by a client; verifying the user credentials to obtain a verification result; when the verification result is successful, performing a risk assessment based on the current login environment to obtain a risk assessment result; when the risk assessment result determines a high-risk environment, temporarily storing the successful verification status information and sending an authentication failure response message to the client, the authentication failure response message being consistent with a genuine authentication failure response in preset characteristics; receiving environment verification information sent by the client based on the authentication failure response message; performing identity authenticity verification based on the environment verification information to obtain an identity verification result; when the identity verification result is successful, activating the temporarily stored status information and returning an authentication success response to the client.

[0007] Fourthly, embodiments of this application provide a client, which includes a processor and a memory. The memory stores a computer program, and the processor executes a client authentication method by calling the computer program stored in the memory. The client authentication method includes: sending a login request containing user credentials to a server, the login request being used by the server to verify the user credentials; receiving an authentication failure response message returned by the server; wherein the authentication failure response message is a message sent by the server to the client after temporarily storing successful verification status information when the user credentials are successfully verified and the current login environment is determined to be high-risk, and the authentication failure response message is consistent with a real authentication failure response in preset characteristics; generating environment verification information based on the authentication failure response message; sending the environment verification information to the server so that the server performs identity verification based on the environment verification information; and receiving an authentication success response returned by the server; wherein the authentication success response is returned by the server after the identity verification is passed and the temporarily stored status information is activated.

[0008] Fifthly, embodiments of this application provide a dynamic authentication system. The dynamic authentication system includes the server and / or client described in any of the above embodiments.

[0009] Sixthly, embodiments of this application provide a computer device, the computer device including a processor and a memory, the memory storing a computer program, the processor executing a server authentication method and / or a client authentication method by calling the computer program stored in the memory. The server authentication method includes: receiving a login request containing user credentials sent by a client; verifying the user credentials to obtain a verification result; when the verification result is successful, performing a risk assessment based on the current login environment to obtain a risk assessment result; when the risk assessment result determines a high-risk environment, temporarily storing the successful verification status information and sending an authentication failure response message to the client, the authentication failure response message being consistent with a genuine authentication failure response in preset characteristics; receiving environment verification information sent by the client based on the authentication failure response message; performing identity verification based on the environment verification information to obtain an identity verification result; when the identity verification result is successful, activating the temporarily stored status information and returning an authentication success response to the client. The client authentication method includes: sending a login request containing user credentials to a server, the login request being used by the server to verify the user credentials; receiving an authentication failure response message returned by the server; wherein the authentication failure response message is a message sent by the server to the client after temporarily storing the successful verification status information when the user credentials are successfully verified and the current login environment is determined to be high-risk, and the authentication failure response message is consistent with the real authentication failure response in preset characteristics; generating environment verification information based on the authentication failure response message; sending the environment verification information to the server so that the server can perform identity verification based on the environment verification information; and receiving an authentication success response returned by the server; wherein the authentication success response is returned by the server after the identity verification is passed and the temporarily stored status information is activated.

[0010] In a seventh aspect, embodiments of this application provide a computer program product, including computer instructions, which, when executed by a processor, implement a server authentication method and / or a client authentication method. The server authentication method includes: receiving a login request containing user credentials sent by a client; verifying the user credentials to obtain a verification result; when the verification result is successful, performing a risk assessment based on the current login environment to obtain a risk assessment result; when the risk assessment result determines a high-risk environment, temporarily storing the successful verification status information and sending an authentication failure response message to the client, the authentication failure response message being consistent with a genuine authentication failure response in preset characteristics; receiving environment verification information sent by the client based on the authentication failure response message; performing identity verification based on the environment verification information to obtain an identity verification result; when the identity verification result is successful, activating the temporarily stored status information and returning an authentication success response to the client. The client authentication method includes: sending a login request containing user credentials to a server, the login request being used by the server to verify the user credentials; receiving an authentication failure response message returned by the server; wherein the authentication failure response message is a message sent by the server to the client after temporarily storing the successful verification status information when the user credentials are successfully verified and the current login environment is determined to be high-risk, and the authentication failure response message is consistent with the real authentication failure response in preset characteristics; generating environment verification information based on the authentication failure response message; sending the environment verification information to the server so that the server can perform identity verification based on the environment verification information; and receiving an authentication success response returned by the server; wherein the authentication success response is returned by the server after the identity verification is passed and the temporarily stored status information is activated.

[0011] In the server authentication method, client authentication method, server, client, dynamic authentication system, computer device, and computer program product provided in this application embodiment, the authentication failure response message and the real authentication failure response are consistent in preset characteristics. This enables runtime deception defense against attackers, does not explicitly expose the control logic of the authentication method, and resists automated cracking and reverse attacks, thereby confusing attackers and triggering implicit challenges. The environment verification information is generated by the client and does not require user interaction. It can perform secondary authentication based on the environment verification information without affecting the normal user experience, thereby achieving a dynamic balance between security, performance, and user experience. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a schematic diagram of an example dynamic authentication system provided in an embodiment of this application.

[0014] Figure 2 This is an interactive schematic diagram of the identity authentication method provided in the embodiments of this application.

[0015] Figure 3 This is a flowchart illustrating the identity authentication method provided in an embodiment of this application.

[0016] Figure 4 This is a flowchart illustrating the identity authentication method provided in an embodiment of this application.

[0017] Figure 5 This is a flowchart illustrating the identity authentication method provided in an embodiment of this application.

[0018] Figure 6 This is a flowchart illustrating the identity authentication method provided in an embodiment of this application.

[0019] Figure 7 This is a flowchart illustrating the identity authentication method provided in an embodiment of this application.

[0020] Figure 8 This is a schematic diagram of the authentication system provided in an embodiment of this application.

[0021] Figure 9 A schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0022] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0023] This application provides a server authentication method, a client authentication method, a server 100, a client 200, a dynamic authentication system 1000, a computer device 300, and a computer program product. Specifically, the authentication method of this application embodiment can be executed by the computer device 300, which can be a terminal or a server 100, etc. The terminal can be a smartphone, tablet, laptop, smart TV, wearable smart device, smart vehicle terminal, etc. The terminal can also include a client 200, which can be a game client, browser client, instant messaging client, or applet, etc. The server 100 can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms.

[0024] For example, when this authentication method runs on a terminal device, the terminal device may include a display screen and a processor. The display screen is used to present a login request generation interface and receive instructions from the user regarding the login request generation interface. The login request generation interface may include a prompt input interface, a login request display interface, etc. The processor is used to store the login request generation program, run the login request generation method, generate the login request generation interface, respond to instructions, and control the display of the login request generation interface on the display screen. When the user operates the login request generation interface through the display screen, the login request generation interface can control the local content of the terminal device in response to the received operation instructions. The terminal device can provide the login request generation interface to the user in various ways, such as rendering it on the terminal device's display screen or presenting the login request generation interface through holographic projection.

[0025] For example, when the authentication method runs on server 100, it can be implemented and executed based on a cloud generation system. A cloud generation system refers to a generation method based on cloud computing. The cloud generation system includes a server and client devices. The main body running the login request generation program and the main body presenting the login request generation interface are separate. The storage and execution of the login request generation method are completed on server 100. The presentation of the login request generation interface is completed on client 200. Client 200 is mainly used for receiving and sending data for presenting the login request generation interface. For example, client 200 can be a display device with data transmission capabilities located close to the user, such as a mobile terminal, television, computer, PDA, personal digital assistant, head-mounted display device, etc. However, the terminal device for data processing is server 100 in the cloud. When generating a login request, the user operates client 200 to send instructions to server 100. Server 100 controls the execution of the login request generation method according to the instructions, encodes and compresses the data such as the login request generation interface, returns it to client 200 via the network, and finally, client 200 decodes and outputs the login request generation interface.

[0026] It should be noted that in this embodiment, the execution subject of the login request generation method can be a terminal device or a server 100. The terminal device can be a local terminal device or a client device (i.e., client 200) in the aforementioned cloud generation system. This embodiment does not limit the type of execution subject. This document uses client 200 as the terminal for explanation, highlighting the beneficial effects of including client 200 as the terminal.

[0027] It is understood that in the specific implementation of this application, user object data, context data and other related data are involved. When the embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0028] For example, in conjunction with the above description, Figure 1 An authentication system 1000 for implementing an identity authentication method, according to an embodiment of this application, is illustrated. The authentication system 1000 may include at least one server 100, at least one terminal, at least one database, and a network. A user-held terminal can connect to different servers 100 via the network. The terminal can be any device with computing hardware.

[0029] Furthermore, when the authentication system 1000 includes multiple servers 100, multiple clients 200, and multiple networks, different clients 200 can connect to each other through different networks and different servers 100. The network can be a wireless network or a wired network, such as a wireless local area network (WLAN), local area network (LAN), cellular network, 2G network, 3G network, 4G network, 5G network, etc. Additionally, different clients 200 can also connect to other terminals or to the server 100 using their own Bluetooth network or hotspot network. Furthermore, the system 100 can include multiple databases, which are coupled to different servers 100, and can continuously store game-related information in the databases while different users are playing multi-user games online.

[0030] It should be noted that, Figure 1 The schematic diagram of the authentication system 1000 shown is merely an example. The authentication system 1000 described in this application embodiment is for the purpose of more clearly illustrating the technical solutions of this application embodiment and does not constitute a limitation on the technical solutions provided in this application embodiment. As those skilled in the art will know, with the evolution of the authentication system 1000 and the emergence of new business scenarios, the technical solutions provided in this application embodiment are also applicable to similar technical problems.

[0031] The technical solution of this application will be described in detail below through specific embodiments. It should be noted that the following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0032] With the widespread adoption of internet services, user authentication has become a core component of system security. Most current mainstream online authentication systems employ a password-based authentication (PA) mechanism, where the server verifies the username and password submitted by the client. If the password is correct, it returns a successful authentication result; otherwise, it returns a failure response. In traditional authentication systems, the semantics of the authentication response are deterministic and predictable—success if the password is correct, failure if the password is incorrect. While this determinism improves system interaction efficiency, it can also be exploited by automated attack tools. For example: (1) Brute Force (BF) and Credential Stuffing (CS): Attackers try different password combinations in batches and rely on the "incorrect password" or "successful login" result returned by the server to quickly determine whether the password is correct, thereby obtaining a batch of valid accounts in a short period of time.

[0033] (2) Automated script identification and reverse engineering: For mobile applications or software development kits (SDKs), attackers can accurately identify the authentication status by analyzing the return packets or hooking the login interface. Then, by combining simulated input, debugging, or decompilation techniques, they can achieve exhaustive testing of real user passwords or batch login. HOOK specifically refers to API hijacking code implanted by modifying system API calls, runtime libraries, or application logic. It is used to intercept, tamper with, or forge normal call processes, thereby enabling attackers to bypass security detection, inject malicious behavior, or read sensitive data. The server 100 detects the existence of such Hook flags to determine whether the current environment is being dynamically debugged or injected, thereby reducing the credibility of the environment and triggering corresponding deceptive responses and secondary computing power verification processes.

[0034] (3) High-frequency small-amount attacks and environment switching: Some attackers use different devices, Internet Protocol Addresses (IPs), or proxy environments to perform a large number of small-amount attempts in a short period of time, taking advantage of the latency and gray-scale nature of conventional risk control systems to break through authentication defenses. To mitigate the above risks, existing technologies have proposed a variety of improvement schemes, such as: (1) Risk-based Adaptive Authentication (AA): By assessing factors such as device, geographical location, and behavior, multi-factor authentication steps are added when the risk is high, such as SMS verification code, one-time password (OTP), human-machine verification (CAPTCHA), etc.

[0035] (2) Generic Error Message (GEM): To prevent attackers from distinguishing between “incorrect username” and “incorrect password”, server 100 returns a vague message when authentication fails, such as “invalid username or password”.

[0036] (3) Local device fingerprint and integrity verification: By collecting information such as device fingerprint, application signature, and root detection results, the device trustworthiness identification is improved.

[0037] However, these methods still have the following problems: Adaptive authentication usually exposes the risk status, and attackers can infer the risk control strategy by analyzing the response or page changes, thereby circumventing detection; Multi-factor authentication significantly reduces user experience, increases communication latency and interaction costs, resulting in a decline in user experience and an increase in authentication latency; Local security verification is usually performed every time you log in, resulting in excessive terminal computing power consumption, which is not conducive to performance-sensitive mobile applications; Traditional systems still maintain the logic of "correct password will definitely succeed", which allows attackers to immediately confirm the cracking result at runtime.

[0038] Therefore, the core technical problem to be solved by this application is: how to enable the server 100 to perform runtime deception against attackers in a high-risk environment without affecting the normal user experience, and to securely confirm the real user's identity through the adaptive verification mechanism of the client 200, thereby achieving a dynamic balance between security, performance and experience.

[0039] Please see Figures 1 to 9 , Figure 1 and Figure 2 This is an interactive schematic diagram of the identity authentication method provided in the embodiments of this application. Figures 3 to 7 This is a flowchart illustrating an identity authentication method provided in an embodiment of this application. It should be noted that the steps shown may be executed in a logical order different from that shown in the flowchart. The method may include the following steps: Step 01: Receive the login request containing user credentials sent by the client; Step 02: Verify the user credentials and obtain the verification result; Step 04: When the verification result is successful, perform a risk assessment based on the current login environment to obtain the risk assessment result; Step 05: When the risk assessment result determines that the environment is high-risk, the successful verification status information is temporarily stored, and an authentication failure response message is sent to the client. The authentication failure response message is consistent with the real authentication failure response in terms of preset characteristics. Step 06: Receive environment verification information sent by the client based on the authentication failure response message; Step 07: Verify the authenticity of the identity based on the environment verification information to obtain the identity verification result; Step 08: When the authentication result is successful, activate the temporarily stored status information and return an authentication success response to the client.

[0040] Specifically, login requests include at least three categories: user credentials (traditional authentication data), trusted data from client 200, and client computing power verification request information. User credentials include, but are not limited to: user identifiers (such as account, mobile phone number, email address, User Identifier (UID), etc.), user-entered passwords, verification codes, fingerprint tokens, etc., and login method identifiers (password login / SMS login / one-click login / Open Authorization (OAuth) / Single Sign-On (SSO), etc.). Trusted data from client 200 includes, but is not limited to: system and device fingerprint information (such as system version, device model, or hardware characteristics), risk indication data (root detection, hook detection, or virtual machine / emulator detection), application integrity status (signature verification, binary verification, or debug status), runtime behavior data (launch method, application installation list, etc.), and network environment information (IP, Domain Name System (DNS), proxy, Virtual Private Network (VPN), or accelerator, etc.). The client computing power verification request information includes, but is not limited to: client computing power specifications (number of CPU cores, frequency, whether specific instruction sets are supported), the executable environment of the browser / web page view or application (App), and the client's 200 Proof of Capability to Execute Puzzle / PoW. Optionally, the user credentials in this application shall include at least a password.

[0041] The server performs parallel verification on 100 login requests, with three possible results: a genuine authentication failure response is returned if the user credentials are incorrect; a success response is returned if the verification result is successful and the risk assessment classifies the environment as low-risk; and an authentication failure response message is returned if the verification result is successful but the risk assessment classifies the environment as high-risk. Genuine authentication failure responses and authentication failure response messages maintain consistency in preset characteristics, preventing attackers from inferring the correctness of the login request based on response differences. In some implementations, preset characteristics include, but are not limited to, one or more of the following: response format, error code, response latency, and response header information.

[0042] Client 200 generates environment verification information through local computing power verification. This local computing power verification is triggered based on preset conditions (internal features described later), and is not necessarily triggered with every authentication failure response message, thus avoiding unnecessary burden on the user. The environment verification information is used for secondary verification. The local computing power verification process is completed by client 200 without user interaction or input. Server 100 verifies the authenticity of the identity based on the environment verification information. If the verification passes, it returns a successful authentication response to client 200; otherwise, it returns a failed authentication response. This combines the advantages of deception defense and adaptive environment authentication, not only combating automated cracking and reverse engineering attacks but also improving overall security and user experience without explicitly exposing risk control logic.

[0043] The status information is the authentication conclusion data that server 100 temporarily suspends and does not immediately issue after successfully verifying user credentials, due to the current login environment being deemed high-risk. Status information includes, but is not limited to, the verified user identifier, pre-assigned access permissions, session context, and the timestamp of successful verification. In practice, server 100 generates a unique session suspension identifier and associates the successful verification status information with this identifier, thus placing the authentication process in a securely isolated intermediate state. This ensures that even in a high-risk environment, if the credentials are correct, the true authentication status will not be immediately exposed; instead, a deception defense is implemented by sending an authentication failure response message to client 200. When the authentication result is successful, indicating that client 200 has successfully passed the environment authenticity verification, server 100 then activates the temporarily stored status information based on the session suspension identifier contained in the environment verification information, making the suspended authentication conclusion effective, and returns a final authentication success response to client 200, thereby restoring normal business access after eliminating environmental risks.

[0044] In the authentication method of this application, server 100 returns an authentication failure response message when the verification result is successful. The authentication failure response message is consistent with the real authentication failure response in terms of preset characteristics, which can achieve runtime deception defense against attackers, without explicitly exposing the control logic of the authentication method, resisting automated cracking and reverse attacks, so as to confuse attackers and trigger implicit challenges. The environment verification information is generated locally by client 200 without interacting with the user. It can perform secondary authentication based on environment verification information without affecting the normal user experience, thereby achieving a dynamic balance between security, performance and user experience.

[0045] Please see Figure 4 and Figure 8In some embodiments, a risk assessment is performed based on the current login environment to obtain a risk assessment result, including: Step 041: Obtain the client's device fingerprint information and network behavior characteristics; Step 043: Compare and analyze the device fingerprint information with historical login records to calculate the device consistency score; Step 045: Identify automated attack behavior patterns based on network behavior characteristics and calculate network behavior anomaly scores; Step 047: Calculate the environmental risk score based on the device consistency score and network behavior anomaly score, using preset weighted parameters; Step 049: When the environmental risk score exceeds the preset threshold, the risk assessment result is determined to be a high-risk environment.

[0046] This application uses a machine learning model to determine the risk assessment results. The machine learning model is a pre-set model within server 100 used to determine the risk assessment results.

[0047] Optionally, device fingerprint information may include one or more of the following: operating system information, browser information, hardware configuration information, and software environment information. Network behavior characteristics may include one or more of the following: IP address geographic location, network latency pattern, and request frequency. Device fingerprint information is used to determine whether the login request was sent by an emulator / cloud phone / Hook. Optionally, the machine learning model receives input from two sources: the credential verification module 110 and the client 200. The credential verification module 110 is a built-in module of the server 100, and the client 200 can pass through to the server 100 via its entry point. Input from the credential verification module 110 includes credential verification status, error type analysis results, and behavioral characteristics. The credential verification status includes options such as correct, incorrect, locked, expired, or other abnormalities. Behavioral characteristics are used to determine whether the current behavior is "non-human script behavior." Network behavioral characteristics include, but are not limited to, password attempt frequency, recent consecutive failure count, input time interval, and incorrect password dictionary characteristics. The input time interval is used to determine if the input time interval is too short, and the incorrect password dictionary characteristics are used to determine if it matches credential stuffing attacks. Input from the client 200 includes device fingerprint information (env_report), computing power proof information (sign), and network environment characteristics. Network environment characteristics include, but are not limited to, IP address, user agent (UA), geographic location, Domain Name System (DNS) / proxy, VPN, etc. After inputting the credential verification status, error type analysis results, behavioral characteristics, device fingerprint information env_report, computing power proof information sign, and network environment characteristics into the machine learning model, the machine learning model can comprehensively score the above inputs and output environmental risk score, risk level, and risk assessment results to evaluate the risk assessment results.

[0048] Optionally, the input to the machine learning model includes various environmental and behavioral factors, such as: Environment Trust Score (ETS), device anomaly indicators (e.g., root, hook, virtual machine), Computation Proof Consistency (CPC) based on computing power verification, Network Risk Level (NRL), and User Historical Behavior Risk (BR). The machine learning model calculates the environmental risk score, maps the environmental risk score to a risk level, and then obtains a risk assessment result based on the risk. The environmental risk score is a comprehensive score value (e.g., 0~100), based on the weighted sum of credential results, environmental trust, computing power verification, and behavioral analysis. The higher the environmental risk score (risk_score), the greater the probability of a high-risk risk assessment result. Optionally, the following formula for calculating the environmental risk score can be used: risk_score=w1×(100 ETS)+w2×BR+w3×NRL+w4×(1 CPC)×100+w5.

[0049] risk_score is the environmental risk score, and w1, w2, w3, w4 and w5 are weighted parameters for each risk dimension, which can be dynamically adjusted.

[0050] Optionally, the machine learning model compares and analyzes device fingerprint information with historical login records to calculate a device consistency score. This score measures the deviation between the current device environment and historically trusted environments. Simultaneously, the machine learning model identifies automated attack patterns (such as credential stuffing attacks, excessively short input intervals, etc.) based on network behavior characteristics, calculating a network behavior anomaly score. The machine learning model calculates the final environmental risk score based on the device consistency score and the network behavior anomaly score, combined with preset weighting parameters. The environmental risk score is a comprehensive score (e.g., 0-100); the higher the score, the greater the likelihood of a high-risk environment. For example, the environmental risk score can be calculated using a weighted summation formula: risk_score = w6 × device consistency score + w7 × network behavior anomaly score + w8, where w6, w7, and w8 are weighting parameters that can be dynamically adjusted based on historical attack data. When the environmental risk score exceeds a preset threshold, the risk assessment result is determined to be a high-risk environment.

[0051] Optionally, the machine learning model can also use machine learning algorithms (such as logistic regression model, random forest model, gradient boosting model, etc.) to comprehensively score the input of the above machine learning model and output an environmental risk score of 0 to 100.

[0052] The risk level maps the environmental risk score to a level, which can be optionally categorized as low, medium, high, or critical. The risk assessment result includes four outcomes: pass, challenge, deception, and reject. For example, if the risk assessment result is "issued a second authentication challenge," indicating a high-risk environment, the server will send an authentication failure response message to the client.

[0053] Optionally, the server has preset thresholds. The risk assessment result indicates a high-risk environment, which triggers the return of an authentication failure response message to the client that is consistent with the user's credential error. This can achieve millisecond-level identification and traffic diversion, which not only avoids excessive disturbance to normal users, but also ensures that even if the verification result is successful, attackers cannot continue to exhaustively search based on the difference in the authentication failure response message, thus achieving a dynamic balance between security, performance and user experience.

[0054] Please see Figure 5 and Figure 8 In some embodiments, obtaining the preset threshold includes: Step 0491: Collect historical login information and attack behavior information; Step 0493: Train a machine learning model based on historical login information and attack behavior information; Step 0495: Use a machine learning model to dynamically adjust the preset threshold of the environmental risk score.

[0055] In step 0491, historical login information represents the legitimate access patterns of normal users, including but not limited to commonly used device fingerprint features, stable network geographic location trajectories, and operation latency consistent with human interaction logic. Attack behavior information represents known security threat patterns, including but not limited to access records from malicious IP pools, credential dictionary features exhibited in credential stuffing attacks, non-human operation patterns simulated by automated scripts, and known illegal device environment markers.

[0056] In step 0493, server 100 trains the machine learning model based on the collected historical login information and attack behavior information. Optionally, server 100 cleans, reduces dimensionality, and extracts features from the raw data (the collected historical login information and attack behavior information), transforming the raw data into numerical feature vectors that the model can recognize. Subsequently, iterative optimization is performed on the labeled historical sample dataset using algorithms such as random forest, logistic regression, or gradient boosting decision trees. In this way, the machine learning model can automatically learn and establish a mapping relationship between environmental characteristics and risk levels.

[0057] In step 0495, the machine learning model can dynamically adjust the preset threshold to better suit the server's requirements. Optionally, when the server repeatedly determines the risk assessment result as a high-risk environment within a short period, the machine learning model will automatically output an adjustment command to lower the preset threshold, thereby making the server more sensitive to potentially high-risk environments. Conversely, when the server does not determine the risk assessment result as a high-risk environment for a long period, the machine learning model can appropriately raise the preset threshold to reduce interference with normal users, thus achieving an adaptive balance between security and user experience in the defense strategy while ensuring system security. Please see Figure 6 and Figure 8 In some embodiments, the successful verification status information is temporarily stored, including: Step 051: Generate a unique session suspension identifier; Step 053: Establish an association between the successful verification status information and the session suspension identifier; Step 055: Store the association in the cache and set an expiration time.

[0058] Specifically, server 100 generates a unique session suspension identifier. This identifier is typically a system-generated random unique string (such as a UUID) used to uniquely identify sessions that have successfully authenticated but were suspended due to environmental risks during login requests. It serves as a key index for subsequent identity verification. Server 100 establishes an association between the successfully authenticated status information and the session suspension identifier. Through this association, server 100 can match the session suspension identifier with the status information, ensuring that the corresponding status information is activated after successful authentication. Caching refers to a constant-speed in-memory storage system like Redis, used to temporarily store associations for fast access. The expiration time is the effective lifespan (TTL) of the association. After the expiration time, the association will automatically become invalid and be cleaned up, preventing attackers from using expired identifiers for replay attacks.

[0059] Please see Figure 6 and Figure 8 In some embodiments, triggering local computing power verification includes: Step 051: Respond to the failure response and detect internal features; and Step 053: If the internal features match the suspicious pattern, trigger local computing power verification.

[0060] Client 200 typically encounters the following issues: a large number of users enter the wrong password (user credentials) 1-3 times per day; users on mobile phones and computers may experience accidental touches, network latency, on-screen keyboard errors, and capitalization issues. These errors can cause login requests sent from client 200 to server 100 to fail. If local computing power verification is triggered solely based on "incorrect user credentials," it will increase the user's computational burden, significantly degrade the user experience, and create unnecessary pressure on server 100. By triggering local computing power verification under the dual conditions of "incorrect user credentials + internal characteristics matching a suspicious pattern", the client 200 can more accurately identify hacker attacks and reduce the occurrence of local computing power verification triggered by mis-input issues.

[0061] Incorrect passwords under hacker attacks often exhibit one or more of the following characteristics: Temporal behavioral characteristics: 1) Continuous attempts within a short period, with three failures occurring within 200ms; device behavior is inconsistent with manual operation, often a temporal behavioral characteristic of script or cloud phone automated attacks; 2) Incorrect passwords match dictionary attack characteristics: passwords come from common credential stuffing password sets, the attempt sequence shows an increasing or traversal pattern, often consistent with black market attack models; 3) The current device is in a suspicious environment: hooked / rooted / emulator / automated call chain / proxy / VPN / signature modified. These can all be considered internal characteristics.

[0062] Therefore, "user credential error" only indicates a mismatch in authentication credentials and is insufficient to definitively prove the existence of a hacker attack. To avoid interfering with legitimate users, the client 200 reports internal characteristics along with the "user credential error" message. These internal characteristics include, but are not limited to, environmental fingerprints, runtime behavior characteristics, call chain consistency, or device trustworthiness scores, as well as the characteristics described in the previous paragraph that can serve as internal characteristics. The suspicious pattern characterizes the client 200's preset judgment logic regarding these internal characteristics. Local computing power verification is only triggered when the internal characteristics match the suspicious pattern. This avoids false positives, increases the cost for attackers, and effectively suppresses brute-force attacks, automated script attacks, and emulator attacks.

[0063] Please see Figure 7 and Figure 8 In some embodiments, identity verification is performed based on environmental verification information to obtain an identity verification result, including: Step 071: Verify the consistency between the device fingerprint information and the historical records, and obtain the consistency verification result; Step 073: Verify the correctness of the computing power proof information and obtain the correctness verification result; Step 075: Check the correlation between the device fingerprint information and the computing power proof information, and obtain the correlation check results; Step 077: When the consistency verification result, correctness verification result, and correlation check result are all passed, the authentication result is determined to be successful.

[0064] Environment features are used to construct the environment fingerprint (env_fingerprint). These features include, but are not limited to: a. Device fingerprint information, such as device model, system version, read-only memory information (ROM information), CPU / application binary interface information (ABI), or unique device identifiers (such as Android Identifier (Android ID), hardware fingerprint digest); b. Application integrity information, such as application signature digest (App Signature Hash), package name, version number, installation source, or binary integrity verification information (executable file hash (DEX hash, dex hash), shared object file hash (shared object hash, so hash), etc.); c. Runtime environment features, such as root / jailbreak detection results, hook / debug detection flags, virtual machine / emulator features, call chain hash, or network environment indications (proxy, VPN, or DNS, etc.).

[0065] The environment fingerprint `env_fingerprint` is a hash digest obtained by concatenating various device characteristics, runtime security status, and network environment characteristics collected locally by the client (e.g., 2000). Optionally, a hash digest is performed on the concatenated environment features: `env_fingerprint = SHA256(all_environment_features)`, where `all_environment_features` is the result of concatenating the environment features. The hash digest yields a 32-byte environment fingerprint `env_fingerprint`.

[0066] The environment fingerprint (env_fingerprint) characterizes the uniqueness and trustworthiness of the client 200's current login environment, and is used by the server 100 to determine whether the client 200's current login environment has been forged or copied. The environment fingerprint (env_fingerprint) includes, but is not limited to, device hardware characteristic digests, system version information digests, root / hook / virtual machine flags, application signature digests, and CPU information.

[0067] Optional, env_fingerprint = SHA256(device_info+ app_signature+ runtime_features).

[0068] Client 200 performs a lightweight encryption, which includes, but is not limited to, Hash-based Message Authentication Code-Secure Hash Algorithm 256 (HMAC-SHA256), SHA256-based Proof of Work (SHA256-based PoW), Elliptic Curve Cryptography (ECC) signatures, or a computational puzzle task with a number used once (nonce), generating sign = SHA256(env_fingerprint + nonce + timestamp) or proof = HMAC_SHA256(seed, env_fingerprint). Here, sign represents the computational proof information; optionally, this application uses the computational proof information sign.

[0069] The environment fingerprint `env_fingerprint` contains digested environment parameters (such as `root_flag`, `hook_flag`, `vm_flag`), client 200 computing power parameters, timestamp, nonce, etc., which are then encapsulated to form the device fingerprint information `env_report`. Optionally, `env_report = {env_fingerprint, flags(root / hook / vm), cpu_info, timestamp, nonce,}`, where `cpu_info` is the device computing power digest from the client 200 computing power parameters, `timestamp` is the current timestamp, and `nonce` is a one-time, unpredictable random value generated by server 100 and sent to client 200, used for binding time series. The time series factor includes at least the current timestamp and the random value. The device fingerprint information `env_report` is generated by client 200 during the enhanced verification phase. Its calculation process includes: collecting device and runtime characteristics, standardizing these characteristics, hashing the standardized characteristics to obtain the environment fingerprint `env_fingerprint`, and combining the environment fingerprint `env_fingerprint` with security flags (root, hook, vm, etc.), CPU information `cpu_info` (i.e., the device's computing power digest), the current timestamp, and a random value `nonce` to form the device fingerprint information `env_report`. Server 100 verifies the consistency and authenticity of the device fingerprint information `env_report` to determine whether the client 200's operating environment is trustworthy. The computing power proof information `sign` is an HMAC or SHA256 signature calculated based on `env_fingerprint`, `nonce`, and `timestamp`. Optionally, an ECC signature or other cryptographic proof can also be used. The computing power proof information `sign` is used by server 100 to determine: whether client 200 has executed a real computing power task, whether the environment fingerprint has been tampered with, and whether it is in a script attack / virtual machine / cloud phone environment, etc.

[0070] In this system, after server 100 confirms that the verification result is successful and the risk assessment result is determined to be a high-risk environment, it marks the session as "suspended", generates a unique session suspension identifier and temporarily stores it in the cache, does not generate a login state, and prevents the high-risk environment from directly obtaining the access token; the session only retains the user ID, timestamp and random number, occupies little memory, and is automatically deleted after timeout to avoid long-term occupation of resources.

[0071] Optionally, the verification of the computing power proof information sign includes verifying the correctness of the device fingerprint information. Optionally, the server 100 stores a pre-stored key verification signature. If the server 100 confirms that the computing power proof information sign is consistent with the pre-stored key verification signature, it means that the verification was completed locally by the client 200 and the data has not been tampered with, and then the correctness verification result can be obtained.

[0072] Optionally, the verification of the device fingerprint information env_report includes verifying the consistency between the device fingerprint information and historical records. This includes, but is not limited to, comparing the root, hook, vm flags, and CPU information in the device fingerprint information env_report with those in the initial message. If they match, the server can obtain the consistency verification result. Optionally, it can also check whether the timestamp drift and one-time nonce of the device fingerprint information env_report and historical records are duplicated. If any of the above checks fail, the suspended session is immediately cleared to prevent replay or spoofed activation.

[0073] Optionally, server 100 checks the correlation between the device fingerprint information and the computing power proof information. Server 100 verifies the correlation check result by checking whether the generation parameters of the computing power proof information "sign" are consistent with the corresponding data contained in the device fingerprint information "env_report". When the computing power proof information "sign", the device fingerprint information "env_report", and the correlation check result are verified successfully, server 100 outputs the authentication result as "verification successful".

[0074] In some embodiments, it also includes: Record events where the password is correct and the environment's trust level is below a preset threshold; and Record the probability of passing the environment verification information, and record the ratio of the number of times the local computing power verification is triggered to the number of times a login request is obtained.

[0075] Specifically, the ratio = number of "fake failures" ÷ total number of login attempts. The number of "fake failures" refers to the number of times the client returned a 200 authentication failure response message consistent with incorrect user credentials. The total number of login attempts refers to the number of login requests made. A high ratio indicates that the "fake failure" mechanism of this invention is heavily involved, and attackers cannot determine the correctness of user credentials through the login response. More specifically, a high ratio indicates that many high-risk environments have been identified, including: cloud phones, emulators, hooks, root access, automated scripts, and high-risk IPs. A high ratio also indicates a high proportion of attack traffic, suggesting that the deceptive response is effective and many attackers are being kept in the dark. A low ratio indicates that the "fake failure" mechanism is not overly involved, and normal users will not be affected. More specifically, a low ratio indicates that the vast majority of user environments are normal; server 100 only performs fake failure processing on a small number of environments; it indicates fewer attacks, or that the threshold of server 100's machine learning model is high.

[0076] Please see Figure 2 and Figure 8 A client 200 authentication method, characterized in that it includes: Send a login request containing user credentials to server 100. The login request is used by server 100 to verify the user credentials. Receive authentication failure response message returned by server 100; wherein, the authentication failure response message is a message sent by server 100 to the client after temporarily storing the successful authentication status information when the user credential verification is successful and the current login environment is determined to be high risk, and the authentication failure response message is consistent with the real authentication failure response in preset characteristics. Generate environment verification information based on the authentication failure response message; Send environment verification information to server 100 so that the server can verify the authenticity of the identity based on the environment verification information; and Receive a successful authentication response from server 100; the successful authentication response is returned by server 100 after the identity authenticity verification is passed and the temporarily stored status information is activated.

[0077] The local computing power verification of client 200 is triggered based on preset triggering conditions (internal features described later). It is not necessarily triggered every time an authentication failure response message is sent, thus avoiding unnecessary burden on the user. Local computing power verification is used to generate environment verification information, which is then used for secondary verification. The local computing power verification process is completed by client 200 without interaction with the user, and requires no user input or awareness. Server 100 verifies the environment verification information. If the verification is successful, it returns a successful login verification result to client 200; otherwise, it returns a failed login verification result. This combines the advantages of deception defense and environment adaptive authentication, which not only combats automated cracking and reverse engineering attacks but also improves overall security and user experience without explicitly exposing risk control logic.

[0078] In the authentication method of client 200 in this application, server 100 returns an authentication failure response message when the verification result is successful. The authentication failure response message is consistent with the real authentication failure response in terms of preset characteristics, which can achieve runtime deception defense against attackers, without explicitly exposing the control logic of the authentication method, resisting automated cracking and reverse attacks, so as to confuse attackers and trigger implicit challenges. The environment verification information is generated locally by client 200 without interacting with the user. It can perform secondary authentication based on environment verification information without affecting the normal user experience, thereby achieving a dynamic balance between security, performance and user experience.

[0079] More specifically, Server 100 returns authentication failure response messages to user credentials, preventing attackers from determining the authentication success rate based on the response, thus slowing down brute-force attacks and improving resistance to brute-force attacks. It also utilizes real authentication failure responses to achieve runtime deception, effectively preventing reverse engineering and automated password guessing scripts. Because the authentication failure response messages returned by Server 100 are completely identical in form to real authentication failure responses, attackers cannot distinguish between "real failure" and "fake failure," thereby hiding Server 100's risk control logic and preventing reverse reasoning. Attackers find it difficult to deduce easily exploitable information such as risk thresholds, geographical policies, or blacklist rules. Server 100 only triggers local computing power verification in certain scenarios, avoiding high-load client-side computing power verification operations for all users, reducing terminal power consumption and waiting time, and optimizing user experience and device performance. Users in low-risk environments still maintain a fast login experience. Compared to traditional two-factor authentication (SMS verification codes, QR code scanning, etc.), the authentication method in this application completes both verifications within the same session, eliminating the need for additional external channels, reducing one round trip communication, improving authentication throughput, and lowering communication and interaction costs. The two verification records can be logged by the log and audit module 170 for risk control tracing. The first "false failure" can trigger backend mechanisms such as security log analysis and IP reputation marking. The authentication system 1000 can dynamically adjust the spoofing probability to implement flexible defense strategies, enhancing the security and controllability of the authentication system 1000. Adjusting the spoofing probability refers to the machine learning model dynamically adjusting the preset conditions for judging risk assessment results.

[0080] The following section continues to describe the identity authentication method provided in the embodiments of this application. Please refer to [link / reference]. Figure 2 , Figure 2 This is a schematic diagram illustrating the interaction of the authentication method provided in this application embodiment. The interaction process may include the following steps: S1: User login request: The user enters their username and password as user credentials → The client sends a login request in 200: {account_id,password_hash, env_fingerprint, timestamp}; S2: Server 100 first verification: Receive login request, Server 100 verifies user credentials → Call machine learning model to calculate environment risk score risk_score; According to the rules: If the user's credentials are incorrect, a genuine authentication failure response message will be returned. If the verification result is successful and the risk assessment result is determined to be a low-risk environment → return success; If the verification result is successful but the risk assessment result determines it to be a high-risk environment → return an "authentication failure response message" (the actual authentication failure response is exactly the same as the authentication failure response message), and create a session suspension identifier.

[0081] S3: The client 200 detects an authentication failure response message, → the response parsing module 220 identifies "user credential error"; S4: The local verification trigger module 230 checks the internal characteristics and confirms that it may be an "authentication failure response message"; S5: Start the computing power verification and environment acquisition module 240 to perform local computing power and environment verification. The client 200 performs a lightweight calculation: computing power proof information sign = SHA256(env_fingerprint + nonce + timestamp), and collects the environment status to form device fingerprint information env_report; S6: Package the results into: Environment Verification Information = {account_id, password_hash, env_fingerprint, sign, env_report} S7: Client 200 sends environment verification information back to server 100; S8: Server 100 verifies whether the computing power proof information sign matches; S9: Verify the risk assessment results of the device fingerprint information env_report; S10: If the match is successful, activate the status information that was suspended for the first time and return an authentication success response of "Login successful".

[0082] To facilitate better implementation of the identity authentication method in this application, this application also provides a dynamic authentication system 1000. Please refer to... Figure 8 , Figure 8This is a schematic diagram of the structure of the dynamic authentication system 1000 provided in this application embodiment. The dynamic authentication system 1000 includes a server 100 and a client 200. The server 100 may include: a credential verification module 110, used to verify the account and password of the login request; a risk assessment module 120, used to call a machine learning model, which calculates the risk assessment result based on rules and the machine learning model; outputs an environmental risk score of 0~100, and supports dynamic threshold adjustment (updated in real time according to user behavior or geographical risk level); a deception response control module 130, used to return an authentication failure response message that is exactly the same as "user credential error" even if the verification result is successful, when the risk assessment result determines that the environment is high-risk; a session suspension module 140, used to generate a session suspension identifier for the successfully verified user credentials, waiting for secondary verification by the client 200; an additional verification module 150, used to verify the environmental verification information submitted by the client 200, and activate the suspended session after successful matching; and a result confirmation module 160, used to update the session status to success and return the verification result of successful login. The log and audit module 170 is used to record each false failure event (an event where the verification result is successful and the risk assessment result is determined to be a high-risk environment); and to record the secondary verification success rate (the probability that the environment verification information passes) and the trigger ratio (the ratio of the number of times the local computing power verification is triggered to the number of times the login request is obtained), for subsequent strategy optimization.

[0083] In some embodiments, the credential verification module 110 is used to receive a login request containing user credentials sent by the client.

[0084] In some embodiments, the credential verification module 110 is used to verify user credentials and obtain verification results.

[0085] In some embodiments, when the verification result is successful, the risk assessment module 120 performs a risk assessment based on the current login environment to obtain a risk assessment result.

[0086] In some embodiments, when the risk assessment result determines that the environment is high-risk, the deception response control module 130 temporarily stores the successful verification status information and sends an authentication failure response message to the client. The authentication failure response message is consistent with the real authentication failure response in terms of preset characteristics.

[0087] In some embodiments, the additional verification module 150 is used to receive environment verification information sent by the client based on the authentication failure response message.

[0088] In some embodiments, the additional verification module 150 is used to verify the authenticity of an identity based on environmental verification information and obtain an identity verification result.

[0089] In some embodiments, when the authentication result is successful, the result confirmation module 160 is used to activate the temporarily stored status information and return an authentication success response to the client.

[0090] In some embodiments, the log and audit module 170 is used to record events where the verification result is successful and the environment trustworthiness is lower than a preset threshold.

[0091] In some embodiments, the log and audit module 170 is used to record the probability of passing the environment verification information and to record the ratio of the number of times the local computing power verification is triggered to the number of times a login request is obtained.

[0092] Client 200 (App / SDK) may include: a login submission module 210, used to collect username and password and initiate a login request; a response parsing module 220, used to identify the error type returned by server 100; a local verification trigger module 230, used to initiate local computing power verification when a "user credential error" is detected but matches internal characteristics (such as signature fields); a computing power verification and environment collection module 240, used to collect device fingerprint, application signature, runtime environment hash information, and perform a lightweight encryption operation (such as HMAC-SHA256, ECC signature, etc.) to generate computing power proof information sign and device fingerprint information env_report; and an enhanced submission module 250, used to package the computing power proof information sign, device fingerprint information env_report, and other information into: environment verification information = {account_id, password_hash, env_fingerprint, sign, env_report}.

[0093] In some embodiments, the login submission module 210 is used to send a login request containing user credentials to the server, and the login request is used by the server to verify the user credentials. In some embodiments, the login submission module 210 is used to receive an authentication failure response message returned by the server; wherein, the authentication failure response message is a message sent by the server to the client after temporarily storing the successful authentication status information when the user credential verification is successful and the current login environment is determined to be high-risk, and the authentication failure response message is consistent with the real authentication failure response in preset characteristics. In some embodiments, the local verification triggering module 230 is used to detect internal features in response to a failure response; and to trigger local computing power verification if the internal features match a suspicious pattern.

[0094] In some embodiments, the computing power verification and environment acquisition module 240 generates environment verification information based on the authentication failure response message; In some embodiments, the enhanced submission module 250 is used to send environment verification information to the server so that the server can perform identity verification based on the environment verification information; and to receive an authentication success response returned by the server; wherein the authentication success response is returned by the server after the identity verification is passed and the temporarily stored status information is activated.

[0095] Optionally, in mobile payment scenarios, computing power verification uses HMAC-SHA256; environment detection includes root check and device ID consistency verification; the entire process is completed within 200ms.

[0096] Optionally, in high-security enterprise login scenarios, computing power verification adopts the ECCP-256 signature algorithm; the device fingerprint information env_report includes the operating system version and signature certificate hash; and it supports the use of security chips (TEE / SE) to generate computing power proof information sign.

[0097] Optionally, in the lightweight web-based scenario, a local hash is generated using the JavaScript + WebAssembly module; caching and retry logic is implemented through ServiceWorker; after the authentication failure response message is triggered, the front end automatically requests an additional challenge and calculates the computing power proof information sign.

[0098] Each module in the aforementioned authentication system 1000 can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each of these units.

[0099] The authentication system 1000 can be integrated into a terminal or server 100 that has storage and a processor and thus computing power, or the authentication system 1000 can be the terminal or server 100.

[0100] Optionally, this application also provides a computer device 300, including a memory 302 and a processor 301. The memory 302 stores a computer program, and the processor 301 executes the computer program to implement the steps in the above-described method embodiments.

[0101] Figure 7 This is a schematic diagram of the structure of a computer device 300 provided in an embodiment of this application. The computer device 300 can be a terminal 100 or a server 100. Figure 7As shown, the computer device 300 includes a processor 301 with one or more processing cores, a memory 302 with one or more computer-readable storage media, and a computer program stored on the memory 302 and executable on the processor 301. The processor 301 and the memory 302 are electrically connected. Those skilled in the art will understand that the computer device structure shown in the figures does not constitute a limitation on the computer device, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0102] The processor 301 is the control center of the computer device 300. It connects various parts of the computer device 300 through various interfaces and lines. By running or loading software programs and / or modules stored in the memory 302, and calling data stored in the memory 302, it performs various functions of the computer device 300 and processes data, thereby performing overall processing of the computer device 300.

[0103] In this embodiment, the processor 301 in the computer device 300 loads the instructions corresponding to the processes of one or more computer programs into the memory 302 according to the steps described above, and the processor 301 runs the computer programs stored in the memory 302, thereby achieving: In response to login requests, the system verifies the user credentials in the login request and assesses the environmental trustworthiness of the environmental information in the login request. If the verification result is successful and the risk assessment result is determined to be a high-risk environment, return a failure response to the client that is consistent with the user's credential error. Receive environment verification information from the client, which is generated by the client after triggering local computing power verification based on a failure response; and Verify the environment verification information and return the verification result to the client.

[0104] In the computer device 300 of this application, the server 100 returns a failure response even when the verification result is successful, which can implement runtime deception defense against attackers, without explicitly exposing the control logic of the authentication method, resisting automated cracking and reverse attacks, so as to confuse attackers and trigger implicit challenges; the client 200 decides whether to trigger local computing power verification based on the response, which can reduce the daily power consumption of the algorithm; the environmental verification information is generated by the client 200's local computing power verification, without the need for user interaction, and can perform secondary authentication based on the environmental verification information without affecting the normal user experience, thereby achieving a dynamic balance between security, performance and user experience.

[0105] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0106] This application also provides a computer-readable storage medium for storing a computer program. This computer-readable storage medium can be applied to a computer device, and the computer program causes the computer device to execute the corresponding processes in the authentication method of the embodiments of this application; for the sake of brevity, these will not be elaborated further here.

[0107] This application also provides a computer program product including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the corresponding process in the authentication method of this application embodiment. For simplicity, further details are omitted here.

[0108] This application also provides a computer program comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the corresponding process in the authentication method of this application. For brevity, further details are omitted here.

[0109] It should be understood that the processor in this application may be an integrated circuit chip with signal processing capabilities. In implementation, the steps of the above method embodiments can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor described above can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0110] It is understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0111] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0112] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0113] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0114] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0115] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0116] In addition, the functional units in this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0117] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer or server 100) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0118] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A server authentication method, characterized in that, include: Receive a login request containing user credentials sent by the client; The user credentials are verified to obtain the verification result; When the verification result is successful, a risk assessment is performed based on the current login environment to obtain the risk assessment result; When the risk assessment result determines that the environment is high-risk, the successful verification status information is temporarily stored, and an authentication failure response message is sent to the client. The authentication failure response message is consistent with the real authentication failure response in terms of preset characteristics. Receive the environment verification information sent by the client based on the authentication failure response message; Based on the environmental verification information, the authenticity of the identity is verified to obtain the identity verification result; When the authentication result is successful, the temporarily stored status information is activated, and an authentication success response is returned to the client.

2. The identity authentication method according to claim 1, characterized in that, The risk assessment based on the current login environment, and the resulting risk assessment results, include: Obtain the device fingerprint information and network behavior characteristics of the client; The device fingerprint information is compared and analyzed with historical login records to calculate the device consistency score; Based on the network behavior characteristics, automated attack behavior patterns are identified, and network behavior anomaly scores are calculated. Based on the device consistency score and the network behavior anomaly score, an environmental risk score is calculated using preset weighting parameters. When the environmental risk score exceeds a preset threshold, the risk assessment result is determined to be a high-risk environment.

3. The identity authentication method according to claim 2, characterized in that, Also includes: Collect historical login information and attack behavior information; A machine learning model is trained based on the historical login information and attack behavior information. The preset threshold of the environmental risk score is dynamically adjusted using the machine learning model.

4. The identity authentication method according to claim 2, characterized in that, The device fingerprint information includes one or more of the following: operating system information, browser information, hardware configuration information, and software environment information.

5. The identity authentication method according to claim 2, characterized in that, The network behavior characteristics include one or more of the following: IP address geographic location, network latency pattern, and request frequency.

6. The identity authentication method according to claim 1, characterized in that, The step of temporarily storing the successful verification status information includes: Generate a unique session suspension identifier; Establish an association between the successful verification status information and the session suspension identifier; Store the association in a cache and set an expiration time.

7. The identity authentication method according to claim 6, characterized in that, The environmental verification information received from the client based on the authentication failure response message includes: Receive environment verification information containing the session suspension identifier.

8. The identity authentication method according to claim 1, characterized in that, The authentication failure response message is consistent with the real authentication failure response in one or more of the following characteristics: response format, error code, response latency, and response header information.

9. The identity authentication method according to claim 1, characterized in that, The environmental verification information includes device fingerprint information and computing power verification information.

10. The identity authentication method according to claim 9, characterized in that, The process of verifying identity authenticity based on the environmental verification information to obtain an identity verification result includes: Verify the consistency between the device fingerprint information and the historical records to obtain a consistency verification result; Verify the correctness of the computing power proof information and obtain the correctness verification result; Check the correlation between the device fingerprint information and the computing power proof information to obtain the correlation check result; When the consistency verification result, the correctness verification result, and the correlation check result are all passed, the authentication result is determined to be successful.

Images