A token authentication-based anti-replay attack method and related device

Abstract

The application discloses a token authentication-based anti-replay attack method and related device. A client encrypts information obtained by splicing a token and a request sequence, carries the obtained encrypted information as a whole in a request message, and sends the request message to a server. The server verifies whether the token is valid based on a local request sequence set corresponding to the token and a request sequence obtained from the request message. If the token is invalid, the server determines that the request message is a replay attack for the token authentication, and rejects processing the request message, thereby improving the security of financial transactions in a bank or other financial scenario.

Description

Technical Field

[0001] This application relates to the field of security technology, and in particular to a method and related apparatus for preventing replay attacks based on token authentication. Background Technology

[0002] In computer networks and distributed systems, a token is typically a credential used to prove digital identity or authorize access, enabling authorization control over user access to services. Tokens offer advantages such as statelessness, protection against Cross-Site Request Forgery (CSRF) attacks, and single sign-on friendliness, leading to their widespread use in mobile and microservice authentication. However, tokens also pose risks of identity theft and misuse, potentially resulting in information leaks and API replay attacks. Furthermore, once issued, tokens cannot be actively invalidated by the server.

[0003] As cybersecurity issues in internet scenarios become increasingly severe, the design of interfaces to prevent replay attacks is becoming more and more important. Especially in financial scenarios such as banking, the design of interfaces to prevent replay attacks can increase interface security, prevent important financial transactions from being repeated, and thus enhance the security of important financial transactions.

[0004] However, current token-based replay attack prevention methods typically rely on client-server clock verification, which is unreliable. Therefore, there is an urgent need for a more reliable and secure token-based replay attack prevention method to improve interface security and thus enhance the security of financial transactions in banking and other financial settings. Summary of the Invention

[0005] To address the aforementioned technical issues, this application provides a token-based method and related apparatus for preventing replay attacks. By verifying the request message, which includes the token and the request sequence, through the request sequence corresponding to the token, it obtains a more reliable and accurate verification result for preventing replay attacks based on token authentication, thereby improving interface security.

[0006] To achieve the above objectives, the technical solution provided in this application is as follows:

[0007] Firstly, this application provides a token-based method for preventing replay attacks, applied to the server side, the method comprising:

[0008] Receive a first request message, the first request message including encrypted information;

[0009] The encrypted information is decrypted to obtain a first Token and a first request sequence, wherein the first request sequence is used to indicate the order of the first request messages;

[0010] If the request sequence set corresponding to the first request sequence and the first token indicates that the first token is invalid, then the first request message is refused to be processed. The request sequence set is used to store the request sequence in the valid request message for authentication of the first token.

[0011] Optionally, the first request sequence and the set of request sequences corresponding to the first token indicate that the first token is invalid, including:

[0012] The set of request sequences corresponding to the first Token includes the first request sequence;

[0013] Alternatively, the set of request sequences corresponding to the first token may not include the first request sequence, but the first request sequence may be less than or equal to the lower limit of the number of requests, which is determined based on the request concurrency threshold and the largest second request sequence in the current set of request sequences corresponding to the first token.

[0014] Optionally, the method further includes:

[0015] The first request message was determined to be a replay attack targeting the authentication of the first Token.

[0016] Optionally, the method further includes:

[0017] If the first request sequence and the set of request sequences corresponding to the first token indicate that the first token is valid, then in response to the processing of the first request message, the user information corresponding to the first token is obtained.

[0018] Optionally, the first request sequence and the set of request sequences corresponding to the first token indicate that the first token is valid, including:

[0019] The set of request sequences corresponding to the first Token is empty;

[0020] Alternatively, the set of request sequences corresponding to the first token does not include the first request sequence, and the first request sequence is greater than the lower limit of the number of requests, which is determined based on the request concurrency threshold and the largest second request sequence in the current set of request sequences corresponding to the first token.

[0021] Optionally, the method further includes:

[0022] Update the set of request sequences corresponding to the first Token based on the first request sequence.

[0023] Optionally,

[0024] If the set of request sequences corresponding to the first Token is empty, then updating the set of request sequences corresponding to the first Token based on the first request sequence includes:

[0025] The first request sequence is stored in the request sequence set corresponding to the first Token;

[0026] If the set of request sequences corresponding to the first Token does not include the first request sequence, and the first request sequence is greater than the lower limit of the number of requests, then updating the set of request sequences corresponding to the first Token based on the first request sequence includes:

[0027] If the number of request sequences included in the request sequence set corresponding to the first Token reaches the request concurrency threshold, then the smallest third request sequence in the current request sequence set corresponding to the first Token is removed, and the first request sequence is inserted into the request sequence set corresponding to the first Token.

[0028] Optionally, the request sequence set is stored using a Zset structure in Redis. The data in the Zset structure includes key-value pairs with a Token as the key and the request sequence corresponding to the Token as the value.

[0029] Secondly, this application also provides a token-based method for preventing replay attacks, applied to a client, the method comprising:

[0030] Generate a first request message, the first request message including first encrypted information, the first encrypted information being information obtained by the client encrypting the first token and the first request sequence, the first request sequence being used to indicate the order of the first request message;

[0031] The first request message is sent to the server so that the server processes the first request message based on the authentication result of the first token in the first request message.

[0032] Optionally, the method further includes:

[0033] Add one to the stored first request sequence to obtain the second request sequence;

[0034] A second request message is generated, the second request message including second encrypted information, the second encrypted information being information obtained by the client encrypting the first token and the second request sequence;

[0035] Send the second request message to the server.

[0036] Thirdly, this application also provides a token-based anti-replay attack device, applied to the server side, including:

[0037] A receiving unit is configured to receive a first request message, wherein the first request message includes encrypted information;

[0038] A decryption unit is used to decrypt the encrypted information to obtain a first token and a first request sequence, wherein the first request sequence is used to indicate the order of the first request messages;

[0039] The processing unit is configured to refuse to process the first request message if the first request sequence and the request sequence set corresponding to the first token indicate that the first token is invalid, wherein the request sequence set is used to store the request sequence in the valid request message for authentication of the first token.

[0040] Optionally, the first request sequence and the set of request sequences corresponding to the first token indicate that the first token is invalid, including:

[0041] The set of request sequences corresponding to the first Token includes the first request sequence;

[0042] Alternatively, the set of request sequences corresponding to the first token may not include the first request sequence, but the first request sequence may be less than or equal to the lower limit of the number of requests, which is determined based on the request concurrency threshold and the largest second request sequence in the current set of request sequences corresponding to the first token.

[0043] Optionally, the device further includes:

[0044] The determining unit is used to determine that the first request message is a replay attack targeting the first Token authentication.

[0045] Optionally, the device further includes:

[0046] The acquisition unit is configured to acquire user information corresponding to the first token in response to processing the first request message if the first request sequence and the request sequence set corresponding to the first token indicate that the first token is valid.

[0047] Optionally, the first request sequence and the set of request sequences corresponding to the first token indicate that the first token is valid, including:

[0048] The set of request sequences corresponding to the first Token is empty;

[0049] Alternatively, the set of request sequences corresponding to the first token does not include the first request sequence, and the first request sequence is greater than the lower limit of the number of requests, which is determined based on the request concurrency threshold and the largest second request sequence in the current set of request sequences corresponding to the first token.

[0050] Optionally, the device further includes:

[0051] The update unit is used to update the request sequence set corresponding to the first Token based on the first request sequence.

[0052] Optionally,

[0053] If the set of request sequences corresponding to the first Token is empty, then the update unit is specifically used for:

[0054] The first request sequence is stored in the request sequence set corresponding to the first Token;

[0055] If the set of request sequences corresponding to the first Token does not include the first request sequence, and the first request sequence is greater than the lower limit of the number of requests, then the update unit is specifically used for:

[0056] If the number of request sequences included in the request sequence set corresponding to the first Token reaches the request concurrency threshold, then the smallest third request sequence in the current request sequence set corresponding to the first Token is removed, and the first request sequence is inserted into the request sequence set corresponding to the first Token.

[0057] Optionally, the request sequence set is stored using a Zset structure in Redis. The data in the Zset structure includes key-value pairs with a Token as the key and the request sequence corresponding to the Token as the value.

[0058] It should be noted that the specific implementation method of the device and the technical effects achieved can be found in the relevant description of the method provided in the first aspect or any implementation method of the first aspect.

[0059] Fourthly, this application also provides a token-based anti-replay attack device, applied to a client, including:

[0060] A generation unit is configured to generate a first request message, the first request message including first encrypted information, the first encrypted information being information obtained by the client encrypting the first token and the first request sequence, the first request sequence being used to indicate the order of the first request message;

[0061] The sending unit is configured to send the first request message to the server so that the server processes the first request message based on the authentication result of the first token in the first request message.

[0062] Optionally, the device further includes:

[0063] A calculation unit is used to add one to the stored first request sequence to obtain a second request sequence;

[0064] The generation unit is further configured to generate a second request message, the second request message including second encrypted information, the second encrypted information being information obtained by the client encrypting the first Token and the second request sequence;

[0065] The sending unit is further configured to send the second request message to the server.

[0066] It should be noted that the specific implementation method of the device and the technical effects achieved can be found in the relevant description of the method provided in the second aspect or any implementation method of the second aspect.

[0067] Fifthly, this application also provides a communication system, which includes a client and a server;

[0068] The client is used to execute the methods provided by the second aspect or any implementation thereof.

[0069] The server is used to execute the methods provided by the first aspect or any implementation thereof.

[0070] Sixthly, this application also provides an electronic device, the electronic device comprising: a processor and a memory;

[0071] The memory is used to store instructions or programs;

[0072] The processor is configured to execute the instructions or programs in the memory to cause the electronic device to perform the methods provided by the first aspect, any implementation of the first aspect, the second aspect, or any implementation of the second aspect.

[0073] In a seventh aspect, this application also provides a readable medium storing instructions or programs that, when executed on a processor, cause the processor to perform the methods provided by the first aspect, any implementation of the first aspect, the second aspect, or any implementation of the second aspect.

[0074] Compared with the prior art, the embodiments of this application have at least the following advantages:

[0075] The technical solution provided in this application offers a method for preventing replay attacks based on token authentication. In this method, after the client generates a first request message including encrypted information, it sends the first request message to the server. Upon receiving the first request message, the server decrypts the encrypted information to obtain a first token and a first request sequence. The first request sequence indicates the order of the first request message. Then, if the server determines that the set of request sequences corresponding to the first token indicates that the first token is invalid, it can consider the first request message to be a replay attack targeting the first token authentication and thus refuse to process the first request message. The set of request sequences corresponding to the first token is used to store the request sequences from valid request messages targeting the first token authentication. In this way, the client encrypts the information concatenated with the token and the request sequence, and sends the encrypted information as a whole in the request message to the server. The server decrypts the token and the request sequence, and verifies the validity of the token based on the local set of request sequences corresponding to the token and the request sequence obtained in the request message. If the token is invalid, the server refuses to process the request message, thus obtaining a more reliable and accurate token-based authentication anti-replay attack verification result. This effectively overcomes the problem of unreliable verification due to the unreliability of timestamps in timestamp-based replay attacks on token-authenticated interfaces, improving interface security and thereby enhancing the security of financial transactions in banking and other financial scenarios. Attached Figure Description

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

[0077] Figure 1 A flowchart illustrating a token-based method for preventing replay attacks, provided in an embodiment of this application;

[0078] Figure 2 A flowchart illustrating an example of the method provided in this application embodiment;

[0079] Figure 3 A schematic diagram of the structure of a token-based anti-replay attack device 300 provided in an embodiment of this application;

[0080] Figure 4 A schematic diagram of a token-based anti-replay attack device 400 provided in this application embodiment;

[0081] Figure 5 A schematic diagram of the structure of a communication system 500 provided in an embodiment of this application;

[0082] Figure 6 This is a schematic diagram of the structure of an electronic device 600 provided in an embodiment of this application. Detailed Implementation

[0083] Traditional tokens are used to maintain session information between clients and servers, but they are susceptible to theft. Furthermore, once a token is issued, the server cannot actively invalidate it. Interface replay attack prevention designs can increase interface security and prevent the re-extraction of important data, such as critical financial transactions, thus enhancing the security of sensitive data. However, current interface replay attack prevention designs suffer from problems such as high memory consumption, low efficiency, and inaccurate timeliness.

[0084] The current API replay attack prevention process is typically as follows: S11, the client adds a timestamp to the token; S12, the client sends a request including the token to the server; S13, the server's filter obtains the corresponding timestamp by parsing the token; S14, the server compares the obtained timestamp with the server's clock. If the time interval between the timestamp and the server's clock exceeds a specified time window, the request is blocked; if the time interval is within the specified time window, the request is allowed. This API replay attack prevention mechanism, using a token combined with a timestamp, can verify user identity within a specified time, preventing token reuse. Theoretically, it can effectively improve API security within a specified time. Furthermore, the token can be set to be valid only within a specified time window and supports digital signatures, encryption, and other methods to ensure security during transmission, making it widely used in the modern internet.

[0085] Alternatively, as one of the API anti-replay attack mechanisms that combines tokens and timestamps, there is also a method to prevent replay attacks based on timestamps for API interfaces. In this method, a unique time sequence code is introduced to mark the request based on the timestamp, and the repeated status of the interface is recorded by compressing the binary status of the status code. Only two sets of data need to be cached, namely the status code and the latest time sequence code. Normal requests and suspected abnormal requests are treated differently. Normal request interfaces are optimized and accelerated without verification, and the status is maintained by left shifting the binary status bits of the status code.

[0086] However, all of the above solutions involve timestamps. Using timestamps to determine if a request is replayed can lead to discrepancies between the server-side clock and the timestamp generated by the client. Attackers could tamper with the client-generated timestamp to achieve their goal of replaying the attack. Furthermore, in the login process of these solutions, the client generates a timestamp, stores it in a token, and sends it to the server. The server then verifies whether the timestamp is within the specified time window for a replay attack (also known as the replay attack window). Issues such as clock synchronization problems, clock backtracking attacks, and time zone differences can arise, potentially causing server-side timestamp verification to fail in extreme cases.

[0087] In summary, the current token-timestamp-based API anti-replay attack mechanisms have the following shortcomings: First, clock synchronization issues. This mechanism relies on the synchronization of clocks across various system components. If the server and client clocks are not synchronized, timestamp verification may fail, leading to a false positive for a replay attack. Second, clock backtracking attacks. Attackers may attempt to bypass timestamp verification by altering their local system clock. Preventing clock backtracking attacks requires a secure clock synchronization mechanism, and the server may need to allow for a certain degree of clock drift. Third, replay attack window management issues. Setting the timestamp validity period requires a balance between security and system tolerance. If the validity period is set too short, the system may be susceptible to false positives; if it is set too long, it may increase the risk of replay attacks. Setting a reasonable replay attack window is a challenge. Fourth, time zone differences. If system interactions involve different time zones, time zone differences may cause problems with timestamp parsing.

[0088] Based on this, this application provides a method for preventing replay attacks based on token authentication. In this method, after the client generates a first request message including encrypted information, it sends the first request message to the server. Upon receiving the first request message, the server decrypts the encrypted information to obtain a first token and a first request sequence. The first request sequence indicates the order of the first request message. Then, if the server determines that the set of request sequences corresponding to the first token indicates that the first token is invalid, it can consider the first request message to be a replay attack targeting the first token authentication and thus refuse to process the first request message. The set of request sequences corresponding to the first token is used to store the request sequences from valid request messages targeting the first token authentication.

[0089] In this way, the client encrypts the information concatenated with the token and the request sequence, and sends the encrypted information as a whole in the request message to the server. The server decrypts the token and the request sequence, and verifies the validity of the token based on the local set of request sequences corresponding to the token and the request sequence obtained in the request message. If the token is invalid, the server refuses to process the request message, thus obtaining a more reliable and accurate token-based authentication anti-replay attack verification result. This effectively overcomes the problem of unreliable verification due to the unreliability of timestamps in timestamp-based replay attacks on token-authenticated interfaces, improving interface security and thereby enhancing the security of financial transactions in banking and other financial scenarios.

[0090] It should be noted that the entity implementing the token-based authentication anti-replay attack method can be the communication system provided in the embodiments of this application. Specifically, the entity executing the steps implemented by the server in the token-based authentication anti-replay attack method can be the server of the communication system, and the entity executing the steps implemented by the client in the token-based authentication anti-replay attack method can be the client of the communication system. Alternatively, the entity implementing the token-based authentication anti-replay attack method can be the token-based authentication anti-replay attack device provided in the embodiments of this application. Specifically, the entity executing the steps implemented by the server in the token-based authentication anti-replay attack method can be the token-based authentication anti-replay attack device 300 described below, and the entity executing the steps implemented by the client in the token-based authentication anti-replay attack method can be the token-based authentication anti-replay attack device 400 described below.

[0091] It should be noted that, in the embodiments of this application, the process executed by the client can be considered a separate embodiment with its own specific technical effects; similarly, the process executed by the server can be considered a separate embodiment with its own specific technical effects. The execution of a separate embodiment by the client does not affect the implementation of a separate embodiment by the server, and vice versa.

[0092] The following section introduces and explains some technical terms involved in the embodiments of this application.

[0093] A token, in computer networks and distributed systems, typically refers to a credential that proves digital identity or authorizes access, enabling authorization control over user access to services.

[0094] In computer networks or distributed systems, a client typically refers to the process or application that initiates a request. Clients can be deployed on various user devices, such as personal computers (PCs), mobile phones, tablets, etc.

[0095] The server is a process or application that provides computing resources, storage, and service access. It undertakes the core business logic of the system and provides services to a large number of clients through standard interfaces.

[0096] Asymmetric encryption is an important encryption mechanism. The key is divided into a public key and a private key. Generally, the public key is used for encryption and the private key is used for decryption.

[0097] Microservices architecture is a distributed software architecture pattern that breaks down a complex system into multiple small services, each responsible for implementing an independent business function.

[0098] Figure 1 This is a flowchart illustrating a token-based anti-replay attack method provided in an embodiment of this application. The method is described from the perspective of client-server interaction. The client can correspond to client 520 in the token-based anti-replay attack device 400 or communication system 500 described below, and the server can correspond to server 510 in the token-based anti-replay attack device 300 or communication system 500 described below.

[0099] like Figure 1 As shown, the method may include, for example, the following steps S101 to S105:

[0100] S101, the client generates a first request message, which includes first encrypted information. The first encrypted information is information obtained by the client encrypting the first token and the first request sequence. The first request sequence is used to indicate the order of the first request message.

[0101] A request sequence can be understood as a string that indicates the order of request messages. By concatenating the token and the request sequence and encrypting the concatenated content, the encrypted content is carried in the request for transmission. This ensures the security of the valid information in the request message because: first, an encryption algorithm is used; second, even if the encryption is cracked, the concatenation of the token and the request sequence will confuse the attacker, making it impossible for them to accurately obtain the token.

[0102] Prior to S101, the method may also include: the client generating a first request sequence corresponding to the first token.

[0103] As an example, if the client is using the first token for token authentication for the first time, an initial request sequence can be randomly generated, denoted as the first request sequence.

[0104] It should be noted that, in order to update the request sequence regularly based on the initial request sequence, so that the updated request sequence can always serve as a valid credential for the request message in the token authentication, that is, the server can accurately verify the validity of the request message based on the changing pattern of the request sequence in the received request message, the client can save the request sequence used each time. For example, the client can save the first request sequence to local storage.

[0105] As another example, if the client is not using the first token for token authentication for the first time, then the client generating the first request sequence may include: first, the client obtaining the second request sequence used last time; receiving, the client obtaining the first request sequence based on the second request sequence.

[0106] If the client saves the last used first request sequence to LocalStorage, then the client can retrieve the last used second request sequence by retrieving the second request sequence corresponding to the first token from LocalStorage.

[0107] In this process, the client obtains the first request sequence based on the second request sequence. This can be achieved by updating the second request sequence to the first request sequence according to the rules for updating request sequences. For example, if the rule for updating request sequences is to increment the request sequence by one, then the client can obtain the first request sequence by incrementing the second request sequence by one. This incremental request sequence approach effectively prevents direct access from Application Programming Interface (API) access tools such as Postman, enhancing the security of APIs against replay attacks. Furthermore, it disables the replay attack module of the conventional penetration testing tool Burp Suite, significantly increasing the difficulty of penetration testing and contributing to the maintenance of API security within the system.

[0108] It should be noted that in this example, after generating the first request sequence, the client can update the saved second request sequence corresponding to the first token to the first request sequence.

[0109] In some implementations, after the client generates the first request sequence, step S101 may include: the client generating a first request message based on the first token and the first request sequence. As an example, the client may concatenate the first token and the first request sequence, encrypt the concatenated information to obtain first encrypted information, and then carry the first encrypted information in the request message to generate the first request message. The concatenation method of the first token and the first request sequence can be, for example, appending the first request sequence to the first token (or, as a suffix to the first token). Encryption of the concatenated information can use an asymmetric encryption algorithm, such as SM2, which is an elliptic curve public-key cryptography algorithm. The first encrypted information can be carried in the request header of the first request message. It should be noted that the embodiments of this application provide illustrative examples of the concatenation method of the first token and the first request sequence, the encryption algorithm used for the concatenated information, and the method of carrying the first encrypted information in the first request message, without making specific limitations.

[0110] S102, the client sends the first request message to the server.

[0111] S103, the server receives the first request message.

[0112] The server can process the first request message based on the authentication result of the first token in the first request message.

[0113] In some implementations, after S101, the method may further include: the client incrementing the stored first request sequence by one to obtain a third request sequence; the client generating a second request message, the second request message including second encrypted information, which is information obtained by the client encrypting the first token and the third request sequence; and the client sending the second request message to the server. The steps performed by the client and server in this implementation can be found in [reference needed]. Figure 1 The relevant descriptions of the embodiments shown will not be repeated here.

[0114] S104, the server decrypts the first encrypted information to obtain the first token and the first request sequence.

[0115] In practice, after the server receives the first request message, the TokenFilter in the server parses and processes the first request message, that is, the TokenFilter executes S104 and S105.

[0116] As an example, S104 may include: TokenFilter obtaining first encrypted information from the first request message; TokenFilter decrypting the first encrypted information to obtain the first Token and the first request sequence.

[0117] S105, if the request sequence set corresponding to the first request sequence and the first token indicates that the first token is invalid, the server refuses to process the first request message. The request sequence set is used to store the request sequence in the valid request message for authentication of the first token.

[0118] The invalid first token can be understood as the invalid first token in the first request message.

[0119] It's worth noting that the server can store the request sequence set corresponding to each token. This request sequence set can be stored using a Redis Zset structure. A Zset structure consists of key-value pairs where the token is the key and the corresponding request sequence is the value. Using a Redis Zset structure significantly optimizes the storage space for the request sequence set. Furthermore, a sliding window can be maintained with a request concurrency threshold (e.g., 10) to ensure that each user's request sequence set can accommodate a maximum of that threshold, eliminating the need to store all user request sequences. When the number of request sequences reaches the threshold, the smallest request sequence is automatically removed, and a new one is inserted. This ensures the validity of the request sequences while maximizing storage space optimization.

[0120] After S104 and before S105, the server can use the first token as the key to query the set of request sequences corresponding to the first token.

[0121] In S105, the first request sequence and the set of request sequences corresponding to the first token indicate that the first token is invalid. This can be understood as the server determining that the first request message is a replay attack targeting the authentication of the first token. The first request sequence and the set of request sequences corresponding to the first token indicating that the first token is invalid can correspond to two scenarios: Scenario 1, the set of request sequences corresponding to the first token includes the first request sequence; Scenario 2, the set of request sequences corresponding to the first token does not include the first request sequence, but the first request sequence is less than or equal to the lower limit of the request quantity. The lower limit of the request quantity is determined based on the request concurrency threshold and the largest fourth request sequence in the current set of request sequences corresponding to the first token. Assuming the request concurrency threshold is 10, and the largest fourth request sequence in the current set of request sequences corresponding to the first token is 1015, then the lower limit of the request quantity is (1015-10) = 1005. If the first request sequence is 999, since 999 is less than 1005, the first token in the first request message is invalid.

[0122] In scenario one, it can be understood that the server has already received a request message for the first token, and the request sequence in that request message is also the first request sequence. In this case, the first request message for authentication of the first token, which includes the first request sequence, can be considered as an interface replay attack based on the first token authentication.

[0123] Scenario 2 can be understood as the server determining, based on the lower limit of the first token's request, that the first request sequence belongs to the request sequence of the first token that was generated a long time ago and has expired. If the server receives the first request message that includes the first request sequence and is for authentication of the first token at such a time, it can be considered as an interface replay attack based on the first token authentication.

[0124] In some other implementations, the method may further include: if the first request sequence and the set of request sequences corresponding to the first token indicate that the first token is valid, then in response to processing the first request message, obtaining the user information corresponding to the first token.

[0125] The first request sequence and the set of request sequences corresponding to the first token indicate that the first token is valid. This can be understood as the server determining that the first request message is a legitimate request authenticated using the first token. The first request sequence and the set of request sequences corresponding to the first token indicating the validity of the first token can correspond to two scenarios: Scenario 3, the set of request sequences corresponding to the first token is empty; Scenario 4, the set of request sequences corresponding to the first token does not include the first request sequence, and the first request sequence is greater than the lower limit of the request quantity. Taking a lower limit of 1005 requests as an example, if the first request sequence is 1010, because 1010 is greater than 1005, the first token in the first request message is valid.

[0126] In scenario three, it can be understood that the server has not yet received any request messages for the first token. Therefore, the first request message, which includes the first request sequence and is for authentication of the first token, cannot be considered as an interface replay attack based on the first token authentication and must be a legitimate message.

[0127] In scenario four, it can be understood that the server determines, based on the lower limit of the first token's request, that the first request sequence belongs to the request sequence of the first token with a relatively short generation time and is still within the validity period. If the server receives the first request message that includes the first request sequence and is for authentication of the first token at such a time, it can be considered a legitimate message.

[0128] In this implementation, after confirming the validity of the first token in the first request message, in addition to obtaining the user information corresponding to the first token, the server can also update the request sequence set corresponding to the first token based on the first request sequence. This makes the subsequent verification of the first token authentication against replay attacks more accurate.

[0129] In the third scenario, the server updates the request sequence set corresponding to the first Token based on the first request sequence, which may include: storing the first request sequence in the request sequence set corresponding to the first Token.

[0130] In scenario four, the server updates the request sequence set corresponding to the first token based on the first request sequence. This can include: if the number of request sequences included in the request sequence set corresponding to the first token reaches the request concurrency threshold, then remove the smallest fifth request sequence from the current request sequence set corresponding to the first token, and insert the first request sequence into the request sequence set corresponding to the first token. This uses a sliding window approach to maintain the validity of the request sequence. While conventional hash storage structures require storing each request sequence in memory, using a skip list structure (such as Zset) ensures both query efficiency and space control.

[0131] The token offers high security. The token returned by the server is concatenated with a random string and then asymmetrically encrypted using a public key. The server decrypts it using its private key. Throughout the interaction, even if a third party obtains the request message, they cannot identify the specific information. Simultaneously, the server maintains request records for the token, ensuring that even if the message is intercepted, the token cannot be reused, thus preventing the possibility of the authentication token being stolen.

[0132] Understandably, concatenating the request sequence with a token and encrypting it using SM2 provides a secure, obfuscated encryption method that ensures the security of the request message, including the token, during transmission. Furthermore, the server maintains a record of requests corresponding to each token (i.e., a set of request sequences) for authentication. If a third party captures the request message and sends a corresponding request message, the server decrypts the message and verifies whether the random string (i.e., the request sequence) concatenated with the token has already been used. If it has, the service is rejected, ensuring that the request message cannot be reused even after being captured. Moreover, the use of a Zset structure from Redis significantly reduces the server-side storage space required for the request sequence set.

[0133] As can be seen, in this embodiment, the client uses asymmetric encryption such as SM2 to obfuscate information including the token and request sequence, while the server uses a Zset structure in Redis to maintain a set of request sequences with a fixed step size. This detects whether the request sequence corresponding to each token has already been initiated, thereby preventing duplicate requests using the same token. Furthermore, in this embodiment, the server uses a unified TokenFilter to parse and verify the token in each request message, ensuring the consistency and validity of the verification results. This method can provide an effective response to replay attacks on token-based authentication interfaces in critical scenarios such as banking and finance, improving network security.

[0134] To make the description of the methods provided in the embodiments of this application clearer and more complete, the following is in conjunction with... Figure 2Let me illustrate this with an example.

[0135] like Figure 2 As shown, the server's processing flow for the received request message 1 may include:

[0136] S21, decrypt the encrypted information 1 in request message 1 to obtain Token 1 and request sequence 1.

[0137] S22, use Token 1 as the key to find the corresponding request sequence set 1.

[0138] S23, determine whether the request sequence set 1 is empty. If it is, execute S24 to S25; otherwise, execute S26.

[0139] S24, store request sequence 1 into request sequence set 1.

[0140] S25, find the user information corresponding to Token 1.

[0141] S26, determine whether request sequence 1 exists in request sequence set 1. If it does, execute S27; otherwise, execute S28.

[0142] S27, Request message 1 is refused.

[0143] S28, determine whether request sequence 1 is not greater than the lower limit of the number of requests. If it is, execute S27; otherwise, execute S25 and S29.

[0144] S29, determine whether the number of request sequences in request sequence set 1 has reached the request concurrency threshold. If yes, execute S30; otherwise, execute S24.

[0145] S30, remove the smallest request sequence from request sequence set 1, and return to execute S24.

[0146] This processing logic can improve the security and reliability of token-based authentication request messages.

[0147] Accordingly, this application also provides a token-based anti-replay attack device 300, such as... Figure 3 As shown. This device 300 is applied to the server side. This device 300 can, for example, correspond to the following... Figure 5 The server 510 in the middle can also correspond to Figure 6 The illustrated electronic device 600 is used as a server. This device 300 may include:

[0148] Receiving unit 301 is configured to receive a first request message, wherein the first request message includes encrypted information;

[0149] The decryption unit 302 is used to decrypt the encrypted information to obtain a first token and a first request sequence, wherein the first request sequence is used to indicate the order of the first request messages;

[0150] The processing unit 303 is configured to refuse to process the first request message if the first request sequence and the request sequence set corresponding to the first token indicate that the first token is invalid, wherein the request sequence set is used to store the request sequence in the valid request message for authentication of the first token.

[0151] Optionally, the first request sequence and the set of request sequences corresponding to the first token indicate that the first token is invalid, including:

[0152] The set of request sequences corresponding to the first Token includes the first request sequence;

[0153] Alternatively, the set of request sequences corresponding to the first token may not include the first request sequence, but the first request sequence may be less than or equal to the lower limit of the number of requests, which is determined based on the request concurrency threshold and the largest second request sequence in the current set of request sequences corresponding to the first token.

[0154] Optionally, the device 300 further includes:

[0155] The determining unit is used to determine that the first request message is a replay attack targeting the first Token authentication.

[0156] Optionally, the device 300 further includes:

[0157] The acquisition unit is configured to acquire user information corresponding to the first token in response to processing the first request message if the first request sequence and the request sequence set corresponding to the first token indicate that the first token is valid.

[0158] Optionally, the first request sequence and the set of request sequences corresponding to the first token indicate that the first token is valid, including:

[0159] The set of request sequences corresponding to the first Token is empty;

[0160] Alternatively, the set of request sequences corresponding to the first token does not include the first request sequence, and the first request sequence is greater than the lower limit of the number of requests, which is determined based on the request concurrency threshold and the largest second request sequence in the current set of request sequences corresponding to the first token.

[0161] Optionally, the device 300 further includes:

[0162] The update unit is used to update the request sequence set corresponding to the first Token based on the first request sequence.

[0163] Optionally,

[0164] If the set of request sequences corresponding to the first Token is empty, then the update unit is specifically used for:

[0165] The first request sequence is stored in the request sequence set corresponding to the first Token;

[0166] If the set of request sequences corresponding to the first Token does not include the first request sequence, and the first request sequence is greater than the lower limit of the number of requests, then the update unit is specifically used for:

[0167] If the number of request sequences included in the request sequence set corresponding to the first Token reaches the request concurrency threshold, then the smallest third request sequence in the current request sequence set corresponding to the first Token is removed, and the first request sequence is inserted into the request sequence set corresponding to the first Token.

[0168] Optionally, the request sequence set is stored using a Zset structure in Redis. The data in the Zset structure includes key-value pairs with a Token as the key and the request sequence corresponding to the Token as the value.

[0169] It should be noted that the specific implementation method and technical effects achieved by the device 300 can be found in [reference needed]. Figure 1 The method shown includes relevant descriptions of the steps involved in the server-side implementation.

[0170] Accordingly, this application also provides a token-based anti-replay attack device 400, such as... Figure 4 As shown. This device 400 is applied to a client. This device 400 can, for example, correspond to the following... Figure 5 Client 520 in the middle can also correspond to Figure 6 The illustrated electronic device 600 is used as a client. The device 400 may include:

[0171] The generation unit 401 is used to generate a first request message, the first request message including first encrypted information, the first encrypted information being information obtained by the client encrypting the first token and the first request sequence, the first request sequence being used to indicate the order of the first request message;

[0172] The sending unit 402 is used to send the first request message to the server so that the server processes the first request message based on the authentication result of the first token in the first request message.

[0173] Optionally, the device 400 further includes:

[0174] A calculation unit is used to add one to the stored first request sequence to obtain a second request sequence;

[0175] The generation unit 401 is further configured to generate a second request message, the second request message including second encrypted information, the second encrypted information being information obtained by the client encrypting the first Token and the second request sequence;

[0176] The sending unit 402 is further configured to send the second request message to the server.

[0177] It should be noted that the specific implementation method and technical effects achieved by the device 400 can be found in [reference needed]. Figure 1 The method shown includes relevant descriptions of the steps involved in client-side implementation.

[0178] Furthermore, embodiments of this application also provide a communication system 500, such as... Figure 5 As shown. The communication system 500 may include a client 520 and a server 510. The server 510 is used to execute any implementation of the method provided in this application embodiment; the client 520 is used to execute any implementation of the method provided in this application embodiment.

[0179] In addition, this application also provides an electronic device, the device including a processor and a memory: the memory is used to store instructions or computer programs; the processor is used to execute the instructions or computer programs in the memory so that the electronic device performs any implementation of the method provided in this application.

[0180] See Figure 6 This document illustrates a structural schematic diagram of an electronic device 600 suitable for implementing embodiments of the present disclosure. The terminal devices in these embodiments may include, but are not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 6 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0181] like Figure 6 As shown, electronic device 600 may include a processing device (e.g., a central processing unit, a graphics processor, etc.) 601, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 602 or a program loaded from storage device 608 into random access memory (RAM) 603. RAM 603 also stores various programs and data required for the operation of electronic device 600. Processing device 601, ROM 602, and RAM 603 are interconnected via bus 604. Input / output (I / O) interface 605 is also connected to bus 604.

[0182] Typically, the following devices can be connected to I / O interface 605: input devices 606 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 607 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 608 including, for example, magnetic tapes, hard disks, etc.; and communication devices 609. Communication device 609 allows electronic device 600 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 6 An electronic device 600 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0183] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 609, or installed from a storage device 608, or installed from a ROM 602. When the computer program is executed by the processing device 601, it performs the functions defined in the methods of embodiments of this disclosure.

[0184] The electronic device provided in this embodiment belongs to the same inventive concept as the method provided in the above embodiments. Technical details not described in detail in this embodiment can be found in the above embodiments, and this embodiment has the same beneficial effects as the above embodiments.

[0185] This application also provides a computer-readable medium storing instructions or a computer program that, when executed on a device, causes the device to perform any implementation of the method provided in this application.

[0186] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0187] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0188] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0189] The aforementioned computer-readable medium carries one or more programs, which, when executed by the electronic device, enable the electronic device to perform the aforementioned methods.

[0190] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including but not limited to object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0191] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0192] The units described in the embodiments of this disclosure can be implemented in software or hardware. The names of the units / modules do not necessarily limit the specific unit itself.

[0193] The functions described above in this document can be performed, at least in part, by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application Standard Products (ASSPs), System-on-Chip (SoCs), Complex Programmable Logic Devices (CPLDs), and so on.

[0194] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0195] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the systems or apparatus disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple, and relevant parts can be referred to the method section.

[0196] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0197] It should also be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0198] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0199] It should be noted that this application embodiment does not involve sensitive user information; all user-related information is obtained, used, and determined only after user authorization. In one example, before obtaining user-related information, the corresponding interface displays a prompt regarding authorization for data acquisition and use. This prompt informs the user, in accordance with relevant laws and regulations, of the type, scope of use, and usage scenarios of the personal information involved in this disclosure through an appropriate means, so that the user can determine whether to agree to the authorization based on the prompt. It is understood that the above notification and user authorization acquisition process is merely illustrative and does not constitute a limitation on the implementation of this disclosure. Other methods that comply with relevant laws and regulations can also be applied to the implementation of this disclosure.

[0200] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for preventing replay attacks based on token authentication, characterized in that, Applied to the server side, the method includes: Receive a first request message, the first request message including encrypted information; The encrypted information is decrypted to obtain a first token and a first request sequence, wherein the first request sequence is used to indicate the order of the first request messages; If the request sequence set corresponding to the first request sequence and the first token indicates that the first token is invalid, then the first request message is refused to be processed. The request sequence set is used to store the request sequence in the valid request message for authentication of the first token. If the first request sequence and the request sequence set corresponding to the first token indicate that the first token is valid, then update the request sequence set corresponding to the first token based on the first request sequence; Wherein, the first request sequence and the request sequence set corresponding to the first token indicate that the first token is valid, including: the request sequence set corresponding to the first token does not include the first request sequence, and the first request sequence is greater than the lower limit of the number of requests, the lower limit of the number of requests is determined based on the request concurrency threshold and the largest second request sequence in the current request sequence set corresponding to the first token; if the request sequence set corresponding to the first token does not include the first request sequence, and the first request sequence is greater than the lower limit of the number of requests, then updating the request sequence set corresponding to the first token based on the first request sequence includes: if the number of request sequences included in the request sequence set corresponding to the first token does not reach the request concurrency threshold, storing the first request sequence in the request sequence set corresponding to the first token; if the number of request sequences included in the request sequence set corresponding to the first token reaches the request concurrency threshold, removing the smallest third request sequence in the current request sequence set corresponding to the first token, and inserting the first request sequence into the request sequence set corresponding to the first token.

2. The method according to claim 1, characterized in that, The first request sequence and the set of request sequences corresponding to the first token indicate that the first token is invalid, including: The set of request sequences corresponding to the first Token includes the first request sequence; Alternatively, the set of request sequences corresponding to the first Token does not include the first request sequence, but the first request sequence is less than or equal to the lower limit of the number of requests.

3. The method according to claim 1, characterized in that, The method further includes: The first request message was determined to be a replay attack targeting the authentication of the first Token.

4. The method according to claim 1, characterized in that, The method further includes: If the first request sequence and the set of request sequences corresponding to the first token indicate that the first token is valid, then in response to the processing of the first request message, the user information corresponding to the first token is obtained.

5. The method according to claim 4, characterized in that, The first request sequence and the set of request sequences corresponding to the first token indicate that the first token is valid, including: The set of request sequences corresponding to the first Token is empty.

6. The method according to claim 1, characterized in that, If the set of request sequences corresponding to the first Token is empty, then updating the set of request sequences corresponding to the first Token based on the first request sequence includes: The first request sequence is stored in the request sequence set corresponding to the first Token.

7. The method according to any one of claims 1-6, characterized in that, The request sequence set is stored using a Zset structure in Redis. The data in the Zset structure includes key-value pairs with a Token as the key and the request sequence corresponding to the Token as the value.

8. A method for preventing replay attacks based on token authentication, characterized in that, Applied to a client, the method includes: Generate a first request message, the first request message including first encrypted information, the first encrypted information being information obtained by the client encrypting the first token and the first request sequence, the first request sequence being used to indicate the order of the first request message; Send the first request message to the server so that the server can authenticate and process the first Token in the first request message based on the method described in any one of claims 1-7; Add one to the stored first request sequence to obtain the second request sequence; A second request message is generated, the second request message including second encrypted information, the second encrypted information being information obtained by the client encrypting the first token and the second request sequence; Send the second request message to the server.

Images