Non-inductive continuous authentication anti-stealing-link method

Abstract

The invention provides a non-inductive continuous authentication anti-stealing-link method, which is applied to an HLS streaming media transmission protocol and comprises the following steps: a client sends an authentication request containing unique authentication information to a service server; the service server obtains a first information identifier based on the authentication request, and the unique authentication information, the first information identifier and the live broadcast resource address are included in authentication information and forwarded to an authentication server; the authentication server generates a permission token based on the authentication information, and returns the permission token to the business server; the service server splices the permission token into the live broadcast resource address to form a parametric address, and returns the parametric address to the client; and the client periodically sends a polling request to the live broadcast resource server based on the parametric address so as to obtain the live broadcast content from the live broadcast resource server. The method has the beneficial effects that non-inductive continuous authentication is realized, and the authentication information is complex in composition and not easy to crack.

Description

Technical Field

[0001] This invention relates to the field of live streaming, and more particularly to a seamless, continuous authentication method for preventing hotlinking. Background Technology

[0002] Live streaming is a method of broadcasting content that transmits video and audio received from a single user to multiple users in real time, based on network transmission protocols. With the rise of the live streaming industry, hotlinking has also proliferated. Hotlinking is a technique that steals live stream links to intercept traffic and generate revenue. Hotlinkers steal live stream links from legitimate live streaming platforms and broadcast them on illegal private platforms. When users watch the live stream on these illegitimate platforms, their traffic is diverted to the hotlinkers, who can also insert their own advertisements into the stolen live streams for profit. However, legitimate live streaming platforms cannot obtain the revenue generated from the traffic and advertising content from these illegal users. Furthermore, the CDN of legitimate live streaming platforms may have to handle access from these illegal users, leading to server resource consumption and causing buffering issues for legitimate viewers.

[0003] As a countermeasure, most live streaming platforms deploy anti-leeching technologies, which mainly include authentication and heartbeat reporting via client SDK.

[0004] For example, patent document CN201610655444.8 provides a multi-terminal integrated media publishing player generation system and method, comprising six modules: player definition, code generation, code embedding, client judgment, player generation, and video playback. Developers can customize attributes such as the player's logo, channel emblem, on / off indicator, and advertising embedding through the definition module. The code generation module automatically generates complete player code with anti-leeching technology, which is then embedded into a webpage or application page through the code embedding module. When a user initiates a usage request, the client judgment module identifies whether it is a mobile device, and the player generation module generates an HTML5 script or Flash script and calls the player. Finally, the video playback module supports video playback in multiple formats such as MP4 and FLV, and multiple protocols such as HTTP and RTMP, enabling services such as live streaming, video-on-demand, and live replay. For example, patent document CN201610882851.2 provides a method, device, and network server for preventing hotlinking in member live streaming. After receiving a member's live streaming request containing account information, IP and / or MAC address, the server generates a live streaming link embedded with the user identifier and the aforementioned information and returns it to the terminal. The terminal sends a live streaming request containing the corresponding information based on the link. When the server responds, it verifies whether hotlinking has occurred through playback strategies. The verification method can be to collect relevant information from all requests using synchronous or asynchronous online heartbeats, or to classify and collect requests with the same identifier according to the user identifier. The server combines the user identifier, the program being watched, the source IP and MAC address, etc., to determine whether hotlinking has occurred. If it is illegal, it is blocked; if it is legal, playback continues. This allows for real-time identification of abuse of member rights, saving bandwidth and increasing the cost of piracy.

[0005] However, in actual anti-leeching implementation, client requests only undergo authentication once, and authentication is not repeated after that. The client's heartbeat request logic is simple, only continuously sending repetitive information to confirm online status. A leechroutine attacker only needs to successfully intercept one heartbeat and its corresponding frequency to copy it. Existing technologies generally suffer from the problem of lacking subsequent anti-leeching measures after the initial authentication and having limited authentication information. Summary of the Invention

[0006] To address the problems existing in current technologies, this solution proposes a seamless, continuous authentication method for preventing hotlinking, applied to the HLS streaming media transmission protocol, including: Step S1: The client sends an authentication request containing unique authentication information to the business server; Step S2: The service server obtains the first information identifier based on the authentication request, and includes the unique authentication information, the first information identifier, and the live streaming resource address associated with the authentication request in the authentication information and forwards it to the authentication server. Step S3: The authentication server generates an authorization token containing a preset expiration time based on the authentication information, and returns the authorization token to the business server. Step S4: The service server concatenates the permission token as a parameter into the live stream resource address to form a parameterized address, and returns the parameterized address to the client. The client then requests the live stream resource from the live stream resource server based on the parameterized address. Step S5: Before the preset expiration time of the permission token expires, the client periodically sends polling requests to the live streaming resource server to obtain live streaming content from the live streaming resource server.

[0007] Preferably, the unique authentication information includes the client's unique device identifier, a random number, and a user identity identifier.

[0008] Preferably, the unique device identifier includes at least one of the client's browser fingerprint and network characteristics.

[0009] Preferably, the first information identifier is the contextual information associated with the authentication request, including the client address, request source information, and user agent information.

[0010] Preferably, step S3 includes: Step S31: The authentication server performs a one-way hash operation on the user agent information and encodes and generates hash parameters. Step S32, the authentication server constructs the permission payload of the permission token based on the authentication information and the hash parameters; Step S33: The authentication server combines the permission payload and the preset expiration time to form the permission token; In step S34, the authentication server sends the permission token to the business server.

[0011] Preferably, step S5 includes: Step S51: The client periodically sends polling requests to the live streaming resource server, and the polling requests contain the permission token. Step S52: The live streaming resource server obtains the second information identifier associated with the client based on the polling request, and sends the permission token and the second information identifier to the authentication server; Step S53, the authentication server determines whether the permission token has expired: If so, the authentication server sends the information that the permission token has expired to the client through the business server, and then returns to step S1; If not, proceed to step S54; Step S54: The authentication server parses the permission token to obtain the corresponding permission payload, and determines whether the permission payload matches the blacklist. If so, the authentication server sends a blocking request to the live streaming resource server, and the live streaming resource server rejects all the polling requests periodically sent by the corresponding client based on the blocking request; If not, proceed to step S55; Step S55: The authentication server verifies the second information identifier based on the parsed permission payload, generates a verification result after verification, and sends it to the live streaming resource server. Step S56: The live streaming resource server responds to the client based on the verification result. If the verification result is successful, the live streaming resource server sends the live streaming content to the client. If the verification result is that the verification fails, the live streaming resource server rejects the polling request sent by the client this time.

[0012] Preferably, the second information identifier includes: request address, client address, request source information, and user agent information.

[0013] Preferably, when the authentication server obtains the permission token sent by the live streaming resource server, it performs the following steps: Step A1: The authentication server performs anomaly detection on the permission token, and if it detects abnormal behavior in the client corresponding to the permission token, it proceeds to step A2. Step A2: Extract multidimensional information associated with the abnormal behavior, and update the blacklist based on the multidimensional information.

[0014] Preferably, the multidimensional information includes the device's unique identifier, the client address, and the user's identity identifier.

[0015] The above technical solution has the following advantages or beneficial effects: The client periodically polls the parameterized address based on the HLS streaming media transmission protocol to achieve multi-round authentication. The authentication information will not become invalid after a single authentication. The client generates an authorization token by combining the authentication request sent by the client with the preset expiration time. The authentication information consists of multi-dimensional information and is not easy to crack. Attached Figure Description

[0016] Figure 1 A schematic diagram of a method for seamless continuous authentication and anti-leeching in a preferred embodiment of the present invention; Figure 2 This is a schematic diagram of the permission token generation process in a preferred embodiment of the present invention; Figure 3 This is a schematic diagram illustrating the determination of whether an authorization token is valid in a preferred embodiment of the present invention. Figure 4 This is a schematic diagram of the blacklist dynamic update process in a preferred embodiment of the present invention; Detailed Implementation

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

[0018] Some of the block diagrams shown in the accompanying drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices. It should be noted that, unless otherwise specified, the embodiments and features described in these embodiments can be combined with each other.

[0019] The present invention will be further described below with reference to the accompanying drawings and specific embodiments, but this is not intended to limit the scope of the invention.

[0020] This invention provides a seamless, continuous authentication method for preventing hotlinking, applied to the HLS streaming media transmission protocol, such as... Figure 1 As shown, it includes: Step S1: The client sends an authentication request containing unique authentication information to the business server; Step S2: The business server obtains the first information identifier based on the authentication request, and includes the unique authentication information, the first information identifier, and the live streaming resource address associated with the authentication request in the authentication information and forwards it to the authentication server. Step S3: The authentication server generates an authorization token containing a preset expiration time based on the authentication information and returns the authorization token to the business server. In step S4, the business server concatenates the permission token as a parameter into the live stream resource address to form a parameterized address, and returns the parameterized address to the client. The client then requests the live stream resource from the live stream resource server based on the parameterized address. Step S5: Before the preset expiration time of the permission token expires, the client periodically sends polling requests to the live streaming resource server to obtain live streaming content from the live streaming resource server.

[0021] During implementation, viewers select live content through the client. Upon first clicking the URL link of the live room, they request live resources from the live resource server. After receiving the request, the client first sends an authentication request to the business server. The business server extracts the relevant content of the request and, together with the live address corresponding to the live content selected by the user, sends it as authentication information to the authentication server.

[0022] In this invention, the client connects to the business server and the live streaming resource server. The business server processes the requests sent by the client, and the live streaming resource server sends live streaming resources to the client. The authentication server connects to the business server and the live streaming resource server, receives information from the business server, and sends authentication results to the live streaming resource server for the live streaming resource server to determine whether to distribute live streaming resources.

[0023] Specifically, the business server has a pre-set live streaming resource address associated with the live streaming resource server. The client accesses the live streaming resource server through the live streaming resource address to obtain live streaming resources.

[0024] The client comes with a media playlist and internally stores an index file (.m3u8 format). The index file contains the live stream resource address, duration, encryption information, and other information pointing to the corresponding live stream.

[0025] It should be noted that this invention uses .m3u8 only as a storage format. The .m3u8 files in this invention include, but are not limited to, index files. Based on the HLS streaming media transmission protocol, the client polls .m3u8 format files.

[0026] Furthermore, the live streaming resources are real-time generated audio and video clips (.ts format), indexed by an index file. The live streaming content is composed of consecutive audio and video clips. By continuously updating the index file to download subsequent audio and video clips, a complete live stream is formed.

[0027] In step S4, the permission token is a text file containing text content. The live resource address in the index file and the text in the permission token are concatenated into a parameterized address (.m3u8 format) using text concatenation technology. The live resource address is used as the first part of the content, and the information in the permission token is used as the second part of the content. The two parts of the content are concatenated to form a text that is used as the content of the parameterized address.

[0028] As a preferred embodiment of this solution, the unique authentication information includes the client's unique device identifier, a random number, and the user's identity identifier.

[0029] Specifically, the client extracts the client's unique device identifier and user identity identifier ID through its built-in data collection framework, and generates a random number using a random number generator.

[0030] Furthermore, when sending an authentication request, a 16-bit string containing numbers and letters is generated as a random number. The device's unique identifier, the random number, and the ID are packaged together and sent to the business server as unique authentication information.

[0031] The randomized string, combined with a fixed device unique identifier and ID, can ensure the uniqueness of the authentication information. Basic information alone cannot bypass the random number determination.

[0032] As a preferred embodiment of this solution, the unique device identifier includes at least one of the client's browser fingerprint and network characteristics.

[0033] Specifically, the browser fingerprint includes the user's device hardware information, such as device model, number of processor cores, graphics card, memory, etc.; the name and version of the browser used by the user; the attributes and names of browser built-in plugins; a unique rendering image obtained by drawing with Canvas based on the device's graphics card and driver, which is then converted into a Base64 string; and network features, specifically WebRTC network features, including client network interface, network card information, latency, packet loss rate, etc.

[0034] In order to adapt to the different hardware of each device, the browser calls the corresponding Web API interface. Through the API interface, it can identify the GPU model, driver version, sound card model, driver version, and determine the number of cores based on the CPU's processing power. Based on the above information, the hardware information of the user's device is formed.

[0035] Furthermore, the client collects one or more parameters from the device's unique identifier, compresses them into a 32-bit string through a hash operation, and denoted as did.

[0036] Computer users collect the above parameters via JavaScript, while mobile users collect them via the App SDK.

[0037] As a preferred embodiment of this solution, the first information identifier is the contextual information associated with the authentication request, including the client address, request source information, and user agent information.

[0038] Specifically, the client address, request source information, and user agent information are denoted as IP address, Referer, and User-Agent, respectively. The business server extracts the context association information through built-in code.

[0039] Furthermore, the information in the first information identifier consists of attribute features inherent to each authentication request, used to characterize the network location, source entry point, and client identity of the authentication request sent by the client.

[0040] As a preferred embodiment of this solution, such as Figure 2 As shown, step S3 includes: Step S31: The authentication server performs a one-way hash operation on the user agent information and encodes it to generate hash parameters; Step S32: The authentication server constructs the permission payload of the permission token based on the authentication information and hash parameters; Step S33: The authentication server combines the permission payload and the preset expiration time to form a permission token; In step S34, the authentication server sends the authorization token to the business server.

[0041] Specifically, the authentication server performs an MD5 one-way hash operation on the User-Agent and generates a 22-bit hash parameter, denoted as ua_hash, using Base64URL encoding. The one-way hash operation can only obtain the ua_hash from the User-Agent; it cannot retrieve the User-Agent from the ua_hash, thus preventing hotlinkers from cracking the user agent's information.

[0042] Furthermore, the authentication server constructs the permission payload using the live stream resource address, did, ID, IP, random number, and ua_hash as parameters. The payload is in JSON format and is used to construct the token.

[0043] Furthermore, based on the permission payload and a preset expiration time, an permission token, hereinafter referred to as a JWT token, is generated using HMAC-SHA256 signature.

[0044] JWT tokens are an important means of verifying the legitimacy of authentication information sent by clients. The random number and ua_hash in the JWT token ensure that each token is unique and cannot be copied. Hotchain thieves need to obtain a large amount of information in the token and crack it.

[0045] As a preferred embodiment of this solution, such as Figure 3 As shown, step S5 includes: Step S51: The client periodically sends polling requests to the live streaming resource server, and the polling requests contain permission tokens. Step S52: The live streaming resource server obtains the second information identifier associated with the client based on the polling request, and sends the permission token and the second information identifier to the authentication server. Step S53: The authentication server determines whether the permission token has expired. If so, the authentication server sends the expired authorization token information to the client through the business server, and then returns to step S1; If not, proceed to step S54; Step S54: The authentication server parses the permission token to obtain the corresponding permission payload and determines whether the permission payload matches the blacklist. If so, the authentication server sends a blocking request to the live streaming resource server, and the live streaming resource server rejects all polling requests periodically sent by the corresponding client based on the blocking request; If not, proceed to step S55; Step S55: The authentication server verifies the second information identifier based on the parsed permission payload, generates a verification result after verification, and sends it to the live streaming resource server. Step S56: The live streaming resource server responds to the client based on the verification result. If the verification result is successful, the live streaming resource server sends the live streaming content to the client. If the verification result is unsuccessful, the live streaming resource server will reject the polling request sent by the client this time.

[0046] Specifically, the client polls the address with parameters, with a polling period of 2-6 seconds. Based on the live resource address in the address with parameters, the client points to the live resource server, which then extracts the JWT token and the second information identifier.

[0047] Furthermore, the client's polling operation is based on the HLS streaming media transmission protocol and is a built-in function of the client. It does not require modification of the client or installation of third-party plugins, which saves the cost of deploying additional functions while ensuring client security.

[0048] At the same time, since the JWT token is carried in the parameterized address, it will not become invalid due to a single poll, allowing a single JWT token to be used for repeated polling.

[0049] The anti-leeching method proposed in this solution is a seamless approach. The authentication server determines whether the JWT token has expired by comparing the timestamp in the system with the preset expiration time. When the JWT token is valid and about to expire, the authentication server sends this information to the business server. The business server then requests the authentication request from the client again in the backend. The client resends the authentication request starting from step S1, without notifying the user to manually send it again.

[0050] A blacklist is a structured list used to store prohibited entities as determined by the authentication server. In live streaming platforms, it is used to store information on users who violate regulations. The authentication server periodically accesses the blacklist to review the legitimacy of polling requests, filtering out a large number of illegal requests and preventing them from entering the next layer of verification, thus saving computing resources for the system.

[0051] On the one hand, when data of blacklisted users is detected in the payload, the authentication server considers the client that sent the polling request to be a violating user and rejects all subsequent requests from that client.

[0052] On the other hand, if a user is not on the blacklist but still fails to pass verification, it is considered that there may be problems such as network abnormality or data acquisition failure. In this case, the current polling request is rejected and the live streaming resource server waits for the next polling to reacquire the corresponding data.

[0053] Furthermore, after rejecting this polling request, the live streaming resource server returns to step S52 to reacquire the second information identifier.

[0054] The authentication server is also equipped with a log storage module. After authentication is completed, the authentication server sends the authentication result to the live streaming resource server. At the same time, it integrates the did, IP, ID, random number in the payload and the live streaming resource address, IP, Referer and User-Agent of this polling request into a structured log and inputs it into the log storage module.

[0055] The log storage module has a periodic cleanup function. It sets a retention time for each log entry and presets a retention time threshold. When the retention time exceeds the threshold, the module automatically deletes the log entry and releases storage space.

[0056] As a preferred embodiment of this solution, the second information identifier includes: request address, client address, request source information, and user agent information.

[0057] Specifically, the second information identifier contains information extracted in each poll, which is distinguished from the first information identifier of the authentication request.

[0058] Furthermore, the verification in step S55 also includes determining whether the live stream resource address requested in the current request matches the live stream resource address in the payload, and performing the same MD5 one-way hash operation as in the above steps on the currently extracted User-Agent and then performing Base64 URL encoding, comparing it with the ua_hash in the payload to see if they are consistent. If all parameters match, the verification is considered successful; if any parameters do not match, the verification is considered unsuccessful.

[0059] Specifically, the live resource address carried in the current polling request must be consistent with the path prefix of the live resource address carried in the payload.

[0060] As a preferred embodiment of this solution, such as Figure 4 As shown, when the authentication server receives the permission token sent by the live streaming resource server, it performs the following steps: Step A1: The authentication server performs anomaly detection on the authorization token, and if it detects abnormal behavior in the client corresponding to the authorization token, it proceeds to step A2. Step A2: Extract multidimensional information related to abnormal behavior and update the blacklist based on the multidimensional information.

[0061] Specifically, anomaly detection involves identifying hotlinking behavior, and the anomalies include: If a token is forged, such as an invalid JWT token signature, an abnormal expiration time, or a tampered payload field, it is considered a forged token. The authentication server will send the result to the live streaming resource server, which will then reject all subsequent requests containing that token. If the same random number appears in more than 5 different IPs or did within one minute during large-scale distribution, it will be considered as a leak of the live stream resource address, and the authentication server will add the associated did, IP, and ID to the blacklist. If the same IP or did sends more than 30 m3u8 requests within one minute, it will be considered as automated script theft, and the relevant IP and did will be added to the blacklist.

[0062] The authentication server has a built-in behavior analysis module, which monitors the occurrence and frequency of all parameters in a large number of polling requests based on the log storage module.

[0063] On one hand, the hotchain thief intercepts the JWT token and forges a token according to the token format. However, each token is composed of a unique token structure using a random number and ua_hash. Without the original data and generation method, it is impossible for the hotchain thief to forge a legitimate token. After the behavior analysis module identifies the forged token, it sends the result to the live streaming resource server through the authentication server. The live streaming resource server rejects all subsequent requests carrying the token based on the result.

[0064] On the other hand, hotlinkers usually steal the URLs of live streaming resources and publish these stolen URLs on unofficial private websites or platforms. A large number of external users bypass the official live streaming platforms and watch the live stream directly. After the authentication server identifies these users, it adds them to a blacklist and prohibits them from accessing the live stream.

[0065] On the other hand, hotlinkers use automated scripts to continuously send requests to the live streaming platform using accounts without real users, causing server resources to be heavily consumed, resulting in lag on the live streaming server and affecting the viewing experience of normal users. After the behavior analysis module identifies a large number of requests from the same user in a short period of time, it adds the user to the blacklist.

[0066] In this solution, the blacklist is stored in Redis, a high-efficiency key-value store with a response time of less than 1ms. It supports dynamic automatic addition and deletion operations, eliminating the need for manual operation of the blacklist.

[0067] As a preferred embodiment of this solution, the multidimensional information includes a unique device identifier, a client address, and a user identity identifier.

[0068] Specifically, the blacklist stores the did, IP, and ID of users who violate the rules, and updates the blacklist in real time based on the results of the authentication server's anomaly detection for subsequent queries.

[0069] Furthermore, a manual addition / removal unit is set up in conjunction with the blacklist. Users can report wrongful bans to customer service through the client and provide evidence of the wrongful ban. If customer service verifies that the ban is a wrongful ban, the backend blacklist can be directly modified through the manual addition / removal unit to remove the wrongly banned client information from the blacklist.

[0070] The above description is merely a preferred embodiment of the present invention and does not limit the implementation and protection scope of the present invention. Those skilled in the art should realize that any equivalent substitutions and obvious changes made based on the description and illustrations of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for a non-inductive continuous authentication anti-theft chain, applied to an HLS streaming media transmission protocol, characterized in that, The method comprises: Step S1, a client sends an authentication request containing unique authentication information to a service server; Step S2, the service server obtains a first information identifier based on the authentication request, and includes the unique authentication information, the first information identifier and a live streaming resource address associated with the authentication request in authentication information and forwards the authentication information to an authentication server; Step S3, the authentication server generates a permission token containing a preset expiration time based on the authentication information, and returns the permission token to the service server; Step S4, the service server splices the permission token as a parameter into the live streaming resource address to form a parameterized address, and returns the parameterized address to the client, and the client requests a live streaming resource from a live streaming resource server based on the parameterized address; Step S5, before the preset expiration time of the permission token expires, the client periodically sends a polling request to the live streaming resource server to obtain live streaming content from the live streaming resource server.

2. The method of claim 1, wherein the method further comprises: The unique authentication information includes a device unique identifier of the client, a random number and a user identity identifier.

3. The method of claim 2, wherein the method further comprises: The device unique identifier includes at least one of a browser fingerprint and network characteristics of the client.

4. The method of claim 1, wherein the method further comprises: The first information identifier is context associated information of the authentication request, including a client address, request source information and user agent information.

5. The method of claim 4, wherein the method further comprises: The step S3 comprises: Step S31, the authentication server performs one-way hash operation on the user agent information to generate a hash parameter through coding; Step S32, the authentication server constructs a permission payload of the permission token based on the authentication information and the hash parameter; Step S33, the authentication server forms the permission token by combining the permission payload and the preset expiration time; Step S34, the authentication server sends the permission token to the service server.

6. The method of claim 5, wherein the method further comprises: The step S5 comprises: Step S51, the client periodically sends a polling request to the live streaming resource server, and the polling request contains the permission token; Step S52, the live streaming resource server obtains a second information identifier associated with the client based on the polling request, and sends the permission token and the second information identifier to the authentication server; Step S53, the authentication server judges whether the permission token is expired: If yes, the authentication server sends information that the permission token is expired to the client through the service server, and then returns to step S1; If no, go to step S54; Step S54, the authentication server parses the permission token to obtain the corresponding permission payload, and judges whether the permission payload matches a blacklist: If yes, the authentication server sends a ban request to the live streaming resource server, and the live streaming resource server rejects all the polling requests periodically sent by the corresponding client based on the ban request; If no, go to step S55; Step S55, the authentication server verifies the second information identifier based on the parsed permission load, generates a verification result after verification, and sends the verification result to the live resource server; Step S56, the live resource server responds to the client according to the verification result: If the verification result is passed, the live resource server sends live content to the client; If the verification result is not passed, the live resource server rejects the polling request sent by the client this time.

7. The method of claim 6, wherein the method further comprises: The second information identifier includes: request address, client address, request source information and user agent information.

8. The method of claim 6, wherein the method further comprises: When the authentication server obtains the permission token sent by the live resource server, the following steps are performed: Step A1, the authentication server detects the permission token for abnormality, and turns to step A2 when it is detected that the client corresponding to the permission token has abnormal behavior; Step A2, extract multi-dimensional information associated with the abnormal behavior, and update the blacklist based on the multi-dimensional information.

9. The method of claim 8, wherein the method further comprises: The multi-dimensional information includes the device unique identifier, the client address and the user identity identifier.

Images