Login management method and device, electronic equipment and computer readable storage medium

Abstract

The invention provides a login management method and device, electronic equipment and a computer readable storage medium, and the method comprises the steps: obtaining an object identifier and a first client version identifier contained in a login request when the login request is received; identifying a risk level of a target object corresponding to the object identifier; searching for first version information of the target client based on the first client version identifier, wherein the first version information indicates that the target client has a first risk management and control capability; second version information corresponding to the risk level is determined, the second version information indicates a second risk management and control capability, and the second risk management and control capability is the lowest risk management and control capability required by a client allowing an object corresponding to the risk level to log in the target application; and when the first risk management and control capability is lower than the second risk management and control capability, forbidding the target object to log in the target application based on the login request. According to the embodiment of the invention, the application data security can be improved. The embodiment of the invention can be applied to the fields of information security and the like.

Description

Technical Field

[0001] The present disclosure relates to the field of information security, and in particular to a login management method, device, electronic device and computer-readable storage medium. Background Art

[0002] With the continuous development of Internet technology and mobile terminal technology, the types of computer applications are gradually increasing and the quality is constantly improving. The continuous development of computer applications has gradually transferred many affairs in production and life from offline to online processing, greatly improving production efficiency and improving life experience.

[0003] However, current risk management of computer applications at client login is insufficient, resulting in security risks for data stored in computer applications. Summary of the invention

[0004] The embodiments of the present disclosure provide a login management method, apparatus, storage medium and computer equipment, which can improve data security in computer applications.

[0005] According to one aspect of the present disclosure, there is provided a login management method, comprising:

[0006] When receiving a login request, obtaining an object identifier and a first client version identifier included in the login request;

[0007] Identify the risk level of the target object corresponding to the object identifier;

[0008] searching first version information of a target client based on the first client version identifier, the target client being a client that issues the login request and corresponds to a target application, the first version information indicating that the target client has a first risk management capability;

[0009] Determine second version information corresponding to the risk level, where the second version information indicates a second risk control capability, where the second risk control capability is a minimum risk control capability required for allowing an object corresponding to the risk level to log in to a client of the target application;

[0010] When the first risk management capability is lower than the second risk management capability, the target object is prohibited from logging into the target application based on the login request.

[0011] According to one aspect of the present disclosure, there is provided a login management device, comprising:

[0012] A first acquisition unit, configured to, when receiving a login request, acquire an object identifier and a first client version identifier contained in the login request;

[0013] An identification unit, used to identify the risk level of the target object corresponding to the object identifier;

[0014] a searching unit, configured to search for first version information of a target client based on the first client version identifier, wherein the target client is a client that issues the login request and corresponds to a target application, and the first version information indicates that the target client has a first risk management capability;

[0015] A determination unit determines second version information corresponding to the risk level, where the second version information indicates a second risk control capability, where the second risk control capability is a minimum risk control capability required for allowing an object corresponding to the risk level to log in to a client of the target application;

[0016] A login prohibiting unit is used to prohibit the target object from logging into the target application based on the login request when the first risk management capability is lower than the second risk management capability.

[0017] Optionally, in some embodiments, the login management device further includes:

[0018] a ticket issuing unit, configured to issue an access ticket to the target client when the first risk control capability is not lower than the second risk control capability, wherein the access ticket carries a version identifier of the first client;

[0019] A security detection unit, configured to receive a data access request carrying the access ticket, and perform a security detection on the data access request based on the first client version identifier;

[0020] The access prohibition unit is used to prohibit the sender of the data access request from accessing the business data when the security detection result of the data access request is unqualified.

[0021] Optionally, in some embodiments, the safety detection unit is specifically used to:

[0022] When receiving a data access request carrying the access ticket, obtaining a second client version identifier of a sender of the data access request;

[0023] When it is detected that the first client version identifier matches the second client version identifier, determining that the security detection result of the data access request is qualified;

[0024] When it is detected that the first client version identifier does not match the second client version identifier, it is determined that the security detection result of the data access request is unqualified.

[0025] Optionally, in some embodiments, the login management device further includes:

[0026] A second acquisition unit, used to acquire multiple version information of multiple applications;

[0027] A normalization unit, configured to normalize the multiple version information of the multiple applications to obtain a first mapping relationship table, wherein the first mapping relationship table stores a client version identifier corresponding to each version information of each application;

[0028] The searching unit is specifically used for:

[0029] The first version information of the target client is searched in the first mapping table based on the first client version identifier.

[0030] Optionally, in some embodiments, the normalization unit is specifically used to:

[0031] Generate a first field based on application information of each application, generate a second field based on platform information of different platforms, and generate a third field based on different version information of each application;

[0032] A field combination corresponding to different version information of each application on different platforms is determined to obtain a first mapping relationship table, where the field combination is a combination of the first field, the second field, and the third field.

[0033] Optionally, in some embodiments, the login management device further includes:

[0034] A third acquisition unit, used to acquire a preset mapping relationship table update frequency;

[0035] An updating unit is used to reacquire multiple new version information of the multiple applications based on the update frequency of the mapping relationship table, and update the first mapping relationship table based on the multiple new version information of the multiple applications.

[0036] Optionally, in some embodiments, the determining unit includes:

[0037] Obtaining a second mapping relationship table, wherein the second mapping relationship table stores mapping relationships between different risk levels and baseline versions of different applications, wherein the baseline version is a version with the lowest risk control capability that can be used by objects of corresponding risk levels;

[0038] Based on the risk level, search the second mapping relationship table for second version information corresponding to the target application.

[0039] Optionally, in some embodiments, the determining unit includes:

[0040] Receive the baseline version editing instructions input by the operation management personnel;

[0041] A second mapping relationship table is generated based on the baseline version editing instruction.

[0042] Optionally, in some embodiments, the login management device further includes:

[0043] a prompting unit, configured to send a login prohibition prompt to the target client when the first risk management capability is lower than the second risk management capability, and

[0044] Send a version update notification to the target client.

[0045] Optionally, in some embodiments, the identification unit includes:

[0046] Acquire a first object feature and a first operation feature of a target object corresponding to the object identifier;

[0047] A risk level of the target object is determined according to the first object feature and the first operation feature.

[0048] Optionally, in some embodiments, the login management device further includes:

[0049] A fourth acquisition unit, used to acquire an associated object of the target object;

[0050] A fifth acquisition unit, configured to acquire a second object feature and a second operation feature of the associated object;

[0051] The determining unit is specifically used for:

[0052] A risk level of the target object is determined according to the first object feature, the first operation feature, the second object feature, and the second operation feature.

[0053] Optionally, in some embodiments, the fourth acquiring unit is specifically configured to:

[0054] Obtaining a target client that issues the login request;

[0055] Acquire associated objects other than the target object that have logged in on the target client.

[0056] According to one aspect of the present disclosure, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor implements the login management method as described above when executing the computer program.

[0057] According to one aspect of the present disclosure, a computer-readable storage medium is provided, wherein the storage medium stores a computer program, and when the computer program is executed by a processor, the login management method as described above is implemented.

[0058] According to one aspect of the present disclosure, a computer program product is provided. The computer program product includes a computer program. The computer program is read and executed by a processor of a computer device, so that the computer device executes the login management method as described above.

[0059] The login management method in the embodiment of the present disclosure, when receiving a login request, obtains the object identifier and the first client version identifier contained in the login request; identifies the risk level of the target object corresponding to the object identifier; searches for the first version information of the target client based on the first client version identifier, the target client is the client that issues the login request and corresponds to the target application, and the first version information indicates that the target client has a first risk management capability; determines the second version information corresponding to the risk level, the second version information indicates the second risk management capability, and the second risk management capability is the minimum risk management capability required for the client to allow the object corresponding to the risk level to log in to the target application; when the first risk management capability is lower than the second risk management capability, prohibits the target object from logging in to the target application based on the login request.

[0060] In this way, the login management method of the disclosed embodiment determines the first risk control capability of the target client currently used by the target object to log in to the target application according to the first client version identifier; and determines the minimum risk control capability required by the target client for the target object to log in to the target application according to the risk level of the target object. If the first risk control capability of the target client is lower than the minimum risk control capability, the target object is prohibited from logging in to the target application through the target client to avoid possible login risks. Therefore, the disclosed embodiment can effectively prevent abnormal objects from logging in to the application through a client with low risk control capabilities, thereby improving the security of application data.

[0061] Other features and advantages of the present disclosure will be described in the following description, and partly become apparent from the description, or understood by practicing the present disclosure. The purpose and other advantages of the present disclosure can be realized and obtained by the structures particularly pointed out in the description, claims and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0062] The accompanying drawings are used to provide further understanding of the technical solution of the present disclosure and constitute a part of the specification. Together with the embodiments of the present disclosure, they are used to explain the technical solution of the present disclosure and do not constitute a limitation on the technical solution of the present disclosure.

[0063] Figure 1 is a system architecture diagram of a login management method application according to an embodiment of the present disclosure;

[0064] Figure 2a-2bis a schematic diagram of a login management method according to an embodiment of the present disclosure applied in a client login scenario;

[0065] Figure 3 is a flowchart of a login management method according to an embodiment of the present disclosure;

[0066] Figure 4 It is a flowchart of identifying the risk level of the target object corresponding to the object identification;

[0067] Figure 5 It is a schematic diagram of the structure of the version management module storing the version database;

[0068] Figure 6 This is a schematic diagram of a process of searching for the first version information of the target client based on the first mapping relationship table;

[0069] Figure 7 It is a schematic diagram of the correspondence between the risk level of the object and the minimum risk control capability;

[0070] Figure 8a-8c It is a schematic diagram of the interface for operation management personnel to manage version baselines through the operation management terminal;

[0071] Fig. 9 is a schematic diagram of a process of searching for second version information based on a second mapping relationship table;

[0072] Fig.10 It is a system architecture diagram for performing security checks before accessing business data;

[0073] Fig.11 is another flowchart of the login management method provided by the present disclosure;

[0074] Fig.12 is another flowchart of the login management method provided by the present disclosure;

[0075] Fig.13a is a statistical bar chart of the number of malicious behaviors that occurred in each application when the login management method disclosed in the present invention is not used;

[0076] Fig.13b It is a statistical bar chart of the number of malicious behaviors that occurred in each application after using the login management method disclosed in the present invention;

[0077] Fig.14 is a structural diagram of a login management device according to an embodiment of the present disclosure;

[0078] Fig.15 is a terminal structure diagram for implementing various methods according to an embodiment of the present disclosure;

[0079] Fig.16It is a server structure diagram for implementing various methods according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0080] In order to make the purpose, technical solution and advantages of the present disclosure more clear, the present disclosure is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present disclosure and are not used to limit the present disclosure.

[0081] Before further describing the embodiments of the present disclosure in detail, the nouns and terms involved in the embodiments of the present disclosure are described. The nouns and terms involved in the embodiments of the present disclosure are subject to the following interpretations:

[0082] Version number: It is the identification number of the version. Every operating system (or in a broad sense, every software) and client has a version number. The application version number is generally divided into three items: <main version number>.<sub-version number>.<stage version number>, for example, 1.1.1. The modification rule of the main version number is when there are major changes in the functional modules, such as adding multiple modules or changes in the overall architecture; the modification rule of the sub-version number is when there are certain additions or changes in the functions, such as adding permission control, adding custom views and other functions; the modification rule of the stage version number is when bug fixes are made or some minor changes are made.

[0083] Access ticket: An access ticket is a string of characters generated by the server, which is used as a token for the client to make requests. When you log in to the application for the first time, the server will generate an access ticket and return it to the client. When the object uses the client to access data, it only needs to bring this access ticket to request data without having to make a login request again. Access tickets generally have a time limit. If there is no data request within the specified time, the access ticket will become invalid. The next time you want to access data, you need to re-initiate a login request.

[0084] Network security audit: The client will carry client data when requesting backend services. The server will aggregate various traffic data reported by the client and use big data analysis, machine learning and other technologies to quickly identify and handle network attacks and provide some real-time blocking capabilities.

[0085] With the expansion of computer application traffic, more and more risky accounts have appeared in computing applications to engage in harmful activities that endanger the data security of computer applications. Risky accounts often use some vulnerabilities stored in the client of the login application to attack computer applications. In order to solve the vulnerabilities in the client, it is necessary to upgrade the client, and the security defense capability of the client will be improved with the upgrade of the client version. In order to avoid the audit of the client version with high security defense capability, the risky account will still use the client with a lower version to log in to the application. In order to solve this problem, some computer applications currently force the object to upgrade the client to the latest version, but this will affect the normal use of computer applications by many non-risk accounts, such as the new version of the client is incompatible with the device of the object, or because the object is not accustomed to the operation of the new version of the client, it brings additional learning costs to the object. Therefore, forcing all objects to upgrade the client version to the latest version can avoid risky accounts from avoiding security audits, but it affects the normal use of computer applications by non-risk accounts. In this regard, the embodiment of the present disclosure provides a login management method, so as to improve the data security of the application while ensuring the normal use of computer applications by the object.

[0086] System architecture and scenario description of the application of the embodiments of the present disclosure

[0087] Figure 1 It is a system architecture diagram applied by the login management method according to the embodiment of the present disclosure. It includes a terminal 110 and a server 120, wherein the server 120 includes a login module 121, a version management module 122, a risk control capability verification module 123 and a risk level assessment module 124.

[0088] The terminal 110 includes desktop computers, laptop computers, PDAs (personal digital assistants), mobile phones, vehicle-mounted terminals, home theater terminals, dedicated terminals, intelligent voice interaction devices, smart home appliances, aircraft, etc. In addition, it can be a single device or a collection of multiple devices. The terminal 110 can communicate with the server 120 in a wired or wireless manner to exchange data.

[0089] The server 120 refers to a computer system that can provide certain services to the terminal 110. Compared with the ordinary terminal 110, the server 120 has higher requirements in terms of stability, security, performance, etc. The server 120 can be a high-performance computer in a network platform, a cluster of multiple high-performance computers, a part of a high-performance computer (such as a virtual machine), a combination of parts of multiple high-performance computers (such as virtual machines), etc.

[0090] The login module 121 in the server 120 is used to receive a login request from the terminal 110, and needs to extract the object identifier of the target object in the login request and the first client version identifier of the target client that sends the login request, and send them to the serial risk control capability verification module 123. When the first risk control capability is lower than the second risk control capability, the login module 121 prohibits the target object from logging into the target application through the target client.

[0091] The version management module 122 in the server 120 stores client version information of different versions of multiple applications. When the client version is updated, the client version information will be stored in the version management module 122.

[0092] The risk control capability verification module 123 is used to verify whether the first risk control capability of the target client is lower than the minimum risk control capability required by the target client. The risk control capability verification module 123 receives the object identifier and the first client version identifier from the login module 121, and checks the first version information corresponding to the first client version identifier from the version management module 122. The risk level assessment module 124 is used to identify the risk level of the target object corresponding to the object identifier, and determine the second risk control capability corresponding to the risk level. Verify whether the first risk control capability is lower than the second risk control capability.

[0093] The risk level assessment module 124 is used to identify the risk level of the target object and return the risk level to the risk management and control capability verification module 123 .

[0094] The embodiments of the present disclosure can be applied in various scenarios, such as Figure 2a-2b The client login scenario shown, etc.

[0095] In order to avoid data security threats caused by risky accounts logging into computer applications, when an account logs into a computer application through a terminal 110 client, it is necessary to verify whether the client's risk management capability is higher than the minimum requirement of the computer application for the client's risk management capability used by the target object. Figure 2a As shown, when the target object opens the client, he enters the account number and password, and clicks "Login" after entering the password. Server 120 will conduct a risk assessment on the account. Since the account often spreads harmful information to other accounts through the application, it is assessed as a high-risk account. In order to implement accurate security audits on high-risk accounts, high-risk accounts are required to use the latest version of the client to log in to the application. However, the current client used by the account to log in to the application this time is an old version of the client. Therefore, it is easy for high-risk accounts to evade security audits using the current client. In order to improve the data security of the application platform, it is necessary to prohibit objects from logging in to the application through the current client. As shown in Figure 2bAs shown, a message "Login prohibited" is displayed on the terminal 110 of the object, and the object is prompted that "The client version you are currently using is too low, please update the client to the latest version and try again." Through the above process, risky accounts can be prevented from using unqualified clients to log in to the target application, thereby improving the security of application data.

[0096] General description of the disclosed embodiments

[0097] According to an embodiment of the present disclosure, a login management method is provided. The method can be used for Figure 2a-2b The client login scenario shown, etc.

[0098] like Figure 3 As shown, it is a flow chart of the login management method provided by the present disclosure. The method can be applied to the login management device. The login management method may include:

[0099] Step 310: When a login request is received, obtain the object identifier and the first client version identifier contained in the login request.

[0100] The login management method of the disclosed embodiment can be used for login management of one application or for login management of multiple applications. Therefore, if multiple login requests are received, they may be login requests for one application or for multiple applications. Since an application can also log in on multiple platforms, the clients used by different platforms may be different. Therefore, further, multiple login requests may be login requests from clients of different applications on different platforms. For example, an application can be logged in on a mobile phone and a computer, so the login requests for the application may include a mobile phone login request and a computer login request.

[0101] Each login request contains an object identifier and a first client version identifier. The object identifier refers to the identifier of the object that initiates the login request. When registering an application, the application will assign a unique identifier to the object, and the operation of the object in the application can be queried through the object identifier. The first client version identifier indicates the version information of the client that logs in to the application. As the client is upgraded, different client versions correspond to different first client version identifiers.

[0102] The login request may also include the object's account and password for logging into the application platform. If the object is allowed to log into the application through the current client, the login module 121 executes the verification logic for the correctness of the account and password. After passing the verification, the object logs into the application and can access the data in the application.

[0103] Step 320: Identify the risk level of the target object corresponding to the object identifier.

[0104] For a login request, the target object may be the object that initiated the login request. The risk level is used to indicate the degree of data security threat posed by the object to the login application. The risk level can be divided into multiple levels based on the degree of data security threat posed by the object in the application. For example, the risk levels include: high risk, medium risk, low risk and no risk. Among them, a high-risk object may be an object that poses a serious threat to the system stability and security of the application, and a no-risk object may be an object that performs normal activities in the application and has no bad behavior.

[0105] For objects with higher risk levels, higher requirements are placed on the security defense capabilities of the application. Since the security of the application client will increase with the version upgrade, objects with higher risk levels require a more secure client version.

[0106] In one implementation, identifying the risk level of the target object corresponding to the object identifier includes:

[0107] Acquire a first object feature and a first operation feature of a target object corresponding to the object identifier;

[0108] A risk level of the target object is determined according to the first object feature and the first operation feature.

[0109] The first object feature may include static data features during the target object's use of the application, such as account nicknames and account descriptions. If the account has risky behavior, bad information may be transmitted through account nicknames and account descriptions. The static data features of the target object are generally set actively by the target object, and the information set by the target object in the system can be directly extracted as the first object feature.

[0110] The first object feature may also include device information of the terminal 110 used by the target object to log in to the application, such as processor parameters and system parameters. Device information can be obtained by directly accessing the device. Device information can reflect the security protection capability of the device used by the object. Systems with lower security protection capabilities can more easily facilitate high-risk objects to attack the application through the client. Therefore, analyzing the actions of the object in combination with device information can improve the accuracy of determining the risk level.

[0111] The first object feature may also include a feature of the geographical region where the target object is located when the login request is initiated. The geographical region may be an administrative geographical region, for example, region A and region B. If the geographical region where the server that manages the application data is located is different from the geographical region where the target object is located when the login request is initiated, the target object may use the difference in geographical regions to find loopholes in the application system and attack the application system. Therefore, considering the geographical region where the target object is located when determining the risk level can effectively reduce the attack behavior caused by network management loopholes.

[0112] The geographical area feature can be obtained from the positioning information of the terminal 110 of the target object. The terminal 110 of the target object has a positioning device such as GPS and Beidou, and the positioning device can continuously obtain the positioning information of the target terminal 110. The geographical area where the target object is currently located can be determined based on the positioning information as the geographical area feature. For example, based on the GPS positioning information obtained by the positioning device, it is mapped onto an electronic map and it is found that it belongs to area A, then the geographical area feature "area A" is obtained.

[0113] Note that when obtaining the first object feature of the target object, the consent of the target object must be obtained in advance. Moreover, the collection, use and processing of these features will comply with relevant laws, regulations and standards. When obtaining the consent of the target object, the target object's separate permission or consent can be obtained through a pop-up window or by jumping to a confirmation page.

[0114] The first operation feature is obtained through an event that occurs in the target object in the application. The first operation feature of the target object corresponding to the object identifier can be obtained by obtaining the historical operation log of the target object, and obtaining the operation record of the target object in the application from the historical operation log. The historical operation log records all events that have occurred in the account since the target object created the account in chronological order. For example, Table 1 is an example of a historical operation log of an object in a session application.

[0115] time event 2023.8.1 12:01:20 Log in to the app 2023.8.1 12:02:15 Establish an association with object A 2023.8.1 12:02:45 Send content A to object A 2023.8.1 12:03:36 Establish an association with object B 2023.8.1 12:04:52 Send content B to object B 2023.8.1 12:06:15 Receive resources from object B 2023.8.1 12:08:47 Create a conversation group A …… …… 2023.8.10 08:22:15 Send link A in conversation group A

[0116] Table 1

[0117] Table 1 records all operation events that occurred in the target object in the application from 12:01:20 on August 1, 2023 to 08:22:15 on August 10, 2023. By analyzing the user actions in the historical operation log, it can be determined whether the target object will bring risks to the application. For example, the content A sent by the target object to object A, the content B sent to object B, and the link A sent in the conversation group A in Table 1 are all bad content after analysis, and the resources from object B are illegally obtained. Therefore, the behavior of the target object will affect the information and resource security of other objects. Therefore, it is necessary to define the risk level of the target object as high risk. The first operation feature can be obtained from the historical operation log by extracting the key information in the operation event as the first operation feature. For example, through Table 1, the first operation features that can be extracted are: "Content A", "Content B", "Receiving Resources" and "Link A".

[0118] Since the amount of data recorded in the historical operation log is relatively large, the records within a predetermined time period can be obtained from the historical operation log as the first operation feature. The predetermined time period can be one day, one week, half a month, or one month, etc. Since the activities of the object in the application may change, for example, the object uses the application normally when the account is first created, without any bad operations, but recently began to spread a large amount of bad content to other objects. If the target object's current risk level is determined using the target object's operation information from the time the target object's account is first created to the current time, the result obtained may be inaccurate. Therefore, the operation information within the predetermined time period before the current time point can be obtained, so that the obtained operation information can accurately reflect the target object's recent activities, thereby improving the accuracy of determining the target object's risk level.

[0119] The time period for obtaining the first operation feature can be dynamically determined by the usage time of the target object. If the usage time is long, it means that the target object has more operation information in the application, so the operation information in a shorter time period can be used to obtain a more accurate risk level assessment result; but if the usage time is short, the operation information in a longer time period is required to obtain a comprehensive and accurate assessment result. For example, if the target object uses the application for 8 hours a day, the operation information of the target object in the application within a week can be obtained to determine the risk level of the target object; if the target object only uses the application for 1 hour a day, the operation information of the target object in the application within a month can be obtained to determine the risk level of the target object. Dynamically determining the time period for obtaining the target object's operation information can obtain more comprehensive operation information based on the characteristics of the target object's use of the application, so as to improve the accuracy of determining the target object's risk level.

[0120] When obtaining the first operation feature of the target object, the target object's consent must also be sought in advance. This will not be repeated here.

[0121] After acquiring the first object feature and the first operation feature of the target object, the risk level of the target object is analyzed according to the first object feature and the first operation feature. In one embodiment, the risk level of the target object is determined according to the first object feature and the first operation feature, and the risk level of the target object is obtained by inputting the first object feature and the first operation feature into a risk level assessment model.

[0122] The risk level assessment model is a model trained based on a large amount of training data for predicting risk levels. After the first object feature and the first operation feature of the target object are input into the risk level assessment model, the risk level can be directly obtained. The use of the risk level assessment model can improve the efficiency of determining the risk level.

[0123] The advantage of determining the risk level of the target object based on the first object feature and the first operation feature is that the risk level is determined for multiple aspects of the target object, thereby improving the comprehensiveness and accuracy of determining the risk level.

[0124] The first object feature and the first operation feature are obtained based on the account currently logged into the application. However, when an object is engaged in harmful activities, it may create multiple accounts in order to avoid security audits. In related technologies, in order to prevent an object from creating multiple accounts, it is generally limited that each object's identity information can only create one account. However, high-risk objects may also obtain the identity information of other objects through illegal means and create multiple accounts to avoid audits. Therefore, in one embodiment, after obtaining the first object feature and the first operation feature of the target object corresponding to the object identifier, it also includes:

[0125] Get the associated object of the target object;

[0126] Acquire a second object feature and a second operation feature of the associated object;

[0127] Determining a risk level of the target object according to the first object feature and the first operation feature includes:

[0128] A risk level of the target object is determined according to the first object feature, the first operation feature, the second object feature, and the second operation feature.

[0129] The associated objects are other objects that are related to the target object. In one embodiment, obtaining the associated objects of the target object includes:

[0130] Get the target client that issued the login request;

[0131] Gets the associated objects other than the target object that have been logged in on the target client.

[0132] When an object uses multiple identity information to register multiple accounts to log in to an application, it may also switch between multiple accounts on a terminal. Therefore, there may be associations between accounts that have logged in on the same client. In step 310, the login request includes a client version identifier, and the target client that issued the login request can be determined by the client version identifier. The associated objects of the target object are determined by querying the objects that have logged in on the target client in the historical login records.

[0133] However, the target client may be a client temporarily used by the object. For example, the terminal 110 where the target client is located is a public device that can be used by anyone. In this case, there are many objects that have logged in on the target client, and most of them have no relationship with the target object. Therefore, although these objects use the same client as the target object, they cannot participate in the risk level assessment of the target object as associated objects. Therefore, in one embodiment, after obtaining the target client that issued the login request, it also includes:

[0134] Determine the number of times the target object has logged in on the target client;

[0135] If the number of logins is greater than a predetermined threshold, the associated objects other than the target object that have been logged in on the target client are obtained.

[0136] In this embodiment, the frequency of the target object using the target client is determined by determining the number of times the target object logs in on the target client. If the target client is a common client of the target object, then other accounts logged in on the target client are likely to be used by the target object. Therefore, a predetermined threshold is set to determine whether the target client is a common client of the target object.

[0137] The advantage of further screening associated objects based on the number of logins is that it avoids the impact of other irrelevant objects on the client temporarily used by the target object on the risk level assessment of the target object, thereby improving the accuracy of determining the risk level.

[0138] The advantage of using an object that has logged in on the same client as the target object as an associated object is that the accuracy of the acquired associated objects is improved.

[0139] After the associated object is obtained, the second object feature and the second operation feature of the associated object are obtained. The process of obtaining the second object feature and the second operation feature is similar to the process of obtaining the first object feature and the first operation feature in the above description, and will not be repeated here.

[0140] The risk level of the target object is determined by using the first object feature of the target object, the first operation feature, the second object feature of the associated object, and the second operation feature. In the aforementioned embodiment, the first object feature and the first operation feature of the target object are input into the risk level assessment model to directly obtain the risk level of the target object. Similarly, the first object feature, the first operation feature, the second object feature, and the second operation feature can be input into the risk level assessment model together to obtain the risk level of the target object.

[0141] In another embodiment, the result obtained by the risk level assessment model is the probability corresponding to each risk level label, for example: {high risk: 0.6, medium risk: 0.2: low risk: 0.1, no risk, 0.1}. Therefore, determining the risk level of the target object according to the first object feature, the first operation feature, the second object feature and the second operation feature includes:

[0142] Inputting a first object feature and a first operation feature of the target object into a risk level assessment model to obtain a first probability;

[0143] Inputting the second object feature and the second operation feature of the associated object into the risk level assessment model to obtain a second probability;

[0144] A risk level of the target object is determined based on the first probability and the second probability.

[0145] In this embodiment, risk level assessment is performed for different objects. For example, the first probability of the target object is {high risk: 0.4, medium risk: 0.3: low risk: 0.2, no risk, 0.1}, the second probability of the associated object A is {high risk: 0.6, medium risk: 0.2: low risk: 0.1, no risk, 0.1}, and the second probability of the associated object B is: {high risk: 0.3, medium risk: 0.4: low risk: 0.2, no risk, 0.1}. The risk level of the target object is determined according to the probabilities corresponding to the three objects.

[0146] In one embodiment, the risk level of the target object can be determined based on the first probability and the second probability by calculating the average value of the probabilities corresponding to each risk level label, and taking the risk level label with the largest corresponding average value as the risk level of the target object. Based on the above example, the average value of the probabilities corresponding to each risk level label is calculated as {high risk: 0.43, medium risk: 0.3: low risk: 0.17, no risk, 0.1}, so the risk level of the target object is high risk. The advantage of determining the risk level of the target object by the probability average value is that the impact of each object on the risk level assessment is the same, which improves the fairness and comprehensiveness of determining the risk level.

[0147] In another embodiment, the risk level of the target object can be determined based on the first probability and the second probability, and a weight can be set for each object, and the weighted average of the probabilities corresponding to each risk level label is calculated, and the risk level label with the largest corresponding weighted average is used as the risk level of the target object. Based on the above example, the weight corresponding to the target object is 0.5, the weight corresponding to the associated object A is 0.3, and the weight corresponding to the associated object B is 0.2. Then the weighted average of the probabilities corresponding to each risk level label is calculated as {high risk: 0.44, medium risk: 0.29: low risk: 0.17, no risk, 0.1}, so the risk level of the target object is high risk. The weight can be set for each object based on the degree of association with the target object. For example, if the login time of the associated object A is close to the login time of the target object, then the behavior of the associated object A after logging into the application may be associated with the behavior of the target object after logging in, and the weight of the associated object A is higher than that of other associated objects. The advantage of determining the risk level of the target object by weighted average is that the accuracy of determining the risk level of the target object is improved.

[0148] The advantage of determining the risk level of a target object based on the characteristics of the target object and associated objects is that it avoids the problem of risk dispersion caused by the target object logging in through multiple accounts, thereby improving the accuracy of determining the target risk level.

[0149] In the aforementioned embodiment, after obtaining the object identifier, the object feature is determined according to the object identifier, and the risk level is determined based on the object feature. In another embodiment, identifying the risk level of the target object corresponding to the object identifier includes:

[0150] Get the risk level mapping relationship table;

[0151] Based on the object identifier, the risk level of the target object is determined in the risk level mapping relationship table.

[0152] In this embodiment, the risk level mapping relationship table is generated in advance, and the risk level of the target object can be directly obtained through the object identifier. For example, Table 2 is an example of a risk level mapping relationship table.

[0153] Object Identification Risk Level 0001 No risk 0002 No risk 0003 Medium risk 0004 High risk 0005 Low risk

[0154] Table 2

[0155] Referring to Table 2, if the object identification is "0004", the risk level of the target object is "high risk".

[0156] In one embodiment, the risk level mapping relationship table is generated in the following manner:

[0157] Identify multiple risk levels;

[0158] Obtain a third object feature and a third operation feature of each object in the application;

[0159] The risk level corresponding to each object is determined according to the third object feature and the third operation feature, and a corresponding relationship between the object identifier and the risk level is generated.

[0160] The process of determining the correspondence between the object identifier and the risk level in this embodiment is the same as the process of determining the risk level of the target object according to the first object feature and the first operation feature of the target object in the aforementioned embodiment, and will not be repeated here.

[0161] Since the risk level of an object may change, the risk level mapping relationship table may be updated according to a predetermined period, for example, the above process may be performed once a week to update the risk level corresponding to each object.

[0162] Since the risk level corresponding to the object identifier is determined in advance, the process of identifying the risk level of the target object corresponding to the object identifier in step 320 is as follows: Figure 4 As shown. The risk level assessment module 124 will determine in advance which risk levels the object is classified into; obtain the third object feature and the third operation feature of each object; determine the risk level of each object, generate a corresponding relationship between the object identifier and the risk level; and finally generate a risk level mapping relationship table. When identifying the risk level of the target object corresponding to the object identifier, directly call the risk level corresponding to the object identifier in the risk level mapping relationship table. Therefore, the embodiment of determining the risk level through the risk level mapping relationship table can improve the efficiency of identifying the risk level, thereby improving the login efficiency of the target object.

[0163] Step 330: Search for first version information of the target client based on the first client version identifier.

[0164] The target client is a client that sends a login request and corresponds to the target application. The first version information is the version information of the target client. Since different client versions have different risk management capabilities, the first version information indicates that the target client has a first risk management capability.

[0165] The client version information is generated after the client version is issued and stored in the version management module 122. The version management module 122 can store the version data of one application or multiple applications; for one application, it can store the version data of one platform or multiple platforms. Figure 5 As shown, the version management module 122 stores the version databases of application A to application N, the version database of application A stores the version databases of platform A to platform C, and the version database of platform A contains the version number of each update iteration after the client generates it.

[0166] In one embodiment, the version management module 122 only stores the version information of each client, and the first version information cannot be directly found through the version management module 122. Therefore, before finding the first version information of the target client based on the first client version identifier, it also includes:

[0167] Get multiple version information of multiple applications;

[0168] Normalizing multiple version information of multiple applications to obtain a first mapping relationship table;

[0169] Searching for first version information of a target client based on the first client version identifier includes:

[0170] The first version information of the target client is searched in the first mapping table based on the first client version identifier.

[0171] In this embodiment, before searching for the first version information of the target client, a first mapping relationship table needs to be generated, and the first mapping relationship table stores the mapping relationship between the client version identifier of each application and the client version information. To generate the first mapping relationship table, it is first necessary to obtain multiple version information of multiple applications from the version management module 122. For example, based on Figure 5 The version management module obtains multiple version information including: (application A, platform A, 1.0.0), (application A, platform A, 1.0.1), ..., (application N, platform C, 15.2.06). It should be made clear that Figure 5 is a schematic diagram of the storage method of the version management module 122, so through Figure 5 The application information, platform information and version information corresponding to each client version can be clearly read. However, in fact, the storage format of the client version information corresponding to different applications in the version management module 122 may be different. For example, each time a new version of application A's client is issued, the version information is stored in the format of a hash table; each time a new version of application B's client is issued, the version information is stored in the format of a string. Therefore, in order to facilitate unified management, it is necessary to normalize multiple version information according to a predetermined format, so as to assign a unique client version identifier to each version information. Generate a first mapping relationship table corresponding to the client version identifier and the version information.

[0172] In one embodiment, multiple version information of multiple applications is normalized to obtain a first mapping relationship table, including:

[0173] Generate a first field based on application information of each application, generate a second field based on platform information of different platforms, and generate a third field based on different version information of each application;

[0174] The field combination corresponding to the different version information of each application on different platforms is determined to obtain a first mapping relationship table, where the field combination is a combination of the first field, the second field and the third field.

[0175] In this embodiment, the application information, platform information and version information of the client version are stored in sequence according to three fields. For example, a version information obtained is {application: application A, platform: platform B, version: 2.0.3}, therefore, the first field corresponding to the version information is "application A", the second field is "platform B", and the third field is "2.0.3". Another version information is "application B / platform A / 10.01.02", and the version information is stored in the order of application, platform and version. Therefore, the first field corresponding to the version information is "application B", the second field is "platform A", and the third field is "10.01.02". After obtaining the combination of the first field, the second field and the third field corresponding to each version information, a first mapping relationship table is formed with the client version identifier assigned to the version information. Table 3 is an example of a first mapping relationship table.

[0176] Client version identifier First Field (Application) Second field (platform) The third field (version) 00001a Application A Platform A 1.0.0 00001b Application A Platform A 1.0.1 …… …… …… …… 03671d Application N Platform C 12.5.3 03671d Application N Platform C 12.6.0

[0177] Table 3

[0178] Referring to Table 3, if the first client version identifier is 00001b, then the first version information of the target client is (application A, platform A, 1.0.1).

[0179] Through the above process, two version information with different storage formats are standardized, thereby improving the efficiency of searching for client version information based on the client version identifier.

[0180] Since each application will frequently issue a new version of the client, the first mapping relationship table should also be updated with the new version. In one embodiment, after normalizing multiple version information of multiple applications to obtain the first mapping relationship table, the following is also included:

[0181] Get the preset mapping relationship table update frequency;

[0182] Based on the updating frequency of the mapping relationship table, multiple new version information of multiple applications are reacquired, and based on the multiple new version information of the multiple applications, the first mapping relationship table is updated.

[0183] In this embodiment, the first mapping relationship table is updated according to a preset mapping relationship table update frequency. The mapping relationship table update frequency may be one day, one week, half a month, or one month, etc. In one implementation, the mapping relationship table update frequency may be set in the following manner:

[0184] Obtaining multiple version update time intervals of the client of each application in the version management module 122;

[0185] The mapping table update frequency is determined based on multiple version update time intervals corresponding to the multiple applications.

[0186] Whenever the version information of a new version of the client is stored in the version management module 122, the new version promulgation time is recorded. Therefore, the version update time interval can be determined by the version promulgation time of two adjacent versions. For example, the promulgation times of 4 client versions of the same application and platform are: January 7, 2023, March 15, 2023, July 20, 2023, and September 1, 2023. Based on this, 3 version update time intervals are generated, which are 67 days, 127 days, and 43 days respectively. The mapping table update frequency can be determined based on the 3 version update time intervals by calculating the average. In the above example, the mapping table update frequency is (67+127+43) / 3=79 days.

[0187] The advantage of determining the mapping table update frequency based on multiple version update time intervals of multiple applications is that the mapping table update frequency can be determined based on the version update frequency, thereby improving the accuracy of the preset mapping relationship table update frequency.

[0188] After the mapping table update frequency is preset, whenever the time reaches the mapping table update frequency, the new version information of multiple applications in the previous update cycle is obtained, and a unique client version identifier is assigned to each new version information, a mapping relationship between the client version identifier and the version information is generated, and the first mapping table is updated.

[0189] The specific process of updating the first mapping relationship table according to the mapping relationship table update frequency and searching the first version information of the target client based on the first mapping relationship table is as follows: Figure 6 As shown, the version information in the version management module 122 is normalized according to the mapping relationship update frequency to update the first mapping relationship table. The first version information is searched according to the periodically updated first mapping relationship table. Therefore, the advantage of the whole process is that the synchronization of the first mapping relationship table is improved, ensuring that the first mapping relationship table can obtain the latest version information in time, thereby improving the accuracy of searching the first version information of the target client based on the first mapping relationship table.

[0190] After generating the first mapping relationship table, the first version information corresponding to the target client can be quickly found based on the first client version identifier. The first version information can include the target application information that the target client wants to log in, the target platform information where the target client is located, and the version information of the target client, thereby improving the efficiency and comprehensiveness of finding the first version information.

[0191] The first version information can indicate that the target client has the first risk control capability. Since the risk control capability of the client can be improved as the client version is upgraded, the higher the version number in the version information of the same application, the stronger the risk control capability. When comparing the version numbers of two clients, first compare the main version number; if the main version numbers are the same, compare the sub-version numbers; if the sub-version numbers are also the same, compare the stage version numbers. For example, the risk control capability of a client with version number 15.2.3 is weaker than that of a client with version number 15.4.2.

[0192] Step 340: Determine the second version information corresponding to the risk level.

[0193] The second version information indicates a second risk control capability, which is the minimum risk control capability required for a client to allow an object corresponding to the risk level to log in to the target application.

[0194] In the related art, in order to prevent objects from using low-version clients to evade network security audits, all objects are often required to update their clients to the latest version to ensure that the clients used by each object have the strongest risk management capabilities. However, this will cause inconvenience in use for non-risk objects. Therefore, the disclosed embodiments set different minimum risk management capabilities for objects of different risk levels, as long as the clients used by objects of the risk level have the minimum risk management capabilities. In this way, high-risk objects can be prevented from using low-version clients to evade security audits, and the normal login of low-risk objects to the application will not be affected. Generally speaking, the higher the risk level of the object, the stronger the minimum risk management capability that the corresponding client must have. For example Figure 7 As shown in the figure, the minimum risk control capability required for the client of the object application without risk is level 1, and the minimum risk control capability required for the client of the object application with high risk is the highest level 4. Objects limited to the risk control capability cannot log in on the client with low risk control capability. Figure 7 In the middle, risk-free objects can log in on clients of all four risk control capability levels, low-risk objects can only log in on clients with risk control capabilities of level 2, level 3, or level 4, medium-risk objects can only log in on clients with risk control capabilities of level 3 or level 4, and high-risk objects can only log in on clients with risk control capabilities of level 4. Different version information indicates different risk control capabilities of the corresponding application. Therefore, determining the second version information of the client used to log in to the target application based on the risk level of the target object is to determine the minimum risk control capability that the client of the target object application needs to have.

[0195] In one embodiment, determining the second version information corresponding to the risk level includes:

[0196] Obtaining a second mapping relationship table;

[0197] The second version information corresponding to the target application is searched in the second mapping relationship table based on the risk level.

[0198] In this embodiment, the second mapping relationship table stores the mapping relationship between different risk levels and baseline versions of different applications, and the baseline version is the client version with the lowest risk management capability that can be used by objects of the corresponding risk level. The baseline version corresponding to the target application found in the second mapping relationship table based on the risk level is the second version information corresponding to the risk level. For example, Table 4 is an example of a second mapping relationship table.

[0199] application Risk Level Baseline version Application A High risk 10.2.1 Application A Medium risk 10.1.5 Application A Low risk 10.1.1 Application A No risk 9.3.2 …… …… …… Application N No risk 6.4.2

[0200] Table 4

[0201] Based on the second mapping relationship table in Table 4, if a high-risk object logs in to application A, the baseline version of the client used is 10.2.1. Figure 7 , the risk control capability of version 10.2.1 is level 4. If a risk-free object logs in to application A, the extreme version of the client used is 9.3.2, and its risk control capability is level 1.

[0202] Since the application has different clients on different login platforms, the second mapping relationship table may also store mapping relationships between different risk levels and client baseline versions of different applications on different platforms, such as the second mapping relationship table shown in Table 5.

[0203] application platform Risk Level Baseline version Application A Platform A High risk 10.2.1 Application A Platform A Medium risk 10.1.5 Application A Platform A Low risk 10.1.1 Application A Platform A No risk 9.3.2 Application A Platform B High risk 3.5.3 Application A Platform B Medium risk 3.4.1 …… …… …… …… Application N Platform C No risk 6.4.2

[0204] Table 5

[0205] Referring to the second mapping relationship table in Table 5, if a high-risk subject wants to log in to application A through the client on platform A, the minimum client version allowed is 10.2.1, and its risk management capability is level 4; if a high-risk subject wants to log in to application A through the client on platform B, the minimum client version allowed is 3.5.3, and its risk management capability is also level 4.

[0206] The minimum client version for logging into applications at different risk levels may be determined by the operation management personnel. In one embodiment, obtaining the second mapping relationship table includes:

[0207] Receive the baseline version editing instructions input by the operation management personnel;

[0208] A second mapping relationship table is generated based on the baseline version editing instruction.

[0209] In this embodiment, the baseline version editing instruction input by the operator may include the application, platform, risk level and the corresponding version baseline, for example, application N-platform A-high risk-5.6.1, which means that the minimum version of the client used by the high-risk object to log in to application N on platform A is 5.6.1, and its risk management capability is level 4. The mapping relationship between application, platform, risk level and baseline version in the second mapping relationship table is generated according to the baseline version editing instruction.

[0210] The operation and management personnel can manage the mapping relationships in the second mapping relationship table through the management terminal. Figure 8a As shown, in the operation management terminal, the operation management personnel can edit the mapping relationship between applications, platforms, risk levels and baseline versions. The current high-risk object wants to use the client baseline version 9.3.1 to log in to application A through platform A, which has level 4 risk control capabilities. If application A issues a new version 10.1.1 on the client of platform A, this version has level 4 risk control capabilities, while version 9.3.1 only has level 3 risk control capabilities, so the operation management personnel need to make adjustments to each baseline version. After the operation management personnel triggers the "Edit" operation corresponding to the "Application A-Platform A-High Risk" field, the operation management terminal displays the following. Figure 8b As shown, the operations manager needs to input the baseline version number corresponding to "Application A-Platform A-High Risk", and the operations manager inputs the version number 10.1.1 with level 4 risk management capabilities. It should be noted that there are many ways for the operations manager to input the baseline version, and one of the version numbers can be selected. At this time, the extreme version editing instruction received from the operations manager is "Application A-Platform A-High Risk-10.1.1", so the baseline versions corresponding to Application A, Platform A and High Risk in the second mapping relationship table are changed to 10.1.1. Similarly, the baseline versions corresponding to other risk levels of Application A and Platform A are adjusted according to the current risk management capabilities. After all adjustments are completed, the operations management terminal displays the following. Figure 8c As shown, at this time, the minimum client version used by the medium-risk object to log in to application A through platform A is 9.3.1.

[0211] The advantage of this embodiment of generating a second mapping relationship table by receiving baseline version editing instructions input by operation management personnel is that manual judgment can improve the reliability of determining the baseline version, and can also fine-tune the baseline version according to the needs of actual applications, thereby improving the flexibility of determining the baseline version and the safety operation efficiency.

[0212] After the second mapping relationship table is obtained, the second version information corresponding to the target application is searched in the second mapping relationship table based on the risk level.

[0213] In the above-mentioned embodiment, the second mapping relationship table includes the mapping relationship between the application, platform, risk level and baseline version. Therefore, searching the second version information corresponding to the target application in the second mapping relationship table based on the risk level includes:

[0214] Determine the target application and target platform;

[0215] Based on the combination of the target application, the target platform and the risk level, the corresponding baseline version is determined in the second mapping relationship table, and the baseline version is used as the second version information.

[0216] In this embodiment, the target application is the application corresponding to the target client, and the target platform is the platform where the target client is located. In the above embodiment of searching for the first version information of the target client based on the first client version identifier, the first version information includes the target application information and the target platform information, so the target application and the target platform can be determined through the first version information.

[0217] Combine the target application, target platform and risk level, and search for the corresponding baseline version in the second mapping table, for example, referring to Figure 8c , the combination is application A-platform A-low risk, then the baseline version is 9.1.1, that is, the second version information determined based on the risk level is the baseline version 9.1.1.

[0218] The specific process of searching the second version information based on the second mapping relationship table is as follows: Fig. 9 As shown, a second mapping relationship table is generated based on the baseline version editing instruction input by the operation management terminal. When determining the second version information corresponding to the risk level, the second version information is determined based on the mapping relationship between the risk level and the client baseline version of the target application. It can be seen that the second version information can be directly determined based on the second mapping relationship table, which improves the efficiency of finding the second version information.

[0219] Step 350: When the first risk control capability is lower than the second risk control capability, prohibit the target object from logging into the target application based on the login request.

[0220] The first risk control capability is the risk control capability possessed by the target client currently used by the target object to log in to the target application, and the second risk control capability is the minimum risk control capability that the client used by the target object to log in to the target application needs to have. Since the higher the version number of the client, the stronger its risk control capability, therefore, if you want to compare the level of risk control capabilities, you can compare the size of the version numbers. For example, the version number in the first version information is 6.3.2, and the version number in the second version information is 6.4.1. Since the main version number of the first version information is the same as the main version number of the second version information (6), and the sub-version number (3) of the first version information is less than the sub-version number (4) of the second version information, the version number of the first version information is less than the version number of the second version information. Therefore, the first risk control capability corresponding to the first version information is lower than the second risk control capability corresponding to the second version information.

[0221] If the first risk control capability is lower than the second risk control capability, it means that the risk control capability of the target client cannot bear the risk level of the target object, and therefore, the target object is prohibited from logging into the target application based on the login request. If the target object wants to log into the target application, the version of the target client needs to be upgraded to at least the version in the second version information. Therefore, in one embodiment, after determining the second version information corresponding to the risk level, it also includes:

[0222] When the first risk control capability is lower than the second risk control capability, a login prohibition prompt is sent to the target client, and a version update prompt is sent to the target client.

[0223] In this embodiment, while prohibiting the target object from logging into the target application based on the login request, it is also necessary to send a version update prompt to the target object. The version update prompt may include second version information so that the target object knows which version the target client needs to be upgraded to in order to log in to the target application.

[0224] This embodiment effectively transmits the client version update prompt to the target object, so that the target object can update the target client in time, thereby improving the information transmission efficiency in the login management process.

[0225] If the first risk control capability is higher than or equal to the second risk control capability, it means that the target client meets the login requirements of the target object, and the login module 121 logs in to the target application based on the login request. However, in order to avoid security audits, high-risk accounts use illegal operations to obtain access tickets after logging in to the target application using high-risk control capabilities, and use the access tickets on clients with low-risk control capabilities to perform harmful operations. In order to solve this problem, in one embodiment, after determining the second version information corresponding to the risk level, it also includes:

[0226] When the first risk control capability is not lower than the second risk control capability, issuing an access ticket to the target client, where the access ticket carries a version identifier of the first client;

[0227] receiving a data access request carrying an access ticket, and performing a security check on the data access request based on the first client version identifier;

[0228] When the security check result of a data access request is unqualified, the sender of the data access request is prohibited from accessing the business data.

[0229] In this embodiment, when logging into the target application based on a login request, an access ticket is issued to the target client, and the access ticket contains the first client version identifier of the target client. Every time a data access request is received, a security check is performed based on the data access request and the first client version identifier in the access ticket to ensure data access security. The system architecture for business data access in this embodiment can be as follows Fig.10 As shown, terminal 110 is a device that initiates a data access request. After receiving the data access request, security detection module 1010 performs a security detection based on the first client version identifier. If the detection passes, data access is performed in data access module 1020 based on the data access request.

[0230] In one embodiment, receiving a data access request carrying an access ticket and performing security detection on the data access request includes:

[0231] When receiving a data access request carrying an access ticket, obtaining a second client version identifier of the sender of the data access request;

[0232] When it is detected that the first client version identifier matches the second client version identifier, determining that the security detection result of the data access request is qualified;

[0233] When it is detected that the first client version identifier does not match the second client version identifier, it is determined that the security detection result of the data access request is unqualified.

[0234] In this embodiment, when performing security detection, the security detection module 1010 obtains the second client version identifier sent by the data access request. The second client version identifier is compared with the first client version identifier stored in the access ticket. If the second client version identifier is consistent with the first client version identifier, it means that the target object still uses the client at the time of login to access data, its risk management and control capabilities meet the requirements, and the security detection result is qualified; if the second client version identifier is inconsistent with the first client version identifier, it means that the target object illegally obtains the access ticket and logs in to other clients, and the security detection fails at this time.

[0235] This embodiment performs security detection by comparing the first client version identifier with the second client version identifier, which intuitively reflects whether the client used by the target object has changed. The detection efficiency and accuracy are high.

[0236] After the security check, if the test result is qualified, the data access request is sent to the data access module 1020 for normal data access; but if the test result is unqualified, the sender of the data access request is prohibited from accessing the data, and the status of the access ticket is changed to invalid, forcing the target object to exit the target application.

[0237] This embodiment uses the first client version identifier in the access ticket to perform security checks to check whether the target object illegally uses the access ticket to log in to other clients with low risk management capabilities. If the security check fails, the target application is not allowed to access the data, further improving the data security of the application.

[0238] The embodiments of the present disclosure are described in detail in combination with specific application scenarios.

[0239] like Fig.11 As shown, it is another flowchart of the login management method provided by the present disclosure. In the embodiment of the present disclosure, the login management method provided by the present disclosure is introduced in detail with the server 120 as the execution subject. The method specifically includes the following steps:

[0240] Step 1101: The server 120 receives a login request sent by the terminal 110, and obtains the UID and VID included in the login request.

[0241] The login request is initiated by the client on the terminal 110 and is used to request to log in to the application system corresponding to the client. The login request contains UID and VID. UID refers to the object identifier, and each object has a unique identifier in the server. The object identifier contained in the login request is used to indicate which object initiated the login request. VID refers to the client identifier, and the client identifier can indicate the specific information of the client that initiated the login request, such as the client's computer application product information, login platform information and version information.

[0242] Step 1102: The server 120 obtains object information according to the UID, and determines the risk level of the object according to the object information.

[0243] The object information may include static data of the object in the application, such as basic object information, object device information, and object geographic location information. The basic object information is generally content that can be set by the object itself, such as account nickname and account description. Accounts that implement bad behavior can transmit bad information through these self-set contents. Object device information refers to the device information of the terminal 110 from which the object initiates a login request, such as processor parameters and firewall parameters. The purpose of obtaining the object device information is to assess the object risk by judging the security protection capability of the device used by the object. If the security protection capability of the object device is poor, then the tolerance for malicious behavior may be stronger. Object geographic location information refers to the geographic location where the object initiates the login request. The purpose of obtaining geographic location information is to determine the control capability of the server 120 for the object operation. If there is network security isolation between the geographic location of the object and the geographic location of the server 120, then the server 120 may not be able to completely control the operation of the object in the application, and the object can easily implement malicious operations through system vulnerabilities, so the risk level of such objects is relatively high.

[0244] The object information may also include the operation data of the object in the application. The operation data refers to the events that occur in the application, such as logging into the application, creating a conversation group, and having one-to-one conversations with multiple other objects at the same time. The operation data of the object in the application can be sorted and analyzed to determine whether the operation of the object in the application may cause malicious events that may bring data security risks. As long as the object generates traffic after logging into the application, the corresponding operation data will be generated, so the amount of operation data of the object in the application is very large. Moreover, since the risk level of the object in the application will change, there may be no malicious behavior when the application is first used, but malicious behavior will begin to appear after a period of time. Combining the above two points, obtaining the operation data of the object in the application can obtain the operation data within a predetermined time period before the current time point, so as to obtain an accurate risk level assessment result based on the recent operation behavior of the object.

[0245] Determining the risk level of an object based on its information can use machine learning or deep learning to build a risk assessment model, input the object information into the risk assessment model, and obtain the risk level of the target object. The risk level obtained by the risk assessment model can be divided into levels, such as high-risk objects, low-risk objects, etc.; or it can be divided according to the type of malicious operation of the object through analysis of the object information, such as type A objects, type B objects, and objects without malicious operations.

[0246] Step 1103 : The server 120 determines the product information, platform information, and client version number of the client sending the login request according to the VID.

[0247] Since the server 120 can manage multiple versions of clients on multiple platforms of multiple products, its specific storage format can be nested layer by layer with products, platforms, and client versions. For example, the server stores version databases of products A, B, and C. The version database of product A contains version databases of platforms A, B, and C. The version database of platform A contains multiple client versions. Therefore, if you want to find the client that sent the login request from a large amount of information, you need to search one by one in a depth-first traversal manner. Such a search algorithm has a high time complexity and low search efficiency.

[0248] To address this problem, this method can normalize the management of multiple versions of client information on multiple platforms of multiple products, store the client information according to the combination of (product, platform, version), and assign a unique VID to each combination, so that the client information can be directly found through the VID. Since the client version of each application may be updated and iterated at any time, the server 120 sets a timer task to obtain the version information of each product at a regular time, and establishes a mapping relationship between the VID and the version information through normalization and data standardization. The mapping relationship between the VID and the version information is stored in the version online query database. After receiving the login request, the client's product information, platform information and client version number can be obtained by directly querying the version online query database through the VID.

[0249] Step 1104 , the server 120 queries the baseline version number corresponding to the product information and the platform information according to the risk level of the object.

[0250] The baseline version number can be the minimum version number of the client used by the object to log in to the application. The object must use a client with a version number not lower than the baseline version number to log in to the application. Objects with higher risk levels require clients with stronger risk management capabilities to manage the behavior of the object. Since the higher the client version number, the stronger the risk management capability, the higher the risk level of the object, the higher the baseline version number. The baseline version number corresponding to the product information and platform information can be queried through the hierarchical version baseline library according to the risk level of the object. The hierarchical version baseline library stores the mapping relationship between the risk level, the combination of product and platform, and the baseline version number. For example, the hierarchical version baseline library stores (high risk, application A, platform A, 10.2.3), which means that if a high-risk object wants to log in to application A through platform A, the minimum version number of the client used is 10.2.3.

[0251] The hierarchical version baseline library can be obtained by configuring the baseline version numbers of objects of different risk levels in different applications and different platforms by the operation and management personnel. The server 120 can add new baseline version rules, delete existing baseline version rules, or change baseline version rules in the hierarchical version baseline library by receiving the baseline version number editing instructions from the operation and management personnel at the security version operation and management end.

[0252] The server 120 can directly search for the corresponding baseline version number in the graded version baseline library according to the risk level of the object, the combination of product information and platform information.

[0253] Step 1105: When the version corresponding to the client version number is a lower version than the version corresponding to the baseline version number, the server 120 sends a login prohibition instruction to the terminal.

[0254] If the client version number is less than the baseline version number, it means that the client that the object currently sends the login request does not meet the conditions for the object to log in to the application, and the object needs to be prohibited from logging in to the application through the client. At the same time, the server 120 also needs to send a login prohibition prompt and a version update prompt to the terminal 110 to inform the object why the login is prohibited and the minimum client version required to log in to the application.

[0255] Step 1106 , when the version corresponding to the client version number is a higher version than the version corresponding to the baseline version number, or is the same as the version corresponding to the baseline version number, the server 120 issues an access ticket to the terminal 110 .

[0256] If the client version number is greater than or equal to the level baseline version number, it indicates that the client that currently issues the login request to the object can allow the object to log in. Therefore, the server 120 can issue an access ticket to the terminal 110 so that the object can access the data in the application within a specified time without initiating a login request again.

[0257] However, after logging into the application through a client with high risk control capabilities, some objects, in order to evade security audits, perform malicious operations, illegally obtain access tickets, and apply the access tickets to low-version clients with low risk control capabilities. In this way, after logging into the application with a high-version client, they use a low-version client to access data, thereby evading security audits.

[0258] To address the above problem, when issuing an access ticket to the terminal 110 , the method stores the VID of the client that logs into the application in the access ticket so as to verify the data access request.

[0259] Step 1107: When receiving a data access request carrying an access ticket, the server 120 obtains the VID of the sender of the data access request.

[0260] The data access request sent by the terminal 110 will carry an access ticket. When the server 120 receives the data access request, it obtains the VID of the sender of the access request and extracts the VID in the access ticket. The VID in the access ticket is compared with the VID of the sender of the access request. Since the VID corresponds to the unique client version information, two identical VIDs can prove that they are the same client.

[0261] Step 1108: When the VID of the sender of the data access request is the same as the VID in the access ticket, the server 120 allows the sender of the data access request to access the target data.

[0262] When the VID of the sender of the data access request is the same as the VID in the access ticket, it means that the client sending the data access request is the same as the client logging into the application. Therefore, the client sending the access request is a client that meets the risk management capabilities corresponding to the object risk level and can normally access the target data corresponding to the data access request.

[0263] Step 1109 , when the VID of the sender of the data access request is different from the VID in the access ticket, the server 120 prohibits the sender of the data access request from accessing the target data.

[0264] When the VID of the sender of the data access request is different from the VID in the access ticket, it means that the access ticket is used by another client. Therefore, it is necessary to prohibit the sender of the data access request from accessing the target data and force the application to log out, and the access ticket will become invalid. The object can only re-initiate a login request to access the application data.

[0265] It should be noted that steps 1107 to 1109 may be executed for each data access request to improve the security of each data access.

[0266] Refer to the following Fig.12 , and the implementation details of the login management method of the embodiment of the present disclosure are exemplarily explained in combination with the system architecture.

[0267] Step 1201 : Send a login request, which includes an object identifier and a first client version identifier, wherein the object identifier is used to find data of the target object in the application, and the first client version identifier is used to find the first client version information that initiates the login request on the terminal 110 .

[0268] Step 1202, the login module 121 executes the login verification logic, including the account password verification logic, the login environment security verification logic, etc.

[0269] Step 1203: Obtain the object identifier and the first client version identifier included in the login request.

[0270] Step 1204: the version management module 122 generates a first mapping table regularly according to a preset mapping table update frequency. The specific process of generating the first mapping table includes: obtaining multiple version information of multiple applications; normalizing the multiple version information of multiple applications to obtain the first mapping table.

[0271] Step 1205, the risk management capability verification module 123 searches for the first version information of the target client in the first mapping relationship table generated in step 1114 based on the first client version identifier, and the first version information indicates that the target client has the first risk management capability. For example, the target client version in the first version information is 5.3.2.

[0272] Step 1206: Identify the risk level of the target object corresponding to the object identifier. The higher the risk level, the greater the risk that the operation of the object in the application will bring to the data security threat of the application.

[0273] Step 1207, the risk level assessment module 124 obtains the first object feature and the first operation feature of the target object corresponding to the object identifier. The first object feature may include static data features during the target object's use of the application, device information of the terminal 110 used by the target object to log in to the application, and the geographical area feature where the target object is located when initiating a login request. The first operation feature is obtained through an event that occurs in the application for the target object. The first operation feature of the target object corresponding to the object identifier may be obtained by obtaining a historical operation log of the target object, and obtaining the first operation feature of the target object from the historical operation log.

[0274] Step 1208: Determine the risk level of the target object according to the first object feature and the first operation feature. The first object feature and the first operation feature may be input into a risk level assessment model to obtain the risk level of the target object. For example, the risk level of the target object is high risk.

[0275] Step 1209: The operation management personnel inputs a baseline version editing instruction in the operation management terminal.

[0276] Step 1210: Generate a second mapping relationship table based on the baseline version editing instruction. The second mapping relationship table stores the mapping relationship between different risk levels and baseline versions of different applications. The baseline version is the client version with the lowest risk management capability that can be used by objects of the corresponding risk level.

[0277] Step 1211: Determine the second version information corresponding to the risk level in the second mapping relationship table based on the risk level. For example, the second version information corresponding to the high-risk object is 5.4.1.

[0278] Step 1212: Compare the first risk control capability corresponding to the first version information with the second risk control capability corresponding to the second version information. Since the larger the version number, the higher the corresponding risk control capability, by comparing the version numbers in the first version information and the second version information, the first risk control capability and the second risk control capability can be compared.

[0279] Step 1213: determine whether the first risk control capability is lower than the second risk control capability, that is, whether the version number of the first version information is smaller than the version number of the second version information; if so, execute step 1214; if not, execute step 1215.

[0280] Step 1214: The terminal 110 prohibits the target object from logging into the target application based on the login request and displays a version update prompt.

[0281] Step 1215: The login module 121 passes the login verification.

[0282] Step 1216: Write the first client version identifier into the access ticket.

[0283] Step 1217 , log in to the target application through the terminal 110 .

[0284] Step 1218: Terminal 110 initiates a data access request;

[0285] Step 1219 , in the security detection module 1010 , detect whether the first client version identifier in the access ticket matches the second client version identifier that initiated the data access request. If yes, execute step 1220 ; if not, execute step 1221 .

[0286] Step 1220: Access application data based on the data access request.

[0287] Step 1221: prohibit the sender of the data access request from accessing business data and log out.

[0288] Through the above steps 1201 to 1221, the disclosed embodiment restricts objects with higher risk levels to log in and access data on clients with stronger risk management capabilities, while allowing objects with lower risk levels to continue using clients with lower risk management capabilities without forced upgrades. Through this process, the disclosed embodiment reduces the number of malicious behaviors that malicious objects use clients with lower risk management capabilities to evade network security audits and threaten application data security. Figure 13a-13b As shown, Fig.13ais the number of malicious behaviors that occurred in each application when the login management method of the embodiment of the present disclosure is not used, wherein the number of malicious behaviors that occurred in application A is 300, and the number of malicious behaviors that occurred in application B is 250; Fig.13b is the number of malicious behaviors that occurred in each application after using the login management method of the embodiment of the present disclosure, wherein the number of malicious behaviors that occurred in application A becomes 125, and the number of malicious behaviors that occurred in application B becomes 85. Figure 13a to Figure 13b It can be clearly seen from the changes in that the login management method of the embodiment of the present disclosure effectively reduces the occurrence of malicious events in various applications and improves data security in the applications.

[0289] Description of the apparatus and device of the present disclosure

[0290] It is to be understood that, although the steps in the above-mentioned flowcharts are sequentially displayed according to the characterization of arrows, these steps are not necessarily executed in sequence according to the order of arrow characterization. Unless there is a clear description in the present embodiment, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a portion of the steps in the above-mentioned flowcharts can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a portion of the steps or stages in other steps.

[0291] It should be noted that in each specific embodiment of the present disclosure, when it comes to the need to perform relevant processing based on data related to the characteristics of the target object such as the target object attribute information or attribute information set, the permission or consent of the target object will be obtained first, and the collection, use and processing of these data will comply with the relevant laws, regulations and standards of the relevant region. In addition, when the embodiment of the present application needs to obtain the attribute information of the target object, the separate permission or separate consent of the target object will be obtained through a pop-up window or jump to a confirmation page. After clearly obtaining the separate permission or separate consent of the target object, the necessary target object-related data used to enable the normal operation of the embodiment of the present application is obtained.

[0292] Fig.14 The structure diagram of the login management device 1400 provided in the embodiment of the present disclosure. The login management device 1400 includes:

[0293] The first acquisition unit 1410 is used to acquire the object identifier and the first client version identifier contained in the login request when receiving the login request;

[0294] An identification unit 1420 is used to identify the risk level of the target object corresponding to the object identifier;

[0295] A searching unit 1430 is configured to search for first version information of a target client based on the first client version identifier, where the target client is a client that issues a login request and corresponds to a target application, and the first version information indicates that the target client has a first risk management capability;

[0296] The determining unit 1440 determines the second version information corresponding to the risk level, where the second version information indicates a second risk control capability, and the second risk control capability is the minimum risk control capability required for a client to allow an object corresponding to the risk level to log in to the target application;

[0297] The login prohibiting unit 1450 is configured to prohibit the target object from logging into the target application based on the login request when the first risk management capability is lower than the second risk management capability.

[0298] Optionally, in some embodiments, the login management device 1400 further includes:

[0299] A ticket issuing unit, configured to issue an access ticket to a target client when the first risk control capability is not lower than the second risk control capability, wherein the access ticket carries a first client version identifier;

[0300] A security detection unit, configured to receive a data access request carrying an access ticket, and perform a security detection on the data access request based on a first client version identifier;

[0301] The access prohibition unit is used to prohibit the sender of the data access request from accessing the business data when the security detection result of the data access request is unqualified.

[0302] Optionally, in some embodiments, the safety detection unit is specifically used to:

[0303] When receiving a data access request carrying an access ticket, obtaining a second client version identifier of the sender of the data access request;

[0304] When it is detected that the first client version identifier matches the second client version identifier, determining that the security detection result of the data access request is qualified;

[0305] When it is detected that the first client version identifier does not match the second client version identifier, it is determined that the security detection result of the data access request is unqualified.

[0306] Optionally, in some embodiments, the login management device 1400 further includes:

[0307] A second acquisition unit, used to acquire multiple version information of multiple applications;

[0308] A normalization unit, used to normalize multiple version information of multiple applications to obtain a first mapping relationship table, wherein the first mapping relationship table stores a client version identifier corresponding to each version information of each application;

[0309] The searching unit 1430 is specifically used for:

[0310] The first version information of the target client is searched in the first mapping table based on the first client version identifier.

[0311] Optionally, in some embodiments, the normalization unit is specifically used for:

[0312] Generate a first field based on application information of each application, generate a second field based on platform information of different platforms, and generate a third field based on different version information of each application;

[0313] The field combination corresponding to the different version information of each application on different platforms is determined to obtain a first mapping relationship table, where the field combination is a combination of the first field, the second field and the third field.

[0314] Optionally, in some embodiments, the login management device 1400 further includes:

[0315] A third acquisition unit, used to acquire a preset mapping relationship table update frequency;

[0316] The updating unit is used to reacquire multiple new version information of multiple applications based on the updating frequency of the mapping relationship table, and update the first mapping relationship table based on the multiple new version information of the multiple applications.

[0317] Optionally, in some embodiments, the determining unit 1440 includes:

[0318] Obtain a second mapping relationship table, the second mapping relationship table storing mapping relationships between different risk levels and baseline versions of different applications, the baseline version being a version with the lowest risk control capability that can be used by objects of corresponding risk levels;

[0319] The second version information corresponding to the target application is searched in the second mapping relationship table based on the risk level.

[0320] Optionally, in some embodiments, the determining unit 1440 includes:

[0321] Receive the baseline version editing instructions input by the operation management personnel;

[0322] A second mapping relationship table is generated based on the baseline version editing instruction.

[0323] Optionally, in some embodiments, the login management device 1400 further includes:

[0324] a prompting unit, configured to send a login prohibition prompt to the target client when the first risk management capability is lower than the second risk management capability, and

[0325] Send version update notifications to target clients.

[0326] Optionally, in some embodiments, the identification unit 1420 includes:

[0327] Acquire a first object feature and a first operation feature of a target object corresponding to the object identifier;

[0328] A risk level of the target object is determined according to the first object feature and the first operation feature.

[0329] Optionally, in some embodiments, the login management device 1400 further includes:

[0330] A fourth acquisition unit, used to acquire an associated object of the target object;

[0331] A fifth acquisition unit, configured to acquire a second object feature and a second operation feature of the associated object;

[0332] The determining unit 1440 is specifically configured to:

[0333] A risk level of the target object is determined according to the first object feature, the first operation feature, the second object feature, and the second operation feature.

[0334] Optionally, in some embodiments, the fourth acquiring unit is specifically configured to:

[0335] Get the target client that issued the login request;

[0336] Gets the associated objects other than the target object that have been logged in on the target client.

[0337] Reference Fig.15 , Fig.15 The structural block diagram of the terminal 110 for implementing the login management method of the embodiment of the present disclosure is as follows: the terminal 110 includes: a radio frequency (RF) circuit 1510, a memory 1515, an input unit 1530, a display unit 1540, a sensor 1550, an audio circuit 1560, a wireless fidelity (WiFi) module 1570, a processor 1580, and a power supply 1590. Those skilled in the art can understand that Fig.15 The structure of the terminal 110 shown does not constitute a limitation on a mobile phone or a computer, and may include more or less components than shown in the figure, or combine certain components, or arrange the components differently.

[0338] The RF circuit 1510 may be used for receiving and sending signals during information transmission or calls. In particular, after receiving the downlink information from the base station, it is sent to the processor 1580 for processing; in addition, the designed uplink data is sent to the base station.

[0339] The memory 1515 may be used to store software programs and modules. The processor 1580 executes various functional applications of the terminal and identifies lane change points by running the software programs and modules stored in the memory 1515 .

[0340] The input unit 1530 may be used to receive input digital or character information and generate key signal input related to the terminal's settings and function control. Specifically, the input unit 1530 may include a touch panel 1531 and other input devices 1532 .

[0341] The display unit 1540 may be used to display input information or provided information and various menus of the terminal. The display unit 1540 may include a display panel 1541 .

[0342] The audio circuit 1560 , the speaker 1561 , and the microphone 1562 may provide an audio interface.

[0343] In this embodiment, the processor 1580 included in the terminal 110 can execute the login management method of the previous embodiment.

[0344] The terminal 110 of the embodiment of the present disclosure includes but is not limited to mobile phones, computers, intelligent voice interaction devices, smart home appliances, vehicle terminals, aircraft, etc. The embodiment of the present invention can be applied to various scenarios, including but not limited to information security, etc.

[0345] Fig.16 A block diagram of the structure of a portion of the server 120 for implementing the login management method of an embodiment of the present disclosure. The server 120 may have relatively large differences due to different configurations or performances, and may include one or more central processing units (CPUs) 1622 (for example, one or more processors) and storage devices 1632, and one or more storage media 1630 (for example, one or more mass storage devices) storing application programs 1642 or data 1644. Among them, the storage device 1632 and the storage medium 1630 can be short-term storage or permanent storage. The program stored in the storage medium 1630 may include one or more modules (not shown in the figure), and each module may include a series of instruction operations in the server 120. Furthermore, the central processing unit 1622 can be configured to communicate with the storage medium 1630 and execute a series of instruction operations in the storage medium 1630 on the server 120.

[0346] The server 120 may also include one or more power supplies 1626, one or more wired or wireless network interfaces 1650, one or more input and output interfaces 1658, and / or, one or more operating systems 1641, such as Windows ServerTM, Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM, etc.

[0347] The central processor 1622 in the server 120 can be used to execute the login management method of the embodiment of the present disclosure.

[0348] The embodiments of the present disclosure also provide a computer-readable storage medium, which is used to store program codes, and the program codes are used to execute the login management methods of the aforementioned embodiments.

[0349] The embodiment of the present disclosure also provides a computer program product, which includes a computer program. A processor of a computer device reads and executes the computer program, so that the computer device executes and implements the above-mentioned login management method.

[0350] The terms "first", "second", "third", "fourth", etc. (if any) in the specification of the present disclosure and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present disclosure described herein can, for example, be implemented in an order other than those illustrated or described herein. In addition, the terms "comprises" and "comprising" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0351] It should be understood that in the present disclosure, "at least one (item)" means one or more, and "plurality" means two or more. "And / or" is used to describe the association relationship of associated objects, indicating that three relationships may exist. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally indicates that the objects associated before and after are in an "or" relationship. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple.

[0352] It should be understood that in the description of the embodiments of the present disclosure, the meaning of multiple (or multiple items) is more than two, greater than, less than, exceed, etc. are understood to not include the number, and above, below, within, etc. are understood to include the number.

[0353] In the several embodiments provided in the present disclosure, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

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

[0355] In addition, each functional unit in each embodiment of the present disclosure may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0356] If the integrated unit is implemented in the form of 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 the present disclosure is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the various embodiments of the present disclosure. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (Read-Only Memory, referred to as ROM), random access memory (Random Access Memory, referred to as RAM), disk or optical disk and other media that can store program codes.

[0357] It should also be understood that the various implementations provided in the embodiments of the present disclosure can be combined arbitrarily to achieve different technical effects.

[0358] The above is a specific description of the implementation methods of the present disclosure, but the present disclosure is not limited to the above implementation methods. Technical personnel familiar with the art can also make various equivalent modifications or substitutions without violating the spirit of the present disclosure. These equivalent modifications or substitutions are all included in the scope defined by the claims of the present disclosure.

Claims

1. A login management method, characterized in that: include: When receiving a login request, obtaining an object identifier and a first client version identifier included in the login request; Identify the risk level of the target object corresponding to the object identifier; searching first version information of a target client based on the first client version identifier, the target client being a client that issues the login request and corresponds to a target application, the first version information indicating that the target client has a first risk management capability; Determine second version information corresponding to the risk level, where the second version information indicates a second risk control capability, where the second risk control capability is a minimum risk control capability required for allowing an object corresponding to the risk level to log in to a client of the target application; When the first risk management capability is lower than the second risk management capability, the target object is prohibited from logging into the target application based on the login request.

2. The method according to claim 1, characterized in that After determining the second version information corresponding to the risk level, the method further includes: When the first risk control capability is not lower than the second risk control capability, issuing an access ticket to the target client, where the access ticket carries the first client version identifier; receiving a data access request carrying the access ticket, and performing a security check on the data access request based on the first client version identifier; When the security check result of the data access request is unqualified, the sender of the data access request is prohibited from accessing the business data.

3. The method according to claim 2, characterized in that The receiving the data access request carrying the access ticket and performing security detection on the data access request includes: When receiving a data access request carrying the access ticket, obtaining a second client version identifier of a sender of the data access request; When it is detected that the first client version identifier matches the second client version identifier, determining that the security detection result of the data access request is qualified; When it is detected that the first client version identifier does not match the second client version identifier, it is determined that the security detection result of the data access request is unqualified.

4. The method according to claim 1, characterized in that: Before searching for the first version information of the target client based on the first client version identifier, the method further includes: Get multiple version information of multiple applications; Normalizing the multiple version information of the multiple applications to obtain a first mapping relationship table, wherein the first mapping relationship table stores a client version identifier corresponding to each version information of each application; The searching for the first version information of the target client based on the first client version identifier includes: The first version information of the target client is searched in the first mapping table based on the first client version identifier.

5. The method according to claim 4, characterized in that The normalizing the multiple version information of the multiple applications to obtain a first mapping relationship table includes: Generate a first field based on application information of each application, generate a second field based on platform information of different platforms, and generate a third field based on different version information of each application; A field combination corresponding to different version information of each application on different platforms is determined to obtain a first mapping relationship table, where the field combination is a combination of the first field, the second field, and the third field.

6. The method according to claim 4, characterized in that After the plurality of version information of the plurality of applications are normalized to obtain the first mapping relationship table, the method further includes: Get the preset mapping relationship table update frequency; Reacquire multiple new version information of the multiple applications based on the update frequency of the mapping relationship table, and update the first mapping relationship table based on the multiple new version information of the multiple applications.

7. The method according to claim 1, characterized in that The determining the second version information corresponding to the risk level includes: Obtaining a second mapping relationship table, wherein the second mapping relationship table stores mapping relationships between different risk levels and baseline versions of different applications, wherein the baseline version is a version with the lowest risk control capability that can be used by objects of corresponding risk levels; Based on the risk level, search the second mapping relationship table for second version information corresponding to the target application.

8. The method according to claim 7, characterized in that The obtaining of the second mapping relationship table includes: Receive the baseline version editing instructions input by the operation management personnel; A second mapping relationship table is generated based on the baseline version editing instruction.

9. The method according to claim 1, characterized in that: After determining the second version information corresponding to the risk level, the method further includes: When the first risk control capability is lower than the second risk control capability, sending a login prohibition prompt to the target client, and Send a version update notification to the target client.

10. The method according to claim 1, characterized in that The identifying the risk level of the target object corresponding to the object identifier includes: Acquire a first object feature and a first operation feature of a target object corresponding to the object identifier; A risk level of the target object is determined according to the first object feature and the first operation feature.

11. The method according to claim 10, characterized in that After obtaining the first object feature and the first operation feature of the target object corresponding to the object identifier, the method further includes: Obtaining the associated object of the target object; Acquire a second object feature and a second operation feature of the associated object; The determining the risk level of the target object according to the first object feature and the first operation feature includes: A risk level of the target object is determined according to the first object feature, the first operation feature, the second object feature, and the second operation feature.

12. A login management device, characterized in that: include: A first acquisition unit, configured to, when receiving a login request, acquire an object identifier and a first client version identifier contained in the login request; An identification unit, used to identify the risk level of the target object corresponding to the object identifier; a searching unit, configured to search for first version information of a target client based on the first client version identifier, wherein the target client is a client that issues the login request and corresponds to a target application, and the first version information indicates that the target client has a first risk management capability; A determination unit determines second version information corresponding to the risk level, where the second version information indicates a second risk control capability, where the second risk control capability is a minimum risk control capability required for allowing an object corresponding to the risk level to log in to a client of the target application; A login prohibiting unit is used to prohibit the target object from logging into the target application based on the login request when the first risk management capability is lower than the second risk management capability.

13. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the login management method according to any one of claims 1 to 11 is implemented.

14. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the login management method according to any one of claims 1 to 11 is implemented.

15. A computer program product, comprising a computer program, wherein the computer program is read and executed by a processor of a computer device, so that the computer device executes the login management method according to any one of claims 1 to 11.

Images