User identity authentication method and device, electronic equipment and storage medium

Abstract

This application discloses a user authentication method, apparatus, electronic device, and storage medium, belonging to the field of authentication technology. The method includes: obtaining a user's authentication request; determining a target authentication scenario from multiple preset authentication scenarios based on the authentication request, each authentication scenario corresponding to a security level threshold; obtaining a user's historical behavior dataset, where each historical behavior data entry is configured with a basic security level and a weight; determining candidate behavior data in the historical behavior dataset whose basic security level meets the target security level threshold corresponding to the target authentication scenario; determining target behavior data from each candidate behavior data according to the weight; generating a authentication question based on the target behavior data and outputting the authentication question to the user; obtaining user response information corresponding to the authentication question; and determining the authentication result based on the user response information. This application enables scenario-adaptive authentication strategies, ensuring that high-security-level historical behavior data is used in high-risk scenarios.

Description

Technical Field

[0001] This application relates to the field of identity verification technology, specifically to user identity verification methods, devices, electronic devices, and storage media. Background Technology

[0002] Identity verification is the process in information security of confirming the legitimacy of a user, device, or system. Its core is to verify the credentials provided by the user (such as passwords, biometrics, hardware tokens, etc.) to determine whether the user is the claimed legitimate entity, thereby controlling access to resources.

[0003] Currently, related technologies typically employ verification methods based on historical devices / locations. For example, the system records the devices and login locations a user has previously used, triggering additional verification when a new device or location is detected. However, this method lacks flexibility and cannot adapt to the security requirements of different verification scenarios. Summary of the Invention

[0004] This application provides user authentication methods, devices, electronic devices, and storage media, aiming to address the problem that related technologies lack flexibility and cannot adapt to the security needs of different authentication scenarios.

[0005] Firstly, a user authentication method is provided, including: Obtain the user's verification request, and determine the target verification scenario from multiple preset verification scenarios based on the verification request; where each verification scenario corresponds to a security level threshold; Obtain the user's historical behavior dataset. Each historical behavior data point in the dataset is configured with a basic security level and weight. In the historical behavior dataset, candidate behavior data that meet the target security level threshold corresponding to the target verification scenario are identified; Based on the weight of each candidate behavior data, the target behavior data is determined from the candidate behavior data, a verification question is generated based on the target behavior data, and the verification question is output to the user. Obtain the user's answer information corresponding to the verification question, and determine the identity verification result based on the user's answer information.

[0006] Secondly, a user authentication device is provided, comprising: The scene recognition unit is configured to acquire the user's verification request and determine the target verification scene from multiple preset verification scenes based on the verification request; wherein, each verification scene corresponds to a security level threshold. The acquisition unit is configured to acquire a user's historical behavior dataset, and each piece of historical behavior data in the historical behavior dataset is configured with a basic security level and weight. The first processing unit is configured to determine, from the historical behavior dataset, candidate behavior data whose basic security level meets the target security level threshold corresponding to the target verification scenario; The second processing unit is configured to determine the target behavior data from among the candidate behavior data according to the weight of each candidate behavior data, generate a verification question based on the target behavior data, and output the verification question to the user. The verification unit is configured to obtain the user's answer information corresponding to the verification question and determine the identity verification result based on the user's answer information.

[0007] Thirdly, an electronic device is provided, comprising a memory and a processor, wherein a computer program is stored in the memory, and when executed by the processor, the computer program implements the user authentication method as described in the first aspect.

[0008] Fourthly, a computer-readable storage medium is provided having a computer program stored thereon, the computer program being loaded by a processor to perform the steps of the user authentication method as described in the first aspect.

[0009] The solution provided in this application involves obtaining a user's verification request, determining a target verification scenario from multiple preset verification scenarios based on the request, acquiring the user's historical behavior dataset (each historical behavior data point is configured with a basic security level and weight), identifying candidate behavior data whose basic security level meets the target security level threshold corresponding to the target verification scenario, determining target behavior data based on the weights of each candidate behavior data point, generating a verification question based on the target behavior data, outputting the verification question to the user, acquiring the user's answer information corresponding to the verification question, and determining the identity verification result based on the user's answer information. This application, by configuring a basic security level and weight for each historical behavior data point in the user's historical behavior dataset and establishing a mapping relationship between verification scenarios and historical behavior data security level thresholds, can achieve scenario-adaptive verification strategies, ensuring that high-risk scenarios use high-security-level historical behavior data, and also achieving a balance between security and user experience. Attached Figure Description

[0010] 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.

[0011] Figure 1 This is a flowchart of a user authentication method provided in an embodiment of this application; Figure 2 This is a flowchart of a method for determining the weights of historical behavior data provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of the user authentication device provided in the embodiments of this application; Figure 4 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0012] 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.

[0013] In the description of this application, it should be understood that the terms "center," "longitudinal," "lateral," "length," "width," "thickness," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientation or positional relationships based on the orientation or positional relationships shown in the accompanying drawings, are used only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this application. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, features defined with "first" and "second" may explicitly or implicitly include one or more of the stated features. In the description of this application, "a plurality of" means two or more, unless otherwise explicitly specified.

[0014] "A and / or B" includes the following three combinations: A only, B only, and a combination of A and B.

[0015] The use of "applies to" or "configured to" in this application implies open and inclusive language, which does not exclude the applicability to or configuration to devices performing additional tasks or steps. Additionally, the use of "based on" implies openness and inclusivity, because processes, steps, calculations, or other actions "based on" one or more conditions or values ​​may in practice be based on additional conditions or values ​​beyond those stated.

[0016] In this application, the term "exemplary" is used to mean "used as an example, illustration, or description." Any embodiment described as "exemplary" in this application is not necessarily to be construed as being more preferred or advantageous than other embodiments. The following description is provided to enable any person skilled in the art to make and use this application. Details are set forth in the following description for purposes of explanation. It should be understood that those skilled in the art will recognize that this application can be made without using these specific details. In other instances, well-known structures and processes are not described in detail to avoid obscuring the description of this application with unnecessary detail. Therefore, this application is not intended to be limited to the embodiments shown, but is consistent with the broadest scope of the principles and features disclosed in this application.

[0017] For user authentication, common industry solutions currently include: Static credential verification relies on known credentials such as passwords, PIN codes, and answers to security questions. The main problem with this method is that credentials can be forgotten, stolen, or obtained through social engineering attacks.

[0018] Dynamic credential verification: This method relies on a user-owned device or token, such as SMS verification codes, hardware tokens, or software tokens (like Google Authenticator). This type of method requires the user to carry the verification device with them and carries the risk of SIM card swapping attacks.

[0019] Biometric verification: Based on a user's inherent biometric characteristics, such as fingerprints, faces, voiceprints, irises, etc. While these methods offer a high degree of uniqueness, they pose a risk of privacy breaches, and once biometric characteristics are leaked, they cannot be changed.

[0020] Behavioral signature verification: Based on user behavior patterns, such as touchscreen gestures. This type of method is typically used for continuous authentication, but its application is limited in one-time authentication scenarios.

[0021] The above solution has the following disadvantages: The method based on historical security questions involves setting up security questions during registration (such as "the name of your first school"), which users must answer correctly during verification. However, these questions are vulnerable to social engineering attacks, and users may forget the answers.

[0022] The historical transaction record-based method: In financial scenarios, the system displays a user's past transaction records and requires the user to identify which transactions they made. However, this method is limited by the accuracy of the user's memory.

[0023] The historical device / location-based method involves recording the devices and login locations a user has previously used. Additional verification is triggered when a new device or location is detected. However, this method lacks flexibility and cannot adapt to the security requirements of different verification scenarios.

[0024] Further analysis of the relevant technologies revealed the following problems: Insufficient utilization of historical data: Related technologies typically only use a single type of historical behavioral data (such as only using historical devices or only using historical locations), failing to comprehensively utilize multi-dimensional historical behavioral data of users (nickname, mobile phone number, device, behavioral patterns, etc.) for comprehensive judgment.

[0025] Lack of dynamic weighting mechanisms: Related technologies typically assign fixed weights to historical behavioral data, without considering differences in data timeliness, usage frequency, and security and trustworthiness levels. For example, devices recently used by a user are more valuable for reference than those used a long time ago, but related technologies often treat them equally.

[0026] Rigid verification strategies: Related technologies typically employ fixed verification strategies, which cannot dynamically adjust the required types and quantities of historical behavior data based on real-time risk assessments, resulting in either insufficient security or a poor user experience.

[0027] Lack of security level threshold mechanism: The relevant technologies have not established a mapping relationship between the security level threshold of historical behavior data and the security requirements of the verification scenario, and cannot ensure that high-security historical data is used in high-risk verification scenarios.

[0028] In view of this, embodiments of this application provide a user authentication method, apparatus, electronic device, and storage medium. By configuring a basic security level and weight for each piece of historical behavior data in a user's historical behavior dataset and establishing a mapping relationship between the verification scenario and the security level threshold of the historical behavior data, the verification strategy can be adapted to different scenarios, ensuring that high-risk scenarios use historical behavior data with high security levels. Furthermore, it can achieve a balance between security and user experience, thereby solving at least one of the aforementioned technical problems.

[0029] Specifically, this application embodiment will be described from the perspective of a user authentication device, which can be integrated into an electronic device. That is, the user authentication method provided in this application embodiment can be executed by an electronic device. Optionally, the electronic device may include a terminal device. The terminal device may be a mobile phone, tablet computer, smart Bluetooth device, laptop computer, game console, or personal computer (PC), etc.

[0030] The user authentication method provided in this application can be applied to user authentication systems. This user authentication system may include a terminal device and a server. The terminal device may be a device including receiving and transmitting hardware, i.e., a device with receiving and transmitting hardware capable of performing bidirectional communication on a bidirectional communication link. The terminal device and the server can communicate bidirectionally via a network.

[0031] Optionally, the server can be a standalone server, or a server network or server cluster, including but not limited to computers, network hosts, single network servers, multiple network server sets, or cloud servers composed of multiple servers. Cloud servers consist of a large number of computers or network servers based on cloud computing.

[0032] The following is a detailed description in conjunction with the accompanying drawings. It should be noted that the order of description of the following embodiments is not intended to limit the preferred order of the embodiments. Although a logical order is shown in the flowcharts, in some cases, the steps shown or described may be performed in a different order than that shown in the drawings.

[0033] Figure 1 This is a flowchart of a user authentication method provided in an embodiment of this application. The specific flow of this user authentication method can be summarized in steps 101-105, wherein: Step 101: Obtain the user's verification request, and determine the target verification scenario from multiple preset verification scenarios based on the verification request; where each verification scenario corresponds to a security level threshold.

[0034] Verification requests can include information for scenario identification, such as operation type (e.g., user login, changing linked mobile phone number, or modifying payment password), and device and environment information (e.g., device identifier, IP address, login location, network environment, etc.). Based on this information, the target verification scenario triggered by the verification request can be determined.

[0035] The aforementioned verification scenarios can include multiple scenarios such as daily login, login from a different location, login from a new device, changing the phone number linked to the account, and account recovery. Daily login can be understood as a regular login in a trusted device / network environment. Login from a different location can be understood as logging in from a new geographical location or unfamiliar network environment. Login from a new device can be understood as logging in from a device that has never been recorded before. Changing the phone number linked to the account can be understood as changing the linked phone number. Account recovery can be understood as regaining account access permissions through identity verification.

[0036] It should be noted that each historical behavior data point in the user's historical behavior dataset is configured with a basic security level. This basic security level is encompassed by multiple preset security levels. The security level threshold for each verification scenario is determined based on these multiple security levels, taking into account the security requirements of that verification scenario.

[0037] As an example, the above security levels are listed in ascending order, such as L1, L2, L3, and L4. The basic security level of each piece of historical behavior data can be determined based on multiple evaluation dimensions, including data stability, data privacy, data reliability, and data timeliness. Data stability can be determined based on the frequency of data changes; for example, device information is relatively stable, so its data stability is high, while nicknames may change frequently, so nickname data stability is low. Data privacy can be determined based on the sensitivity of the data; for example, mobile phone numbers have high privacy, so their data privacy is high, while profile pictures may be public, so profile pictures data privacy is low. Data reliability can be determined based on the credibility of the data source; for example, data from a real-name authenticated mobile phone number has high reliability, while data from a nickname filled in by the user has low reliability. Data timeliness can be determined based on the "freshness" of the data; for example, recently used data is more valuable than older data, so its data timeliness is higher.

[0038] For example, the basic security level of an occasionally used profile picture and non-sensitive operation records can be L1; the basic security level of a frequently used nickname and historical password modification records can be L2; the basic security level of a verified email address and frequently used login location can be L3; and the basic security level of a real-name authenticated mobile phone number and a long-term used device fingerprint can be L4.

[0039] Security requirements for verification scenarios can also be categorized into multiple levels, such as low, medium, and high. For example, the security requirement level for daily login can be S1, with S1 being low. The security requirement level for login from a different location can be S2, with S2 being medium. The security requirement level for login from a new device can be S3, with S3 being medium. The security requirement level for changing the linked mobile phone number can be S4, with S4 being high. The security requirement level for account recovery can be S5, with S5 being high.

[0040] For verification scenarios with security requirement level S1, the security level threshold can be, for example, L1-L4. In this verification scenario, historical behavioral data from all levels L1-L4 can be used. For verification scenarios with security requirement level S2 or S3, the security level threshold can be, for example, L2-L4. In this verification scenario, historical behavioral data from levels L2-L4 can be used. For verification scenarios with security requirement level S4 or S5, the security level threshold can be, for example, L3-L4. In this verification scenario, historical behavioral data from levels L3-L4 can be used.

[0041] In some embodiments, a security requirement level can be configured for each verification scenario, and a security level threshold can be set for each security requirement level. Thus, after determining the target verification scenario, the security level threshold corresponding to the security requirement level of the target verification scenario can be determined as the target security level threshold corresponding to the target verification scenario.

[0042] Step 102: Obtain the user's historical behavior dataset. Each historical behavior data point in the dataset is configured with a basic security level and weight.

[0043] The verification request may also include a user identifier. The historical behavior dataset may be pre-associated with and stored with the user identifier, and the historical behavior dataset may be obtained based on the user identifier.

[0044] Step 103: In the historical behavior dataset, determine the candidate behavior data that meet the target security level threshold corresponding to the target verification scenario based on the basic security level.

[0045] Specifically, for each piece of historical behavior data in a user's historical behavior dataset, if the basic security level of the historical behavior data meets the target security level threshold, then the historical behavior data is considered as candidate behavior data. For example, the target security level threshold is a security level range; if the basic security level of the historical behavior data falls within this range, it means that the basic security level of the historical behavior data meets the target security level threshold.

[0046] Step 104: Based on the weight of each candidate behavior data, determine the target behavior data from among the candidate behavior data, generate a verification question based on the target behavior data, and output the verification question to the user.

[0047] Specifically, as one implementation method, a specified number of candidate behavior data can be selected as the target behavior data from each candidate behavior data in descending order of weight. This specified number can be, for example, 2, 3, 4, or 5, and can be set according to actual needs; no specific limitation is made here.

[0048] To achieve the optimal balance between security and user experience, another approach is to pre-configure weights for each piece of historical behavior data and pre-set a minimum verification strength V_min for each verification scenario. For example, a minimum verification strength V_min can be set for each security requirement level of the verification scenario. The minimum verification strength V_min is a core threshold parameter in a user authentication system; it defines the minimum cumulative strength required to pass verification under a specific security requirement level. The following principles should be followed when designing the minimum verification strength V_min: Risk adaptability: The minimum verification intensity V_min should be positively correlated with the risk level of the verification scenario; Security guarantee: Ensure that even if some historical behavior data is obtained by an attacker, it is difficult to reach the minimum verification strength V_min; Balance user experience: Avoid setting excessively high thresholds that make verification overly cumbersome; Adjustability: Supports dynamic adjustment based on actual security incidents and business needs.

[0049] When a minimum verification strength V_min is set for the security requirement level of each verification scenario, the minimum verification strength V_min corresponding to the security requirement level of the target verification scenario is determined as the target minimum verification strength corresponding to the target verification scenario.

[0050] When determining the target behavior data, the target behavior data can be determined from among the candidate behavior data based on the weight of each candidate behavior data and the minimum verification strength of the target verification scenario.

[0051] Furthermore, the candidate behavior data can be sorted according to their weights to obtain a behavior data sequence. Then, starting from the side with the highest weight in the behavior data sequence, candidate behavior data are selected sequentially until the sum of the weights of the selected candidate behavior data is greater than or equal to the target minimum verification strength. Each candidate behavior data selected from the behavior data sequence is then used as the target behavior data. When sorting the candidate behavior data according to their weights, they can be sorted, for example, in descending order of weight or in ascending order of weight.

[0052] It should be noted that if, after traversing the behavior data sequence, the sum of the weights of each candidate behavior data in the behavior data sequence is still less than the target minimum verification strength, it indicates that there is insufficient available historical data and an alternative verification scheme (such as secondary verification) needs to be activated.

[0053] When generating validation questions based on target behavior data, one validation question can be generated for each piece of target behavior data, so that the number of target behavior data is the same as the number of validation questions.

[0054] In this application, the user's historical behavior dataset includes historical behavior data of multiple different data types. For example, multiple dimensions of user historical behavior data can be pre-collected and stored as a historical behavior dataset. These multiple dimensions may include, for example, identity history, previously used personal signatures / profiles, device and environment history, and behavioral pattern history. Specifically, historical behavior data under the identity history dimension may include multiple items such as previously used nicknames / usernames, previously used avatars, previously used personal signatures / profiles, previously bound mobile phone numbers (including binding / unbinding times), previously bound email addresses, and previously bound social media accounts (such as WeChat, QQ, etc.). Historical behavior data under the device and environment history dimension may include multiple items such as previously used login devices (device model, operating system, unique identifier), frequently used login geographical locations / IP address ranges, frequently used login time periods, and previously used browser / client version information. Historical behavior data under the behavioral pattern history dimension may include multiple items such as APP interface settings, historical password modification records, previously set security questions and answers, and historical login success / failure records. It should be noted that each piece of historical behavior data contains a timestamp, and these timestamps form a user behavior timeline.

[0055] The form of the validation question depends on the type of historical behavior data, for example: For previously used nicknames: multiple nickname options (including correct answers and distractors) can be provided for users to choose the ones they have used; For historical phone numbers: users can be asked to provide the last few digits of the phone number, or selected from multiple options; For legacy equipment: a list of equipment models can be provided for users to select from; For historical login locations: a list of cities can be provided for users to choose from.

[0056] At the same time, user experience and security should be considered when generating verification questions. For example, distractors should be randomly generated but similar to the correct answer to increase the difficulty for attackers to guess. Furthermore, the number of verification questions should not be too large, generally between 1 and 5, with 2-3 questions usually sufficient.

[0057] One implementation approach is to pre-configure question generation strategies for different data types corresponding to the historical behavior dataset. These strategies describe how to generate validation questions based on the historical behavior data of their respective data types. When generating a validation question for each piece of target behavior data, the question generation strategy corresponding to the data type of that target behavior data can be used to generate a validation question based on the target behavior data.

[0058] Taking the previously used nickname data type under the identity history dimension as an example, the question generation strategy configured for the previously used nickname data type can include: Question template: Please select from the following options the nicknames you have used; Generation method: Randomly select a correct answer from the user's past nickname history, and then randomly select several (e.g., 2-4) nicknames from other users' nickname databases as distractors, ensuring that the distractors do not repeat the correct answer and are similar in style.

[0059] Taking the previously bound mobile phone number data type under the contact information history dimension as an example, the question generation strategy for the previously bound mobile phone number data type configuration can include: Question template: Please provide the last 4 digits of the mobile phone number you have previously linked (or select from the following options); Generation method: If multiple-choice questions are used, one phone number is selected from the user's phone number history, and the last 4 digits of the phone number are randomly generated as a distractor; note that phone numbers are sensitive information, and usually only the last few digits are displayed.

[0060] Taking the previously logged-in device data type under the device and environment history dimension as an example, the issue generation strategy for configuring the previously logged-in device data type can include: Question template: Please select the device you have logged into from the following list; Generation method: Select a correct answer from the user's device history, and then randomly select distractors from the device model database.

[0061] Taking the commonly used login location data type under the behavioral pattern history dimension as an example, the question generation strategy for configuring the commonly used login location data type can include: Question template: Please select the city you have logged into from the following list; Generation method: Select a correct answer from the user's login history, and then randomly select distractors from the list of cities.

[0062] Additionally, when generating question options, it's crucial to ensure that each question has the same number of options, typically four (including the correct answer). Furthermore, the distractors should belong to the same category as the correct answer and lack any obvious distinguishing features (e.g., both being devices from the same brand).

[0063] When presenting validation questions to users, the order of the validation questions can be random or arranged from high to low according to the weight of the corresponding target behavior data.

[0064] Step 105: Obtain the user's answer information corresponding to the verification question, and determine the identity verification result based on the user's answer information.

[0065] Specifically, a verification score can be determined based on the user's response. Then, the authentication result is determined by comparing the verification score with a score threshold. For example, if the verification score is greater than or equal to the score threshold, the authentication result is successful; if the verification score is less than the score threshold, the authentication result is rejected.

[0066] As one implementation method, the verification score is the number of verification questions answered correctly by the user, and the score threshold is the number of each verification question.

[0067] As another implementation, each verification scenario also corresponds to a minimum verification strength, and each piece of historical behavior data is also configured with a weight. The sum of the weights of the target behavior data is greater than or equal to the target minimum verification strength corresponding to the target verification scenario. The score threshold is the target minimum verification strength, and each piece of target behavior data corresponds to a verification question. When determining the verification score, the target verification question that was answered correctly can be determined from among the verification questions based on the user's answer information, and the sum of the weights of the target behavior data corresponding to each target verification question is determined as the verification score.

[0068] Figure 1 The corresponding embodiment provides a solution that obtains a user's verification request, determines a target verification scenario from multiple preset verification scenarios based on the verification request, then obtains the user's historical behavior dataset. Each historical behavior data in the historical behavior dataset is configured with a basic security level and weight. Candidate behavior data whose basic security level meets the target security level threshold corresponding to the target verification scenario are determined from the historical behavior dataset. Next, target behavior data is determined from the candidate behavior data according to the weights of each candidate behavior data. A verification question is generated based on the target behavior data and output to the user. Then, the user's answer information corresponding to the verification question is obtained, and the identity verification result is determined based on the user's answer information. This application, by configuring a basic security level and weight for each historical behavior data in the user's historical behavior dataset and establishing a mapping relationship between verification scenarios and the security level threshold of historical behavior data, can achieve scenario-adaptive verification strategies, ensuring that high-risk scenarios use high-security-level historical behavior data, and also achieving a balance between security and user experience.

[0069] In some embodiments, the weight of each historical behavior data point is a dynamic weight. Figure 2 This is a flowchart of a method for determining the weight of historical behavior data provided in an embodiment of this application. The specific process of this determination method can be summarized in steps 201-203, wherein: Step 201: Determine the time decay coefficient based on the timestamps of historical behavior data.

[0070] Specifically, an exponential decay function can be used to determine the time decay coefficient based on the timestamps of historical behavioral data. The most recent data has a higher time decay coefficient, while the time decay coefficient decreases for older data.

[0071] Step 202: Determine the usage frequency coefficient based on the usage frequency of historical behavior data within a set period.

[0072] Among these, frequently used data have a higher usage frequency coefficient. As an example, multiple time windows can be used for analysis to balance the real-time nature and stability of the data. The set period, as mentioned earlier, can be any of these multiple time windows. These multiple time windows can include, for example, several short-term, medium-term, and long-term windows. An example value range for the short-term window is 7 days; its main purpose is to capture recent activity for rapid response and dynamic weight adjustments. An example value range for the medium-term window is 30 days; the medium-term window is the core evaluation period, mainly used to measure stable data usage habits. An example value range for the long-term window is 90 days; its main purpose is to observe long-term trends and identify the decay or consolidation of data value.

[0073] As one implementation method, the frequency of use of historical behavioral data within a set period is quantified by calculating the relative usage density of historical behavioral data within the set period, such as using the following formula: Usage frequency = (Number of successful uses of historical behavior data within a set period / Total number of verifications within a set period) × 1000; The frequency of use is measured in times per thousand verifications. It should be noted that successful use can refer to a session where historical behavioral data is used as one of the verification factors and successfully passes verification. The formula above (number of successful uses of historical behavioral data within a set period / total number of verifications within the set period) is normalized. Dividing by the total number of verifications within the set period is to eliminate the impact of business volume fluctuations and make data from different periods comparable.

[0074] The frequency coefficient exhibits a piecewise positive correlation with the usage frequency, aiming to significantly increase the weight of high-frequency data. Let f represent the usage frequency, and the basic correspondence between usage frequency and the frequency coefficient is shown in Table 1 below.

[0075] Table 1: Exemplary Basic Correspondence Between Usage Frequency and Usage Frequency Coefficient

[0076] Step 203: Determine the weight of historical behavior data based on its basic security level, time decay coefficient, and usage frequency coefficient.

[0077] Specifically, the weight of historical behavior data is determined by multiplying the basic security level, time decay coefficient, and usage frequency coefficient.

[0078] The solution provided in this application determines the weight of historical behavior data based on its basic security level, time decay coefficient, and usage frequency coefficient. This enables the establishment of a dynamic weight calculation model for historical behavior data, achieving dynamic weight allocation to reflect the timeliness, usage frequency, and security reliability of the data.

[0079] In some embodiments, the method for determining the basic security level of each piece of historical behavior data includes: using a preset scoring card model to determine the scores of the historical behavior data under multiple preset evaluation dimensions, and determining the comprehensive score of the historical behavior data based on each score; and determining the basic security level of the historical behavior data based on the comprehensive score. The scoring card model is a model used to score historical behavior data based on multiple evaluation dimensions. These multiple evaluation dimensions include several of the aforementioned data stability, data privacy, data trustworthiness, and data timeliness.

[0080] Furthermore, among the score ranges corresponding to the preset multiple security levels, the target score range where the comprehensive score is located is determined, and the security level corresponding to the target score range is determined as the basic security level of the historical behavior data.

[0081] For example, taking the aforementioned security levels L1-L4 as an example, the scorecard model can assign a base score to different levels of each assessment dimension, and after weighted summation, map the scores to L1-L4 based on the score range. Each assessment dimension can be set to three levels: high, medium, and low. The scorecard model can convert these three levels into specific scores, such as high = 3 points, medium = 2 points, and low = 1 point. The scorecard model can determine the corresponding level of historical behavioral data for each assessment dimension and use the specific score corresponding to that level as the score.

[0082] The aforementioned evaluation dimensions can be assigned weights. The scorecard model can then use these weights to perform a weighted summation of the scores for historical behavioral data across these multiple evaluation dimensions, thereby obtaining a comprehensive score for the historical behavioral data.

[0083] The weighting principle for the aforementioned evaluation dimensions can be based on the degree of contribution of each dimension to determining whether "the current operator is the true owner of the account." The greater the contribution, the higher the weight. Taking data stability, data privacy, data trustworthiness, and data timeliness as examples, the exemplary weighting of these evaluation dimensions can be shown in Table 2 below.

[0084] Table 2: Exemplary weight allocation for the above evaluation dimensions

[0085] As an example, the score ranges corresponding to security levels L1-L4 can be as follows: L4: Overall score ≥ 2.8 (extremely high safety value); L3: 2.0 points ≤ Overall score < 2.8 points (high safety value); L2: 1.5 points ≤ Overall score < 2.0 points (Medium safety value); L1: Overall score <1.5 points (low safety value).

[0086] Below, we will use the assessment of the basic security level of historical behavioral data, such as a user's previously linked mobile phone number, as an example to illustrate this. Let's assume the dimensional level assessment result of this historical behavioral data is: Data reliability: High (3 points); This mobile number has been verified by the operator through real-name authentication and SMS verification code. Data stability: Medium (2 points); Users may change their numbers, but a mobile number is usually bound for several months or even years; Data privacy: High (3 points); Mobile phone numbers are considered sensitive personal information; Data timeliness: Medium (2 points); This mobile number was unbound 3 months ago.

[0087] Based on the weights in Table 2, the comprehensive score of this historical behavior data is (3 points × 40%) + (2 points × 30%) + (3 points × 20%) + (2 points × 10%) = 1.2 + 0.6 + 0.6 + 0.2 = 2.6 points. Through interval mapping, 2.6 points is determined to fall within the range of 2.0 points ≤ comprehensive score < 2.8 points as mentioned earlier, thus determining the basic security level of this historical behavior data as L3.

[0088] As a comparative case with the above example, let's evaluate the historical behavioral data of a user's profile picture used one year ago. Assume the dimensional level evaluation result of this historical behavioral data is as follows: Data reliability: Low (1 point, user-selected); Data stability: Low (1 point, can be replaced at any time); Data privacy: Low (1 point, publicly visible); Data timeliness: Low (1 point, too old).

[0089] Using a similar calculation process to the above case, the comprehensive score of this historical behavior data = 1.0 points → mapped to L1 level.

[0090] It is understandable that by using a quantitative scoring mapping method, complex and multidimensional evaluations can be objectively and consistently transformed into a basic security level that can be used for subsequent dynamic weight calculations and strategy generation. Weight allocation can be optimized according to actual business security strategies; for example, in financial-grade applications, the weight of data trustworthiness can be further increased.

[0091] In some embodiments, the method for determining the basic security level of each piece of historical behavior data includes: Using a pre-defined scoring card model, the scores of historical behavioral data are determined under multiple pre-defined evaluation dimensions, and the comprehensive score of historical behavioral data is determined based on each score. Using a pre-defined rule engine, determine how historical behavioral data triggers the rules in the rule engine; If historical behavior data triggers a rule in the rule engine, the basic security level of the historical behavior data is determined based on the triggered rule. If the historical behavior data does not trigger the rules in the rule engine, the basic security level of the historical behavior data is determined based on the comprehensive score.

[0092] The rules engine serves as a qualitative fallback mechanism. It sets certain hard rules that directly determine the basic security level when specific conditions are met. For example, if a piece of historical behavioral data has a value of "system authentication" (such as a mobile phone number verified by an authoritative institution) in the "data trustworthiness" dimension, then regardless of other dimensions, its basic security level is at least L3.

[0093] The basic security level is determined by a combination of "rule engine + scorecard model". This ensures both the clarity and interpretability of the rules and the flexibility for quantitative adjustment.

[0094] In some embodiments, the weights of historical behavioral data can be updated periodically to more effectively reflect the timeliness, frequency of use, and security and reliability of the data.

[0095] In some embodiments, after determining the authentication result, the weight of the target behavior data can be adjusted based on the authentication result. Specifically, when the authentication result is successful, the weight of the target behavior data is appropriately increased. When the authentication result is rejected, the weight of the target behavior data is appropriately decreased. It should be understood that the weight adjustment occurs after each authentication, and the weight of each piece of target behavior data used in the authentication is adjusted according to the authentication result.

[0096] The adjustment range of the weights can be determined by the following factors: Basic adjustment range (e.g., 0.1); Identity verification result: increase if successful, decrease if unsuccessful; Verification quality: A higher verification score results in a larger increase, while a lower verification score results in a smaller increase; for failures, the decrease is determined by the error type and severity. Scenario risk: Adjustments are more significant for high-risk scenarios; Historical performance of data: Data with high historical usage frequency and high credibility are adjusted less frequently (adjustments are made more cautiously).

[0097] For example, the rules for adjusting the weights of historical behavioral data may include: If the verification passes: Basic adjustment range = 0.1; Adjustments based on validation scores: If the validation score is high (e.g., >4.0), the base adjustment is multiplied by 1.5; if the validation score is medium (e.g., >3.0), the base adjustment is multiplied by 1.2; if the validation score is low (e.g., >2.0), the base adjustment is multiplied by 0.8. Adjust according to the security requirement level of the verification scenario: the higher the security requirement level, the larger the adjustment coefficient (for example, the adjustment coefficient for S5 is 1.5, and for S1 it is 0.5). Adjustments are made based on historical usage data: the more times a data is used, the smaller the adjustment coefficient becomes (e.g., more than 20 times, coefficient 0.6; more than 10 times, coefficient 0.8). Adjust based on data age: For older data (e.g., more than 1 year), the adjustment factor is reduced (e.g., 0.5). Final adjustment range = base adjustment range × product of all coefficients; New weight = old weight × (1 + final adjustment range); If verification fails: Severity is determined based on error type: Complete error (severity 1.0), Partial error (0.5), Timeout (0.3), Suspicious pattern (0.7); Base reduction margin = 0.1 × severity; Mitigation based on historical credibility: Higher historical credibility reduces the downsizing factor (e.g., credibility > 0.8, factor 0.5). Mitigation based on usage frequency: For high-frequency usage, reduce the coefficient (e.g., for usage frequency > 0.8, reduce the coefficient to 0.6). Final reduction amount = base reduction amount × product of all coefficients; New weight = Old weight × (1 - final reduction).

[0098] In addition, the adjustment rules for the weights of historical behavioral data can also limit the adjustment range to a reasonable range, for example, each adjustment shall not exceed 30%, and the weight range shall be between 0.1 and 5.0.

[0099] It should be understood that weight adjustment strategies can be designed according to actual needs, and no specific limitations are made here.

[0100] In some embodiments, the basic security level of historical behavior data can be adjusted based on verification-related information from the historical behavior data. This verification-related information reflects the actual performance of the historical behavior data during verification.

[0101] The adjustment of the basic security level includes both upgrade and downgrade determinations. When determining an upgrade, key performance indicators (KPIs) may include multiple factors such as verification success rate, usage stability, data timeliness (recent usage percentage), data consistency (consistency with other data), and risk performance (proportion of risk events). When determining a downgrade, key KPIs may include multiple factors such as verification failure rate, usage attenuation, data obsolescence, data inconsistency, and risk exposure.

[0102] Taking the core criteria for upgrading as an example, which include verification success rate, usage stability, data timeliness, data consistency, and risk performance, and the core criteria for downgrading as an example, which include verification failure rate, usage decay, data obsolescence, data inconsistency (inconsistency rate with other data), and risk exposure (proportion of risk events), the exemplary indicator information of the core criteria for upgrading and downgrading is shown in Table 3 below.

[0103] Table 3: Exemplary Indicator Information for Core Judgment Indicators of Promotion and Relegation

[0104] The overall score for promotion / demotion determination is calculated as Σ(score of individual indicator × weight). In one example, a promotion requires an overall score ≥ 0.85, while a demotion is triggered when the overall score is ≤ 0.4.

[0105] As an example, the triggering conditions and rules for adjusting the basic security level can be shown in Table 4 below.

[0106] Table 4: Exemplary Triggering Conditions and Rules for Adjusting Basic Security Levels

[0107] By adjusting the triggering conditions and rules as described above, the system can automatically and robustly manage data security levels, ensuring that high-value data is reused and low-quality or high-risk data is downgraded.

[0108] In some embodiments, the security requirement level of each verification scenario can be adjusted based on the security event statistics of each verification scenario within a set time period.

[0109] As an example, security incidents can be divided into four levels according to their severity, corresponding to different weights and response requirements, as shown in Table 5 below.

[0110] Table 5: Exemplary Definition Criteria for Security Incidents

[0111] Key statistical indicators for security incidents may include: Event density = (∑(number of events × weight) / total number of verifications) × 1000; Attack success rate = Number of successful attacks / Total number of attack attempts.

[0112] Adjustments to security requirement levels can be triggered at different levels based on different time windows and analysis results. For example, exemplary triggering conditions and magnitudes for security requirement level adjustments are shown in Table 6 below.

[0113] Table 6: Exemplary Triggering Conditions and Scope for Security Requirement Level Adjustments

[0114] It should be noted that the core factors in calculating the magnitude of security requirement level adjustments can include several of the following: Base adjustment / reduction factor: depends on the adjustment type; Scenario risk coefficient: The adjustment range is larger for high-risk scenarios (such as S5 account recovery); Time decay coefficient: The longer the time since the last adjustment, the stronger the adjustment effect; Smoothing mechanism: The more frequent the recent adjustments, the smaller the actual adjustment range in a single instance.

[0115] In addition, hard restrictions on adjusting security requirement levels may include: Single amplitude: not exceeding ±50%; Threshold range: It must not be lower than 50% of the base value, or higher than 200%; Adjustment frequency: A maximum of 2 adjustments can be made within 7 days for the same scenario.

[0116] In summary, the solution provided by the embodiments of this application has the following beneficial effects: Scenario-adaptive verification: The verification strategy is dynamically adjusted according to different verification scenarios. High-security historical data is used in high-risk scenarios (such as account recovery), while low-security historical data is used in low-risk scenarios (such as daily login), achieving the optimal balance between security and user experience.

[0117] Multidimensional data utilization: Comprehensive utilization of users' multidimensional historical behavioral data (nickname, mobile phone number, device, behavioral patterns, etc.) to form a comprehensive user "digital fingerprint" and increase the difficulty for attackers to simulate.

[0118] Dynamic weighting mechanism: The weights of historical data are dynamically adjusted through factors such as time decay and usage frequency to ensure the verification system's adaptability to the latest user behavior patterns.

[0119] Progressive verification experience: When verification fails, the verification strategy can be automatically upgraded (selecting historical data with a higher security level), without requiring the user to manually select a verification method.

[0120] Anti-forgetting feature: When a user forgets some historical information, the system can still pass the verification based on the successful verification of other historical data, reducing the risk of account lockout due to forgetting.

[0121] Feedback-learning optimization mechanism: Based on the identity verification results, the weight of historical behavior data and the basic security level, as well as the security requirement level of the verification scenario, are dynamically adjusted to achieve self-optimization of the system.

[0122] Figure 3 This is a schematic diagram of the user authentication device provided in an embodiment of this application. Figure 3 As shown, the user authentication device includes: The scene recognition unit 301 is configured to acquire the user's verification request and determine the target verification scene from a set of multiple preset verification scenes based on the verification request; wherein, each verification scene corresponds to a security level threshold. The acquisition unit 302 is configured to acquire the user's historical behavior dataset, and each piece of historical behavior data in the historical behavior dataset is configured with a basic security level and weight. The first processing unit 303 is configured to determine candidate behavior data in the historical behavior dataset that meet the target security level threshold corresponding to the target verification scenario based on the basic security level. The second processing unit 304 is configured to determine the target behavior data from each candidate behavior data, generate a verification question based on the target behavior data, and output the verification question to the user. Verification unit 305 is configured to obtain user answer information corresponding to the verification question based on the weight of each candidate behavior data, and determine the identity verification result based on the user answer information.

[0123] For details regarding the implementation of the user authentication device and its various units, as well as their beneficial effects, please refer to the relevant descriptions in the method embodiments above; they will not be repeated here.

[0124] Accordingly, this application also provides an electronic device, which can be a terminal, such as a smartphone, tablet computer, laptop computer, touch screen, game console, personal computer (PC), personal digital assistant (PDA), or other terminal device. Alternatively, the electronic device can be a server.

[0125] like Figure 4 As shown, Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device 400 includes a processor 401 with one or more processing cores, a memory 402 with one or more computer-readable storage media, and a computer program stored in the memory 402 and executable on the processor. The processor 401 and the memory 402 are electrically connected. Those skilled in the art will understand that the electronic device structure shown in the figure does not constitute a limitation on the electronic device, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0126] The processor 401 is the control center of the electronic device 400. It connects various parts of the electronic device 400 via various interfaces and lines. By running or loading software programs and / or units stored in the memory 402, and by calling data stored in the memory 402, it executes various functions and processes data of the electronic device 400, thereby providing overall monitoring of the electronic device 400. The processor 401 can be a central processing unit (CPU), a graphics processing unit (GPU), a network processor (NP), etc., and can implement or execute the methods, steps, and logic diagrams disclosed in the embodiments of this application.

[0127] In this embodiment, the processor 401 in the electronic device 400 loads the instructions corresponding to the processes of one or more applications into the memory 402 according to the following steps, and the processor 401 runs the applications stored in the memory 402 to realize various functions, such as: Obtain the user's verification request, and determine the target verification scenario from multiple preset verification scenarios based on the verification request; wherein, each verification scenario corresponds to a security level threshold; Obtain the user's historical behavior dataset. Each historical behavior data point in the dataset is configured with a basic security level and weight. In the historical behavior dataset, candidate behavior data that meet the target security level threshold corresponding to the target verification scenario are identified; Based on the weight of each candidate behavior data, the target behavior data is determined from the candidate behavior data, a verification question is generated based on the target behavior data, and the verification question is output to the user. Obtain the user's answer information corresponding to the verification question, and determine the identity verification result based on the user's answer information.

[0128] The user authentication method described above enables scenario-adaptive authentication strategies, ensuring that high-security historical behavioral data is used in high-risk scenarios, while also achieving a balance between security and user experience.

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

[0130] Optional, such as Figure 4 As shown, the electronic device 400 also includes: a touch display screen 403, a radio frequency circuit 404, an audio circuit 405, an input unit 406, and a power supply 407. The processor 401 is electrically connected to the touch display screen 403, the radio frequency circuit 404, the audio circuit 405, the input unit 406, and the power supply 407. Those skilled in the art will understand that... Figure 4 The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0131] The touch display screen 403 can be used to display a graphical user interface (GUI) and receive operation commands generated by the user interacting with the GUI. The touch display screen 403 may include a display panel and a touch panel. The display panel can be used to display information input by the user or information provided to the user, as well as various graphical user interfaces of the electronic device. These graphical user interfaces can be composed of graphics, text, icons, video, and any combination thereof. Optionally, the display panel can be configured using a liquid crystal display (LCD), organic light-emitting diode (OLED), or other similar technologies. The touch panel can be used to collect touch operations performed by the user on or near it (such as operations performed by the user using a finger, stylus, or any suitable object or accessory on or near the touch panel), generate corresponding operation commands, and execute the corresponding program according to the operation commands. Optionally, the touch panel may include two parts: a touch detection device and a touch controller. The touch detection device detects the user's touch location and the signal generated by the touch operation, transmitting the signal to the touch controller. The touch controller receives touch information from the touch detection device, converts it into touch point coordinates, and sends it to the processor 401. It can also receive and execute commands from the processor 401. The touch panel can cover the display panel. When the touch panel detects a touch operation on or near it, it transmits the information to the processor 401 to determine the type of touch event. Subsequently, the processor 401 provides corresponding visual output on the display panel based on the type of touch event. In this embodiment, the touch panel and the display panel can be integrated into the touch display screen 403 to achieve input and output functions. However, in some embodiments, the touch panel and the touch display screen 403 can be implemented as two independent components to achieve input and output functions. That is, the touch display screen 403 can also be used as part of the input unit 406 to achieve input functions.

[0132] The radio frequency circuit 404 can be used to transmit and receive radio frequency signals to establish wireless communication with network devices or other electronic devices, and to transmit and receive signals with network devices or other electronic devices.

[0133] Audio circuit 405 can be used to provide an audio interface between a user and an electronic device via a speaker and a microphone. Audio circuit 405 can convert received audio data into electrical signals and transmit them to the speaker, where the speaker converts them into sound signals for output. Conversely, the microphone converts collected sound signals into electrical signals, which are then received by audio circuit 405, converted back into audio data, and then processed by processor 401 before being transmitted via radio frequency circuit 404 to, for example, another electronic device, or output to memory 402 for further processing. Audio circuit 405 may also include an earphone jack to provide communication between peripheral headphones and electronic devices.

[0134] The input unit 406 can be used to receive input numbers, characters, or user characteristic information (such as fingerprints, iris, facial information, etc.), and to generate keyboard, mouse, joystick, optical, or trackball signal inputs related to user settings and function control.

[0135] Power supply 407 is used to supply power to various components of electronic device 400. Optionally, power supply 407 can be logically connected to processor 401 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. Power supply 407 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0136] although Figure 4 As not shown in the diagram, the electronic device 400 may also include a camera, sensor, wireless fidelity module, Bluetooth module, etc., which will not be described in detail here.

[0137] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0138] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0139] Therefore, embodiments of this application provide a computer-readable storage medium storing multiple computer programs that can be loaded by a processor to execute the user authentication method provided in this application. The computer program can perform the following steps of the user authentication method: Obtain the user's verification request, and determine the target verification scenario from multiple preset verification scenarios based on the verification request; where each verification scenario corresponds to a security level threshold; Obtain the user's historical behavior dataset. Each historical behavior data point in the dataset is configured with a basic security level and weight. In the historical behavior dataset, candidate behavior data that meet the target security level threshold corresponding to the target verification scenario are identified; Based on the weight of each candidate behavior data, the target behavior data is determined from the candidate behavior data, a verification question is generated based on the target behavior data, and the verification question is output to the user. Obtain the user's answer information corresponding to the verification question, and determine the identity verification result based on the user's answer information.

[0140] The user authentication method described above enables scenario-adaptive authentication strategies, ensuring that high-security historical behavioral data is used in high-risk scenarios, while also achieving a balance between security and user experience.

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

[0142] The computer-readable storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0143] Since the computer program stored in the computer-readable storage medium can execute any of the user authentication methods provided in the embodiments of this application, it can achieve the beneficial effects that any of the user authentication methods provided in the embodiments of this application can achieve, as detailed in the preceding embodiments, and will not be repeated here.

[0144] According to one aspect of this application, a computer program product or computer program is also provided, comprising computer instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the electronic device to perform the methods provided in the various optional implementations of the above embodiments.

[0145] In the above embodiments of user authentication methods, user authentication devices, user authentication systems, computer-readable storage media, electronic devices, and computer program products, the descriptions of each embodiment have different focuses. Parts not described in detail in a particular embodiment can be referred to in the relevant descriptions of other embodiments. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes and beneficial effects of the user authentication methods, user authentication devices, user authentication systems, computer-readable storage media, computer program products, electronic devices, and their corresponding units described above can be referred to the descriptions of the relevant methods in the above embodiments, and will not be repeated here.

[0146] It should be noted that, in the data processing stage, the technical solution of this application has strictly limited the scope of data collection to the minimum necessary to achieve the technical objectives, preventing the acquisition of irrelevant information. For any user information to be collected, the data subject will be clearly informed and their consent obtained. Furthermore, technologies such as encrypted storage and access control are employed to strengthen data security and ensure the security and compliance of the entire data processing process. The technical model and decision-making mechanism are based on objective technical parameters and do not introduce unnecessary parameters such as gender or age that may lead to discrimination, resolutely eliminating algorithmic discrimination and upholding public order and good morals. In addition, the specification fully describes the technical implementation methods, application scenarios, and compliance protection details. The claims are consistent with the content of the specification, key compliance designs are clear and verifiable, and the overall technical design is guided by the protection of public interests and adherence to social ethics, without any circumstances that harm public interests or violate public order and good morals.

[0147] The foregoing has provided a detailed description of a user authentication method, apparatus, electronic device, and storage medium provided in the embodiments of this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A user identity authentication method, characterized by, include: Obtain the user's verification request, and determine the target verification scenario from multiple preset verification scenarios based on the verification request; wherein, each verification scenario corresponds to a security level threshold; Obtain the user's historical behavior dataset, where each historical behavior data point is configured with a basic security level and weight; In the historical behavior dataset, candidate behavior data that meet the target security level threshold corresponding to the target verification scenario are identified. Based on the weight of each candidate behavior data, target behavior data is determined from each candidate behavior data, a verification question is generated based on the target behavior data, and the verification question is output to the user; Obtain the user's answer information corresponding to the verification question, and determine the identity verification result based on the user's answer information.

2. The user authentication method according to claim 1, characterized by, Each of the aforementioned verification scenarios also corresponds to a minimum verification strength; Based on the weights of each candidate behavior data, target behavior data is determined from the candidate behavior data, including: The target behavior data is determined from the candidate behavior data based on the weight of each candidate behavior data and the minimum verification strength corresponding to the target verification scenario.

3. The user authentication method according to claim 2, characterized by, Based on the weights of each candidate behavior data and the minimum verification strength corresponding to the target verification scenario, the target behavior data is determined from the candidate behavior data, including: The candidate behavior data are sorted according to their respective weights to obtain a behavior data sequence; Starting from the side with the highest weight in the behavior data sequence, the candidate behavior data are selected sequentially until the sum of the weights of the selected candidate behavior data is greater than or equal to the target minimum verification strength. Each candidate behavior data selected from the behavior data sequence is used as the target behavior data.

4. The user authentication method according to claim 1, characterized by, The method for determining the weight of each piece of historical behavior data includes: The time decay coefficient is determined based on the timestamps of the historical behavior data; Based on the usage frequency of the historical behavior data within a set period, a usage frequency coefficient is determined; The weight of the historical behavior data is determined based on the basic security level, the time decay coefficient, and the usage frequency coefficient of the historical behavior data.

5. The user authentication method according to claim 1, characterized by, The historical behavior dataset corresponds to multiple different data types, and each data type is configured with a question generation strategy; Generate validation questions based on the target behavior data, including: For each piece of target behavior data, a verification question is generated based on the target behavior data using the question generation strategy corresponding to the data type to which the target behavior data belongs.

6. The user authentication method according to claim 1, characterized by, Determining the authentication result based on the user's response information includes: The verification score is determined based on the user's response information; The authentication result is determined based on the comparison between the verification score and the score threshold.

7. The user authentication method according to claim 6, wherein Each of the verification scenarios also corresponds to a minimum verification strength. The sum of the weights of the target behavior data is greater than or equal to the target minimum verification strength corresponding to the target verification scenario. The score threshold is the target minimum verification strength. Each piece of target behavior data corresponds to one verification question. Based on the user's response information, a verification score is determined, including: Based on the user's answer information, determine the target verification question that was answered correctly from among the verification questions; The verification score is determined by summing the weights of the target behavior data corresponding to each of the target verification questions.

8. A user identity authentication apparatus, characterized by comprising: include: The scene recognition unit is configured to acquire the user's verification request and determine the target verification scene from a set of preset verification scenes based on the verification request; wherein each verification scene corresponds to a security level threshold. The acquisition unit is configured to acquire the user's historical behavior dataset, wherein each piece of historical behavior data in the historical behavior dataset is configured with a basic security level and weight. The first processing unit is configured to determine, from the historical behavior dataset, candidate behavior data whose basic security level meets the target security level threshold corresponding to the target verification scenario; The second processing unit is configured to determine target behavior data from the candidate behavior data according to the weight of each candidate behavior data, generate a verification question based on the target behavior data, and output the verification question to the user. The verification unit is configured to obtain user answer information corresponding to the verification question and determine the identity verification result based on the user answer information.

9. An electronic device, comprising: It includes a memory and a processor, wherein the memory stores a computer program that, when executed by the processor, implements the user authentication method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, It stores a computer program, which is loaded by a processor to perform the steps of the user authentication method according to any one of claims 1-7.

Images