Risk control method, device and electronic equipment

Abstract

The present application provides a risk control method, apparatus, and electronic device. In the present application, the device information of risky devices is stored in a cached black device library or an offline black device library, wherein the cached black device library is located on the server, and caches the device information newly added during the current time period that is determined to be a risky device, thereby ensuring the timeliness of the risky device information update; the offline black device library is located on other devices independent of the server where the cached black device library is located, and stores the device information of risky devices before the current time period, thereby avoiding the large amount of historical data occupying too much space on the server. The two black device libraries work together to improve the timeliness of risky device information updates, achieve rapid discovery and punishment of subsequent attacks on risky devices, and promptly protect applications from subsequent batch attacks and harassment from newly added risky devices, thereby achieving better protection effects and improving the overall performance of the risk control system.

Description

Technical Field

[0001] The present application relates to the field of Internet technology, and in particular to a risk control method, device and electronic equipment. Background Art

[0002] In the risk control system, in order to increase the registration cost of online black market accounts and protect the security and atmosphere of application use, some devices will be listed as risky devices and accounts using risky devices will be prohibited from logging in.

[0003] However, the current solution of storing risk device information in an offline library has the problem of low timeliness. That is, after a device is listed as a risk device, it cannot be immediately stored in the offline library storing risk device information and the server cannot immediately query the newly added risk device. It is impossible to protect the application from subsequent batch attacks and harassment from this newly added risk device until the offline library is updated, which is not conducive to the risk control system's protection of the application. Summary of the Invention

[0004] The present application provides a risk control method, device and electronic equipment to improve the timeliness of the risk control system for updating risk device information and obtain better protection effects.

[0005] According to a first aspect of an embodiment of the present application, a risk control method is provided, the method comprising:

[0006] For a first device, when the device information of the first device is found in an obtained cached black device library or an offline black device library, the first device is determined to be a risk device; when the device information of the first device is not found in the cached black device library and the offline black device library, if an instruction indicating that the first device is a risk device is received, or the first device is determined to be a risk device according to a specified risk control rule, the first device is determined to be a risk device; the cached black device library is used to cache device information newly added as risk devices in the current time period; the offline black device library is used to store device information determined as risk devices before the current time period; the cached black device library is located on the server, and the offline black device library is located on other devices independent of the server; the device information includes at least a device identification code;

[0007] Perform risk control on the associated account associated with the first device.

[0008] In a possible implementation, the device information of the first device is obtained in the following manner:

[0009] receiving device information of the first device reported by a first account currently using the first device during registration; or

[0010] Receive device information of the first device reported by a first account currently using the first device when logging in.

[0011] In this embodiment, the first account using the first device reports the device information of the first device when registering or logging in. This information can be used to check whether the device information of the first device exists in the cached black device library or the offline black device library.

[0012] In one possible implementation, when device information of a first device is found in the obtained cached black device library or offline black device library, and the associated account associated with the first device is a first account currently using the first device, risk control of the first account may include:

[0013] Performing a login prohibition control on the first account; or,

[0014] Force the first account to switch from the current online state to the offline state; or,

[0015] The first account is controlled to use a specified application or a specified function provided by the specified application based on the behavior of the first account in a specified historical time period.

[0016] In this embodiment, when the device information of the first device is found in the cached black device library or the offline black device library, it indicates that the first device is a risky device, and risk control needs to be performed on the first account currently using the first device, including prohibiting login, forcing offline, restricting behavior, etc., to avoid the first account from attacking or harassing, etc., to protect the security of the application and the usage atmosphere.

[0017] In a possible implementation, when the device information of the first device is not found in the cached black device library and the offline black device library, after determining that the first device is a risky device, the device information of the first device is added to the cached black device library.

[0018] In this embodiment, if the device information of the first device does not exist in the cached black device library and the offline black device library and the first device is determined to be a risky device, it indicates that the first device is a newly added risky device and can be added to the cached black device library to facilitate risk control of accounts that subsequently use the first device and expand the risky device information stored in the cached black device library.

[0019] In one possible implementation, the method further includes:

[0020] Obtaining account information of a first account currently using the first device;

[0021] Associating the device information of the first device and the account information and storing them in a cache device library on the server; the cache device library is used to store the device information and account information obtained in the current time period;

[0022] Upon detecting a first update event, updating the offline device library with the cache device library so that the offline device library is updated with all the information cached by the cache device library; wherein the first update event is used to instruct all the information stored in the cache device library to be updated to the offline device library, the offline device library being located on a device independent of the server and being used to store the device information and account information obtained before the current time period;

[0023] Searching for an account that has used the first device from the cache device library and the offline device library;

[0024] Determining the found account as the associated account and performing risk control on the associated account includes:

[0025] For each associated account, execute a login prohibition control on the associated account; or,

[0026] Force the linked account to switch from its current online state to an offline state; or,

[0027] The associated account is controlled to use a specified application or a specified function provided by the specified application based on the behavior of the associated account in a specified historical time period.

[0028] The first update event at least includes:

[0029] Update time arrives; or,

[0030] The current load of the server is less than or equal to the set load threshold; or

[0031] The amount of information cached by the cache device library exceeds a preset threshold.

[0032] In this embodiment, the account information of the first account currently using the first device is obtained, and is associated with the device information of the first device and stored in a cache device library. After a preset event is detected, the offline device library is updated to reduce the server cache pressure while retaining the above-mentioned associated stored data. After determining that the first device is a risky device, risk control is performed on all accounts that have used the first device to avoid possible subsequent attacks or harassment, etc., to protect the security of the application and the usage atmosphere.

[0033] In one possible implementation, the method further includes:

[0034] When a second update event is detected, the cached black device library is used to update the offline black device library, so that the offline black device library is newly updated with all the information cached by the cached black device library; wherein the second update event is used to indicate that all the information stored in the cached black device library is updated to the offline black device library;

[0035] The second update event at least includes:

[0036] Update time arrives; or,

[0037] The current load of the server is less than or equal to the set load threshold; or

[0038] The amount of information cached in the cache black device library exceeds a preset threshold.

[0039] In this embodiment, when a preset event is detected, the offline black device library is updated and the data in the cached black device library is stored in the offline black device library to reduce the server cache pressure while retaining the stored data and accumulating risk device information for subsequent risk control.

[0040] According to a second aspect of an embodiment of the present application, there is provided a risk control device, the device comprising:

[0041] A risk device determination unit is configured to determine, for a first device, that the first device is a risk device when device information of the first device is found in an obtained cached black device library or an offline black device library; and to determine that the first device is a risk device if an instruction indicating that the first device is a risk device is received, or the first device is determined to be a risk device according to a specified risk control rule, when the device information of the first device is not found in either the cached black device library or the offline black device library; the cached black device library is configured to cache device information newly added as risk devices within a current time period; the offline black device library is configured to store device information determined as risk devices before the current time period; the cached black device library is located on the server, and the offline black device library is located on other devices independent of the server;

[0042] A risk control unit is used to perform risk control on the associated account associated with the first device.

[0043] According to a third aspect of an embodiment of the present application, there is provided a risk control electronic device, the electronic device comprising: a processor and a machine-readable storage medium;

[0044] The machine-readable storage medium stores machine-executable instructions that can be executed by the processor;

[0045] The processor is configured to execute the machine-executable instructions to implement the steps of any one of the methods disclosed above.

[0046] According to a fourth aspect of an embodiment of the present application, a machine-readable storage medium is provided, on which a number of computer instructions are stored. When the computer instructions are executed, the steps of any one of the methods disclosed above are implemented.

[0047] As can be seen from the above technical solution, in this embodiment, the device information of risky devices is stored in a cached black device library or an offline black device library. The cached black device library is located on the server and caches the device information newly identified as risky devices during the current time period, ensuring the timeliness of risky device information updates. The offline black device library is located on a separate device independent of the server and stores the device information identified as risky devices before the current time period, preventing large amounts of historical data from occupying excessive server space. The two black device libraries work together to improve the timeliness of risky device information updates, enabling rapid discovery and punishment of subsequent attacks on risky devices, and promptly protecting applications from subsequent batch attacks from newly added risky devices, achieving better protection and enhancing the overall performance of the risk control system. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and, together with the description, serve to explain the principles of the present disclosure.

[0049] Figure 1 A schematic diagram of an architecture provided for an embodiment of the present application;

[0050] Figure 2 A flow chart of the method provided in the embodiment of the present application;

[0051] Figure 3 Another method flow chart provided in an embodiment of the present application;

[0052] Figure 4 An example flow chart provided for an embodiment of the present application;

[0053] Figure 5 A diagram of the device structure provided in an embodiment of the present application;

[0054] Figure 6 This is a structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0055] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements, unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.

[0056] The terms used in this application are for the purpose of describing particular embodiments only and are not intended to limit this application. As used in this application and the appended claims, the singular forms "a," "an," "the," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.

[0057] In order to enable those skilled in the art to better understand the technical solutions provided by the embodiments of the present application, and to make the above-mentioned purposes, features and advantages of the embodiments of the present application more obvious and easy to understand, the technical solutions in the embodiments of the present application are further described in detail below with reference to the accompanying drawings.

[0058] In the risk control system, users are categorized based on their device, behavior, content, and other information to distinguish their different risk levels. Penalties and behavioral restrictions are then imposed to protect product safety and the overall product environment. When a user logs in and registers, if they click to allow the reporting of information such as the International Mobile Equipment Identity (IMEI), the client's embedded software development kit (SDK) will collect and report the device information. Once the data is reported to the risk control system, if the user's device is judged to be unsafe or risky, the system will prohibit their login or restrict their use of certain product features based on the risk level.

[0059] When designing and building a risk control system, in order to increase the cost of black market registration, some devices will be directly banned from logging in, which has a good protective effect on product atmosphere and resources. The embodiment of this application achieves the above purpose by caching user device information online and then combining it with an offline database to directly punish the device.

[0060] The embodiments of the present application can store the device information reported by high-risk users in the past as an offline blacklist library. If a new user uses a device on the blacklist to log in or register again on the same day, the device will be immediately judged as a high-risk device, and the user will be forced to log out of the application, that is, the device will be blocked. The embodiments of the present application can combine the offline blacklist library with the newly added blacklist devices on the same day, which greatly saves cache resources on the server. Especially for social applications with tens of billions of historical registered users, caching all the device information of risky devices in the server will cause a huge waste of server storage resources. The method provided by the embodiments of the present application can effectively solve this problem. In addition, the embodiments of the present application also introduce how to perform real-time incremental expansion of the blacklist library to improve timeliness after a new device is identified as a risky device on the same day. In addition, the embodiments of the present application provide an effective method for how to trace back the historical users who have used the risky device for a newly added risky device.

[0061] See also Figure 1 , Figure 1 A schematic diagram of an architecture provided for an embodiment of the present application:

[0062] exist Figure 1 In the illustrated network, server 111 and network device 112 are deployed. Optionally, server 111 may be a risk control server, configured to provide risk control protection for a specific application, or an application server that also provides risk control functionality, etc., although this embodiment is not limiting in this regard. Network device 112 is a different network device than server 111. Optionally, network device 112 may be a server, such as a database server.

[0063] As an embodiment, the server 111 caches a cached black device library 121 and a cached device library 122 , and the network device 112 stores an offline black device library 123 and an offline device library 124 .

[0064] Optionally, as an embodiment, the cached black device library 121 is used to cache the IMEI information of risky devices newly added within 24 hours, and the offline black device library 123 is used to store the IMEI information of devices that were determined to be risky devices 24 hours ago. When a device is determined to be a risky device, the IMEI information of the device is added to the cached black device library. Every 24 hours, the IMEI information stored in the cached black device library 121 is stored in the offline black device library 123, and the cache of the cached black device library 121 is released.

[0065] As an embodiment, the server 111 caches a cached black device library 121 and a cached device library 122 , and the network device 112 stores an offline black device library 123 and an offline device library 124 .

[0066] Optionally, as an embodiment, when account 101 uses device 102 to log in to the application, server 111 obtains the user identifier UID information of account 101 and the IMEI information of device 102, and associates and stores the obtained UID information and IMEI information in the cache device library 122. The cache device library 122 is used to cache the above information newly added within 24 hours, and the offline device library 124 is used to store the above login information from 24 hours ago. Every 24 hours, the UID information and IMEI information associated and stored in the cache device library 122 are stored in the offline device library 124, and the cache of the cache device library 122 is released.

[0067] It should be noted that, optionally, the offline black device library 123 and the offline device library 124 can be stored in the same network device or in different network devices respectively; the server 111 can obtain the required information from the device 102, or obtain the information reported by the device 102 from other servers; the device 102 can log in to multiple different accounts, and the account 101 can also log in to multiple different devices, etc. Figure 1 The example shown is only one possible architecture and is not intended to limit this application.

[0068] See also Figure 2 , Figure 2 This is a flow chart of a method provided in an embodiment of the present application. Optionally, as an embodiment, the process can be applied to a server, such as a risk control server in a risk control system, or directly to an application server, etc., which is not limited in this embodiment.

[0069] like Figure 2 As shown, the process may include the following steps:

[0070] Step 201: For the first device, when the device information of the first device is found in the obtained cached black device library or offline black device library, the first device is determined to be a risky device. When the device information of the first device is not found in both the cached black device library and the offline black device library, if an instruction indicating that the first device is a risky device is received, or the first device is determined to be a risky device according to a specified risk control rule, the first device is determined to be a risky device.

[0071] In this embodiment, the cached black device library and the offline black device library store device information of risky devices. The device information here includes at least a device identification code. For example, the device identification code may include but is not limited to at least one of the following: IMEI, Media Access Control Address (MAC Address), operating system ID, and other identification information that can be uniquely matched with the device used in the account. This embodiment does not limit the specific device identification code used, whether one or more device identification codes are used, whether the device information contains other information besides the device identification code of the device, etc.

[0072] The cached black device database stores information about devices newly identified as risky devices during the current time period, while the offline black device database stores information about devices identified as risky devices before the current time period. The cached black device database resides on a server, while the offline black device database resides on a separate device independent of the server. For example, the offline black device database can be located on a database server, using a database such as Hive (a data warehouse analysis system), MySQL (a relational database management system), HBase (a distributed storage system), or a graph database for data storage, though this embodiment does not limit this.

[0073] In this embodiment, when determining whether a device is a risky device, the device identification code of the device can be searched in the cached black device library and the offline black device library. Preferably, because the cached black device library is cached on the server, the query speed is faster. Therefore, the device identification code of the device can be searched in the cached black device library first. If the device identification code of the device does not exist in the cached black device library, the device identification code of the device can be searched in the offline black device library. If the device identification code of the device exists in the cached black device library or the offline black device library, the device can be determined to be a risky device, and risk control can be performed on the associated accounts of the device in subsequent steps.

[0074] Optionally, the method for obtaining the device information of the device may be to receive the device information of the device reported by the account currently using the device when registering, or to receive the device information of the device reported by the account currently using the device when logging in, etc. This embodiment does not limit how to obtain the device information of the device.

[0075] If the device identification code for the device does not exist in either the cached black device database or the offline black device database, the device may be confirmed as a risky device through other means, such as receiving an instruction indicating that the device is a risky device, or determining that the device is a risky device according to specified risk control rules. For example, during manual review, an administrator may discover that a device or an account on a device has engaged in risky behavior, list the device as a risky device, and notify the server of this risky device through instructions. Alternatively, the system may identify that a device has triggered or violated a preset risk control rule. For example, if the system detects that an account using a device has sent fraudulent links or information related to terrorism and violence multiple times within a certain period of time, the account will be subject to risk control and the device will be listed as a risky device.

[0076] The device is listed as a risk device, etc. This embodiment does not limit the specific method for determining the device as a risk device.

[0077] Optionally, when the device identification code of a certain device does not exist in both the cached black device library and the offline black device library, but the device is subsequently determined to be a risky device through other means, the device information of the device can be added to the cached black device library.

[0078] Optionally, updating the device information of the newly added risky device in the offline black device library may include storing all information stored in the cached black device library in the offline black device library and deleting the risky device information in the current time period from the cached black device library.

[0079] Furthermore, when an event is detected that indicates that all information stored in the cached black device library is updated to the offline black device library, such as when a preset update time is detected, when the current server load is detected to be less than or equal to a set load threshold, when the amount of information cached in the cached black device library is detected to exceed a preset threshold, etc., the cached black device library is used to update the offline black device library so that the offline black device library is newly updated with all the information cached in the cached black device library. This embodiment does not limit the conditions for updating the offline black device library. With respect to the aforementioned current time period, when the aforementioned event is the detection of the arrival of a preset update time, for example, the preset update time may be updated every 24 hours, then the current time period may be 24 hours before the preset update time; when the aforementioned event is the detection of the current server load being less than or equal to a set load threshold, then the current time period may be the time before the load is less than or equal to the set load threshold; when the aforementioned event is the detection of the amount of information cached in the cached black device library exceeding a preset threshold, then the current time period may be the time before the amount of information cached in the cached black device library exceeds the preset threshold.

[0080] Step 202: Perform risk control on the associated account associated with the first device.

[0081] In this embodiment, when the device information of the first device is found in the obtained cached black device library or offline black device library, the associated account associated with the first device may include the first account currently using the first device, and risk control is performed on the first account.

[0082] Optionally, risk control of the first account may include: prohibiting the first account from logging into an application or server, forcing the first account to switch from a current online state to an offline state, controlling the first account to use a specified application or a specified function provided by a specified application based on the behavior of the first account in a specified historical time period, etc. This embodiment does not limit the specific content of the risk control.

[0083] Optionally, when the device identification code of a certain device does not exist in both the cached black device library and the offline black device library, but the device is subsequently determined to be a risky device through other means, risk control can also be performed on the associated account of the device. The associated account of the device can include the account currently using the device, or it can be other accounts. For the case where the associated account is other accounts, it will be described in detail in conjunction with another embodiment later and will not be repeated here.

[0084] So far, completed Figure 2 The process shown.

[0085] pass Figure 2 As can be seen from the illustrated process, in this embodiment, risky device information is stored in a cached black device database or an offline black device database. The cached black device database resides on the server and caches information about devices newly identified as risky during the current time period, ensuring timely updates of risky device information. The offline black device database, located on a separate device independent of the server, stores information about devices identified as risky before the current time period, preventing excessive server space from being occupied by large amounts of historical data. These two black device databases work together to improve the timeliness of risky device information updates, enabling rapid detection and punishment of subsequent attacks against risky devices. This protects applications from subsequent batch attacks from newly identified risky devices, resulting in better protection and enhancing the overall performance of the risk control system.

[0086] The method provided in this embodiment is particularly important for social applications. Currently, internet finance doesn't require a specific timeliness for blocking devices, so using a separate offline library alone can meet this requirement. However, social applications have higher timeliness requirements, requiring rapid discovery and punishment to avoid subsequent batch attacks and harassment.

[0087] The method provided in this embodiment is a lightweight framework design. Compared to caching all risky device information on a server or real-time database, it significantly reduces server pressure and conserves server resources, providing ample space for the server to run other complex applications. Furthermore, some existing risk control systems identify risky devices by pre-setting risky device information or using third-party risky device information libraries. For internet companies, the method provided in this embodiment can fully utilize their own platform resources. For example, by leveraging large-scale social applications, they can continuously accumulate their own black device database, effectively utilizing their own platform resources.

[0088] Preferably, the embodiment of the present application also provides another method flow.

[0089] See also Figure 3 , Figure 3 Another method flow chart provided in an embodiment of the present application.

[0090] Step 301: Obtain account information of a first account currently using a first device.

[0091] This embodiment is compared Figure 2 In another embodiment, in addition to obtaining device information, it is also necessary to obtain account information of the account currently using the device. The account information includes at least an account identification code that can be used to identify or distinguish the account. For example, the account identification code can be a user identifier (UID), etc., which is not limited in this embodiment.

[0092] Optionally, the method for obtaining the device information of the device and the account information of the account may be to receive the device information of the device and the account information of the account reported by the account currently using the device during registration, or to receive the device information of the device and the account information reported by the account currently using the device during login, etc. This embodiment does not limit how to obtain the device information of the device and the account information of the account.

[0093] Step 302: Associate the device information and account information of the first device and store them in a cache device library on the server.

[0094] In this embodiment, the cached device library is located on the server and is used to store device information and account information obtained during the current time period. The device information obtained in step 301 is associated with the account information of the account currently using the device and stored in the cached device library. This can be used to subsequently query the account associated with the device using the device information, or to query the devices associated with the account using the account information.

[0095] Step 201: For the first device, when the device information of the first device is found in the obtained cached black device library or offline black device library, the first device is determined to be a risky device. When the device information of the first device is not found in both the cached black device library and the offline black device library, if an instruction indicating that the first device is a risky device is received, or the first device is determined to be a risky device according to a specified risk control rule, the first device is determined to be a risky device.

[0096] In this embodiment, step 201 can refer to the aforementioned Figure 1 The introduction of step 201 in the method flow shown is not repeated here.

[0097] Step 303: Search the cache device library and the offline device library for an account that has used the first device, determine the found account as an associated account associated with the first device, and perform risk control on the associated account.

[0098] It should be noted that, in this embodiment, after a device is determined to be a risky device, the associated account may be the account currently using the device. The subsequent processing method for this situation is as described above. Figure 1 The step 202 has been described in detail, so it will not be repeated here.

[0099] The associated account can also be an account that has previously used the device. For example, after a device is identified as a risky device, the cached device library and offline device library are searched for account information associated with the device information based on the device information. The found account is identified as the associated account, and risk control is performed on the associated account. The offline device library is used to store device information and account information obtained before the current time period. The offline device library is located in a device independent of the above-mentioned server. For example, the offline device library can be established in a database server and use a Hive database, MySQL database, HBase database, graph database, etc. for data storage, which is not limited in this embodiment.

[0100] Optionally, in the case where a device identified as a risky device has multiple associated accounts, risk control can be performed on all associated accounts in a unified manner, or risk control can be performed on each associated account separately. For example, for each associated account, login prohibition control can be performed on the associated account, the associated account can be forced to switch from the current online state to the offline state, and the associated account can be controlled to use a specified application or a specified function provided by a specified application based on the behavior of the associated account in a specified historical time period. This embodiment does not limit this.

[0101] Optionally, updating the newly added device information and account information to the offline device library may include storing all information stored in the cache device library to the offline device library, and deleting risky device information within the current time period from the cache black device library.

[0102] Furthermore, when an event is detected for indicating that all information stored in the cache device library is updated to the offline device library, such as detecting that a preset update time has arrived, detecting that the current load of the server is less than or equal to a set load threshold, detecting that the amount of information cached in the cache device library exceeds a preset threshold, etc., the cache device library is used to update the offline device library so that the offline device library is added with all the information cached in the cache device library. This embodiment does not limit the conditions for updating the offline device library.

[0103] So far, completed Figure 3 The process shown.

[0104] pass Figure 3 As can be seen from the illustrated process, in this embodiment, by associating device information with the account information of the account currently using the device and storing it in a cache device library on the server, all accounts that have ever used a device are recorded. If a device is identified as risky, this record can be used to trace all accounts that have used it and conduct risk control. Furthermore, by storing this information separately in a cache device library or an offline device library, which is located on a separate device from the server, this ensures the timeliness of information updates while preventing large amounts of historical data from occupying excessive server space.

[0105] Existing risk control systems only block a user's device and do not retroactively perform risk control or penalties on historical users. However, the method provided in this embodiment will monitor the historical users of the device and determine penalties and restrictions for these users based on other dimensions, thus achieving a mechanism for rapid feedback and disposal.

[0106] In order to enable those skilled in the art to better understand the technical solution provided by this embodiment, the technical solution is further described in detail below with reference to specific examples.

[0107] See also Figure 4 , Figure 4 This is an example flow chart of an embodiment of the present application. Optionally, this flow uses a new account registration application as an example to illustrate how to determine whether the device used by the account is a risky device, and, if the device is subsequently determined to be a risky device, how to perform risk control on the account and how to record risky device information for subsequent use.

[0108] Step 401: register a new account, obtain the account information of the account and the device information of the device used, and store them in the cache device library.

[0109] When a new account is registered, the device information of the device used by the account and the account information of the registered account are obtained. These device and account information are then associated and stored in a cached device library for subsequent use. This cached device library is used to store the device and account information reported by all new accounts that day. Combined with the offline device library that stores historical device and account information, it serves as a complete device library. The cached device library stores new information in the offline device library daily and clears the corresponding cache to avoid excessive server resource usage.

[0110] Step 411: Determine whether the device in use is a risky device.

[0111] After obtaining the device information for the aforementioned device, the cached black device database and the offline black device database are searched for the device's information. If the device information exists in either the cached black device database or the offline black device database, the device is determined to be a risk device. Otherwise, the device is not considered a risk device in this step. The cached black device database is used to store the device information of newly added risk devices that day. Combined with the offline black device database, which stores the device information of historical risk devices, it can be used to determine whether a device has been listed as a risk device. The cached black device database stores the newly added information in the offline black device database daily and clears the corresponding cache to avoid excessive server resource usage.

[0112] Step 412: Perform risk control on the account.

[0113] If the device is determined to be a risky device in step 411, risk control is performed on the account registered using the device, such as prohibiting the account from logging in or restricting the account from using certain application functions. Alternatively, upon receiving an account registration request, a determination may be made as to whether the device is a risky device. If so, the registration request may be blocked.

[0114] Step 421: Determine whether the device used is subsequently determined to be a risky device.

[0115] The device used is subsequently determined to be a risky device. This may mean that when the device is making the determination in step 411, the device or the account on the device has not yet performed a risky behavior that may cause the device to be listed as a risky device. It may also mean that the device or the account on the device has already performed a risky behavior that may cause the device to be listed as a risky device, but has not yet been listed as a risky device when the determination in step 411 is made. This embodiment does not limit this.

[0116] There may be various reasons why a device used is subsequently determined to be a risky device. For example, during manual review, an administrator may discover that a device or an account on a device has risky behavior, list the device as a risky device, and inform the server that the device is a risky device in the form of instructions, etc.; or, the system may identify that a device has triggered or violated a preset risk control rule and list the device as a risky device, etc. This embodiment does not limit the specific method by which the above-mentioned devices are determined to be risky devices.

[0117] Step 422: No risk control is performed.

[0118] If the device used is not subsequently identified as a risky device, there is no need to perform risk control on the device or the account using the device.

[0119] Step 431: query the cache device library and offline device library to perform risk control on accounts that have used the device.

[0120] In step 421, if the device is subsequently determined to be a risky device, the cached device library and the offline device library are searched for account information associated with the device information based on the device information. The found accounts are those that have previously used the device, and risk control can be performed on these accounts. Optionally, if the device is determined to be a risky device in step 411, when risk control is performed on the account in step 412, step 431 can also be referred to, and risk control can be performed on the accounts that have previously used the device.

[0121] Step 441: Store the device information of the device into a cached black device database.

[0122] After the above-mentioned device is determined to be a risky device, the device information of the device is stored in the cached black device library to expand the cached black device library. When other accounts subsequently log in or register through this device, since the device has been stored in the cached black device library, it is possible to directly determine whether the device used by the above-mentioned account is a black device by searching the database.

[0123] It should be noted that there is no restriction on the execution order of step 431 and step 441 , and step 441 may be executed first and then step 431 , or step 431 and step 441 may be executed simultaneously.

[0124] Optionally, the offline device library or offline black device library may be updated periodically or based on other conditions. For details, please refer to the introduction of updating the offline device library and offline black device library in the aforementioned step 201 or step 303, which will not be repeated here.

[0125] So far, completed Figure 4 The process shown.

[0126] The method provided in this embodiment is described above. The device provided in this embodiment is described below:

[0127] See also Figure 5 , Figure 5 This is a diagram of the device structure provided in the embodiment of the present application. Figure 2 As shown in the process. Figure 5 As shown, the device may include:

[0128] 501, a risk device determination unit, is used to determine, for a first device, that the first device is a risk device when the device information of the first device is found in an obtained cached black device library or an offline black device library; when the device information of the first device is not found in either the cached black device library or the offline black device library, if an instruction indicating that the first device is a risk device is received, or the first device is determined to be a risk device according to a specified risk control rule, then the first device is determined to be a risk device.

[0129] 502, a risk control unit, configured to perform risk control on an associated account associated with the first device.

[0130] Optionally, in the risky device determining unit, the device information of the first device is obtained in the following manner:

[0131] Receive device information of the first device reported by the first account currently using the first device during registration, or receive device information of the first device reported by the first account currently using the first device during login.

[0132] Optionally, in the risk control unit, when device information of the first device is found in the obtained cached black device library or offline black device library, performing risk control on the associated account associated with the first device includes performing risk control on the first account currently using the first device.

[0133] Optionally, in the risk control unit, risk control of the first account currently using the first device includes executing login prohibition control on the first account, or forcing the first account to switch from the current online state to the offline state, or controlling the first account to use a specified application or a specified function provided by a specified application based on the behavior of the first account in a specified historical time period.

[0134] Optionally, in the risky device determining unit, when the device information of the first device is not found in either the cached black device library or the offline black device library, after determining that the first device is a risky device, the device information of the first device is added to the cached black device library.

[0135] Optionally, the risky device determination unit further includes:

[0136] Obtaining account information of a first account currently using the first device;

[0137] Associating the device information and account information of the first device with each other and storing them in a cache device library on the server; the cache device library is used to store the device information and account information obtained in the current time period;

[0138] When the first update event is detected, the cache device library is used to update the offline device library, so that the offline device library is newly updated with all the information cached by the cache device library.

[0139] Optionally, in the risk control unit, performing risk control on the associated account associated with the first device includes:

[0140] Searching for an account that has used the first device from a cached device library and an offline device library;

[0141] The found accounts are identified as associated accounts, and risk control is performed on the associated accounts.

[0142] Optionally, in the risk control unit, risk control of associated accounts includes: for each associated account, executing login prohibition control on the associated account, or forcing the associated account to switch from the current online state to the offline state, or controlling the associated account to use a specified application or a specified function provided by a specified application based on the behavior of the associated account in a specified historical time period.

[0143] Optionally, in the risky device determination unit, the first update event includes at least:

[0144] The update time arrives, or the current server load is less than or equal to the set load threshold, or the amount of information cached in the cache device library exceeds the preset threshold.

[0145] Optionally, the risky device determination unit further includes:

[0146] When a second update event is detected, the offline black device library is updated using the cached black device library, so that the offline black device library is newly updated with all the information cached by the cached black device library;

[0147] The second update event at least includes: the update time arrives, or the current load of the server is less than or equal to the set load threshold, or the amount of information cached in the cache black device library exceeds a preset threshold.

[0148] So far, completed Figure 5 Structural description of the device shown.

[0149] The present application also provides Figure 5 The hardware structure of the device shown. Figure 6 , Figure 6This is a structural diagram of an electronic device provided in an embodiment of the present application. Figure 6 As shown, the hardware structure may include: a processor and a machine-readable storage medium, the machine-readable storage medium storing machine-executable instructions that can be executed by the processor; the processor is used to execute the machine-executable instructions to implement the method disclosed in the above example of this application.

[0150] Based on the same application concept as the above method, an embodiment of the present application also provides a machine-readable storage medium, on which a number of computer instructions are stored. When the computer instructions are executed by a processor, the method disclosed in the above example of the present application can be implemented.

[0151] Exemplarily, the machine-readable storage medium may be any electronic, magnetic, optical, or other physical storage device that may contain or store information, such as executable instructions, data, and the like. For example, the machine-readable storage medium may be: RAM (Random Access Memory), volatile memory, non-volatile memory, flash memory, a storage drive (such as a hard disk drive), a solid-state drive, any type of storage disk (such as a CD, DVD, etc.), or similar storage media, or a combination thereof.

[0152] The systems, devices, modules, or units described in the above embodiments may be implemented by computer chips or entities, or by products having certain functions. A typical implementation device is a computer, which may be in the form of a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email transceiver, game console, tablet computer, wearable device, or any combination of these devices.

[0153] For the convenience of description, the above devices are described as being divided into various units according to their functions. Of course, when implementing this application, the functions of each unit can be implemented in the same or multiple software and / or hardware.

[0154] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the embodiments of the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0155] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the steps in the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0156] Furthermore, these computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0157] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for executing on the computer or other programmable device to implement the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0158] The foregoing is merely an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should all be included within the scope of the claims of the present application.

Claims

1. A risk control method, characterized in that: The method is applied to a server and includes: For a first device, when the device information of the first device is found in an obtained cached black device library or an offline black device library, the first device is determined to be a risk device; when the device information of the first device is not found in the cached black device library and the offline black device library, if an instruction indicating that the first device is a risk device is received, or the first device is determined to be a risk device according to a specified risk control rule, the first device is determined to be a risk device; the cached black device library is used to cache device information newly added as risk devices in the current time period; the offline black device library is used to store device information determined as risk devices before the current time period; the cached black device library is located on the server, and the offline black device library is located on other devices independent of the server; the device information includes at least a device identification code; Perform risk control on the associated account associated with the first device.

2. The method according to claim 1, characterized in that The device information of the first device is obtained in the following manner: receiving device information of the first device reported by a first account currently using the first device during registration; or Receive device information of the first device reported by a first account currently using the first device when logging in.

3. The method according to claim 1, characterized in that When the device information of the first device is found in the obtained cached black device library or offline black device library, the risk control of the associated account associated with the first device includes: Risk control is performed on a first account currently using the first device.

4. The method according to claim 3, characterized in that The performing risk control on the first account currently using the first device includes: Performing a login prohibition control on the first account; or, Force the first account to switch from the current online state to the offline state; or, The first account is controlled to use a specified application or a specified function provided by the specified application based on the behavior of the first account in a specified historical time period.

5. The method according to claim 1, wherein When the device information of the first device is not found in the cached black device database and the offline black device database, after determining that the first device is a risky device, the method further includes: Add the device information of the first device to the cached black device library.

6. The method according to claim 1, wherein The method further comprises: Obtaining account information of a first account currently using the first device; Associating the device information of the first device and the account information and storing them in a cache device library on the server; the cache device library is used to store the device information and account information obtained in the current time period; When a first update event is detected, the cache device library is used to update the offline device library so that the offline device library is newly added with all the information cached by the cache device library; wherein the first update event is used to indicate that all information stored in the cache device library is updated to the offline device library, and the offline device library is located on other devices independent of the server and is used to store the device information and account information obtained before the current time period.

7. The method according to claim 6, characterized in that Performing risk control on the associated account associated with the first device includes: Searching for an account that has used the first device from the cache device library and the offline device library; The found account is determined as the associated account, and risk control is performed on the associated account.

8. The method according to claim 7, characterized in that Risk control of the associated accounts includes: For each associated account, execute a login prohibition control on the associated account; or, Force the linked account to switch from its current online state to an offline state; or, The associated account is controlled to use a specified application or a specified function provided by the specified application based on the behavior of the associated account in a specified historical time period.

9. The method according to claim 6, characterized in that The first update event at least includes: Update time arrives; or, The current load of the server is less than or equal to the set load threshold; or The amount of information cached by the cache device library exceeds a preset threshold.

10. The method according to claim 1, characterized in that The method further comprises: When a second update event is detected, the cached black device library is used to update the offline black device library, so that the offline black device library is newly updated with all the information cached by the cached black device library; wherein the second update event is used to indicate that all the information stored in the cached black device library is updated to the offline black device library; The second update event at least includes: Update time arrives; or, The current load of the server is less than or equal to the set load threshold; or The amount of information cached in the cache black device library exceeds a preset threshold.

11. A risk control device, characterized in that: The device is applied to a server and includes: A risk device determination unit is configured to determine, for a first device, that the first device is a risk device when the device information of the first device is found in an obtained cached black device library or an offline black device library; and to determine that the first device is a risk device if an instruction indicating that the first device is a risk device is received, or the first device is determined to be a risk device according to a specified risk control rule, when the device information of the first device is not found in either the cached black device library or the offline black device library; the cached black device library is configured to cache device information newly added as risk devices within a current time period; the offline black device library is configured to store device information determined as risk devices before the current time period; the cached black device library is located on the server, and the offline black device library is located on other devices independent of the server; the device information includes at least a device identification code; A risk control unit is used to perform risk control on the associated account associated with the first device.

12. An electronic device, characterized in that: include: a processor and a machine-readable storage medium storing machine-executable instructions capable of being executed by the processor; The processor is configured to execute the machine-executable instructions to implement the method steps described in any one of claims 1 to 10.

13. A machine-readable storage medium, characterized in that The machine-readable storage medium stores a plurality of computer instructions, and when the computer instructions are executed, the method steps described in any one of claims 1 to 10 are implemented.

Images