Dynamic token generation method and apparatus, electronic device, and storage medium

Abstract

The application provides a method and device for dynamically generating a token, an electronic device and a storage medium. The application determines a first target scheme of a total code for generating a token each time according to a preset mode in response to a preset trigger condition being met, generates a first session key based on a token version number and a sub-scheme identifier of a plurality of target sub-schemes in the first target scheme, assigns a first session key identifier to the first session key, stores a correspondence between the first session key and the first session key identifier, respectively acquires a sub-code corresponding to each target sub-scheme in the plurality of target sub-schemes including a plurality of sub-scheme, and thereby acquires a total code for generating a token this time, and sends the total code and the first session key identifier to a client. In this way, by using a large number of token generation schemes and dynamically adjusting the token generation scheme strategy, the difficulty of reverse analysis of the code for generating the token by an attacker is greatly increased, and the security of the token is improved.

Description

[Technical Field]

[0001] This application relates to network security technology, and more particularly to a method and apparatus for dynamically generating tokens, electronic devices, and storage media. [Background Technology]

[0002] With the development of internet technology, the amount of data and resources stored and provided through the network is increasing, and the resulting cybersecurity issues are becoming increasingly serious. Currently, cybersecurity threats are growing, and various applications urgently need better technologies to ensure security. Therefore, protecting the security of data and resources stored on the network is becoming increasingly important.

[0003] The common approach involves the client generating a token as a temporary key and sending it to the server. This token acts like a username and password, determining whether the request is allowed and identifying the user making the request. It allows the client to access network data and system resources without providing a password or other credentials. The server verifies the token's validity to determine if the client is authorized to access network data and system resources.

[0004] In the process of developing this application, the inventors discovered that the code for generating tokens on the client side is easily reverse-engineered and thoroughly analyzed by attackers. Subsequently, attackers can use automated tools to automatically generate tokens using this code and send them to the server. The server has difficulty distinguishing whether the received token was sent by a user with access rights through the client or by an attacker. As a result, attackers can use the token to access network data and system resources, or further tamper with network data and system resources or implant viruses, which may cause great losses to users. [Summary of the Invention]

[0005] This application provides a method, apparatus, electronic device, and storage medium for dynamically generating tokens, thereby increasing the difficulty for attackers to reverse engineer the code used to generate the tokens, and thus improving the security of the tokens.

[0006] One aspect of this application provides a method for dynamically generating tokens, applied on a server side, including:

[0007] In response to the achievement of a preset triggering condition, a first target scheme for the total code used to generate the token is determined according to a preset method. The first target scheme includes multiple target sub-schemes corresponding to multiple sub-schemes. The multiple sub-schemes include: algorithm-related schemes, data structure schemes, data interface schemes, code execution flow schemes, and code obfuscation schemes. Each sub-scheme in the multiple sub-schemes has multiple candidate schemes.

[0008] A first session key is generated based on the token version number and the sub-scheme identifiers of the multiple target sub-schemes;

[0009] Assign a first session key identifier to the first session key, and store the correspondence between the first session key and the first session key identifier in a correspondence table; wherein, the first session key identifier is used to uniquely identify the first session key; the sub-scheme identifier is used to uniquely identify a sub-scheme;

[0010] Obtain the sub-code corresponding to each of the multiple target sub-solutions;

[0011] Based on the sub-codes corresponding to each of the multiple target sub-schemes, obtain the total code used to generate the token this time;

[0012] The total code and the first session key identifier are sent to the client so that the client can generate a token based on the total code.

[0013] Another aspect of this application provides an alternative method for dynamically generating tokens, applied to a client, the method comprising:

[0014] In response to receiving the total code and second session key identifier sent by the server; wherein, the second session key identifier is used to uniquely identify the second session key; the second session key is generated based on the token version number and multiple sub-scheme identifiers corresponding to the second target scheme, and the second session key includes the multiple sub-scheme identifiers; the second target scheme includes multiple target sub-schemes corresponding to multiple sub-schemes, and the multiple sub-scheme identifiers are used to identify the multiple target sub-schemes; wherein, the multiple sub-schemes include: algorithm-related schemes, data structure schemes, data interface schemes, code execution flow schemes, and code obfuscation schemes; each of the multiple sub-schemes has multiple candidate schemes; the total code is obtained based on the sub-code corresponding to each target sub-scheme in the multiple target sub-schemes;

[0015] Generate a token based on the total code;

[0016] The request content, the token, and the second session key identifier are sent to the server.

[0017] Another aspect of this application provides an apparatus for dynamically generating tokens, applied on a server side, comprising:

[0018] The determination module is used to determine, in response to the achievement of a preset triggering condition, the first target scheme of the total code used to generate the token in this instance according to a preset method. The first target scheme includes multiple target sub-schemes corresponding to multiple sub-schemes. The multiple sub-schemes include: algorithm-related schemes, data structure schemes, data interface schemes, code execution flow schemes, and code obfuscation schemes. Each sub-scheme in the multiple sub-schemes has multiple candidate schemes.

[0019] The first generation module is used to generate a first session key based on the token version number and the sub-scheme identifiers of the multiple target sub-schemes;

[0020] The allocation module is used to allocate a first session key identifier to the first session key and store the correspondence between the first session key and the first session key identifier in a correspondence table; wherein, the first session key identifier is used to uniquely identify the first session key; and the sub-scheme identifier is used to uniquely identify a sub-scheme.

[0021] The first acquisition module is used to acquire the sub-code corresponding to each of the multiple target sub-schemes;

[0022] The second acquisition module is used to acquire the total code used to generate the token this time based on the sub-code corresponding to each target sub-scheme in the plurality of target sub-schemes;

[0023] The first sending module is used to send the total code and the first session key identifier to the client so that the client can generate a token based on the total code.

[0024] Another aspect of this application provides an apparatus for dynamically generating tokens, applied to a client, comprising:

[0025] A receiving module is configured to respond to receiving a total code and a second session key identifier sent by the server; wherein, the second session key identifier is used to uniquely identify the second session key; the second session key is generated based on a token version number and multiple sub-scheme identifiers corresponding to the second target scheme, and the second session key includes the multiple sub-scheme identifiers; the second target scheme includes multiple target sub-schemes corresponding to multiple sub-schemes, and the multiple sub-scheme identifiers are used to identify the multiple target sub-schemes; wherein, the multiple sub-schemes include: algorithm-related schemes, data structure schemes, data interface schemes, code execution flow schemes, and code obfuscation schemes; each of the multiple sub-schemes has multiple candidate schemes; the total code is obtained based on the sub-code corresponding to each target sub-scheme in the multiple target sub-schemes;

[0026] The second generation module is used to generate tokens based on the total code;

[0027] The second sending module is used to send the request content, the token, and the second session key identifier to the server.

[0028] In another aspect, this application provides an electronic device, the electronic device comprising:

[0029] One or more processors;

[0030] Storage device for storing one or more programs.

[0031] When the one or more programs are executed by the one or more processors, the one or more processors implement the method for dynamically generating tokens as provided in the foregoing aspect.

[0032] In another aspect of this application, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the method for dynamically generating tokens as provided in the preceding aspect.

[0033] As can be seen from the above technical solution, the server can dynamically adjust the first target scheme of the total code used to generate tokens each time, ensuring that the total code sent to the client for token generation is different each time. This results in different tokens generated by the client each time. Since the first target scheme includes multiple target sub-schemes corresponding to multiple sub-schemes, and since these sub-schemes include algorithm-related schemes, data structure schemes, data interface schemes, code execution flow schemes, and code obfuscation schemes, and each sub-scheme has multiple candidate schemes, the possible combinations of code used to generate tokens can reach hundreds or even tens of millions. Through a massive number of token generation schemes and the dynamic adjustment of the token generation scheme strategy, the difficulty for attackers to reverse engineer the token generation code is greatly increased, effectively preventing attackers from integrating the token generation code into automated tools to automatically generate tokens, thus improving token security. Even if an attacker spends a lot of time reverse engineering a portion of the code used to generate a token, due to the dynamic adjustment of the token generation scheme strategy, this portion of code is rendered invalid, making the attacker's reverse engineering of that portion of the token generation code meaningless.

[0034] In addition, based on the technical solution provided in this application, the server can send the total code for generating the token and the first session key identifier to the client. After the client generates the token based on the total code, it can return the request content, the generated token, and the received second session key identifier to the server. In this way, the server can obtain the corresponding second session key based on the second session key identifier and extract valid data from the token according to the sub-scheme identified by the multiple sub-scheme identifiers in the second session key, thereby improving the security and identifiability of the token.

[0035] Furthermore, based on the technical solution provided in this application, the first session key generated by the server also includes the expiration time information of the first target scheme. In this way, after receiving the second session key identifier returned by the client and obtaining the corresponding second session key, it is possible to confirm whether the second session key has expired based on the expiration time information of the second target scheme in the second session key. Only when the second session key has not expired can the token be effectively extracted based on the sub-schemes identified by the multiple sub-scheme identifiers in the second session key. A shorter expiration time can be set to prevent attackers from reverse engineering the total code used to generate the token. Even if an attacker spends a lot of time reverse engineering a portion of the code used to generate the token, this portion of code has expired and cannot be integrated into an automated tool to automatically generate the token, thereby improving the security of the token.

[0036] In addition, based on the technical solution provided in this application, attackers can be prevented from using automated tools to automatically generate tokens to access network data and system resources using reverse-analyzed code, or from further tampering with network data and system resources or implanting viruses, thus effectively ensuring the security of network data and system resources. [Attached Image Description]

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

[0038] Figure 1 A flowchart illustrating a method for dynamically generating tokens according to an embodiment of this application;

[0039] Figure 2 A flowchart illustrating a method for dynamically generating tokens according to another embodiment of this application;

[0040] Figure 3 A flowchart illustrating a method for dynamically generating tokens according to another embodiment of this application;

[0041] Figure 4 This is a flowchart illustrating a method for dynamically generating tokens according to another embodiment of this application.

[0042] Figure 5 A schematic diagram of the structure of a device for dynamically generating tokens according to an embodiment of this application;

[0043] Figure 6A schematic diagram of the structure of an apparatus for dynamically generating tokens provided in another embodiment of this application;

[0044] Figure 7 This is a schematic diagram of the structure of a system for dynamically generating tokens provided in an embodiment of this application;

[0045] Figure 8 This is a schematic block diagram of an example electronic device that can be used to implement embodiments of this application.

Detailed Implementation Methods

[0046] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0047] It should be noted that the terminals involved in the embodiments of this application may include, but are not limited to, mobile phones, personal digital assistants (PDAs), wireless handheld devices, tablet computers, personal computers (PCs), MP3 players, MP4 players, wearable devices (e.g., smart glasses, smartwatches, smart bracelets, etc.).

[0048] Those skilled in the art will understand that the terms "first" and "second" in the embodiments of this disclosure are only used to distinguish different steps, devices, modules, objects, information, etc., and do not represent any specific technical meaning, nor do they indicate the necessary logical order between them, nor do they indicate whether the first object and the second object are necessarily the same or different.

[0049] Furthermore, the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0050] In related technologies, the client generates tokens based on fixed code. For example, in one related technology, the client generates tokens using the following code: it uses a fixed function interface and a fixed data format to pass in the data for generating the token, then sequentially verifies the data using a fixed verification algorithm, encrypts it using an encryption algorithm, and encodes it using a fixed encoding algorithm. The order in which the token is generated is also fixed.

[0051] The following is an example (javascript code) of a client generating a token based on javascript code in related technologies:

[0052] function build_token(){

[0053] var data = [];

[0054] data[0] = Token version number

[0055] / / Generate token IDs according to certain rules

[0056] data[1] = Token ID

[0057] data[2] = token type

[0058] data[3] = Token Source

[0059] data[4] = token attribute

[0060] / / Get the client's current time

[0061] data[5] = current client time

[0062] data[6] = Optional data 1

[0063] data[7] = optional data2

[0064] data[5+n] = optional data ... N

[0065] / / Calculate the validation value of the above data

[0066] data[6+n] = CRC16 checksum

[0067] / / Encrypted data

[0068] var encrypted_data=encrypt_by_aes256(data)

[0069] var cipher=[]

[0070] cipher.push(Session Key generated on the server)

[0071] cipher.push(encrypted_data)

[0072] / / Encoding data

[0073] var token=base64_encode(cipher)

[0074] return token;

[0075] }

[0076] The function `build_token()` is the token generation function. The client generates tokens by executing the code in `build_token()`. `data[]` indicates the position of each field in the token's data structure. For example, `data[0] = token version number` means the field "token version number" is in the 0th position of the token's data structure; `data[1] = token ID` means the field "token ID" is in the 1st position of the token's data structure; and so on. Depending on the application's business, optional data may include user input data, mouse movement data, keyboard input statistics, and environment-related data (such as window size, current operating system, CPU model, etc.). The client uses a fixed function `build_token()` interface, a fixed CRC16 checksum algorithm, an AES256 encryption algorithm, and a base64 encoding algorithm to generate tokens sequentially.

[0077] Because in related technologies, the client generates tokens based on fixed code, the code used by the client to generate the tokens can be easily reverse-engineered and thoroughly analyzed by attackers. Then, attackers can use automated tools to automatically generate tokens using this code and send them to the server. The server has difficulty distinguishing whether the received token was sent by a user with access rights through the client or by an attacker. As a result, attackers can use the token to access network data and system resources, or further tamper with network data and system resources or implant viruses, which may cause great losses to users.

[0078] Therefore, there is an urgent need to provide a method and apparatus, electronic device and computer-readable storage medium for dynamically generating tokens, so as to increase the difficulty for attackers to reverse engineer the code that generates tokens, thereby improving the security of tokens.

[0079] The design concept of this application lies in the server-side dynamically adjusting the total code used to generate tokens each time, ensuring that the total code sent to the client for token generation is different each time. This results in different tokens generated by the client each time. Through a massive number of token generation schemes and the dynamic adjustment strategy, the difficulty for attackers to reverse engineer the token generation code is significantly increased, effectively preventing attackers from integrating the token generation code into automated tools to automatically generate tokens, thus improving token security. Even if an attacker spends a significant amount of time reverse engineering a portion of the code used to generate a token, this portion of code becomes invalid due to the dynamic adjustment strategy, rendering the attacker's reverse engineering of that portion of the code meaningless.

[0080] The embodiments of this application can be applied to various electronic devices with a client-server (C / S) architecture.

[0081] Figure 1 This is a flowchart illustrating a method for dynamically generating tokens according to an embodiment of this application. This embodiment is applied to a server, such as... Figure 1 As shown.

[0082] 101. In response to the achievement of the preset triggering conditions, determine the first target scheme of the total code used to generate the token in this instance according to the preset method.

[0083] The first objective scheme includes multiple objective sub-schemes corresponding to multiple sub-schemes.

[0084] The multiple sub-schemes may include, but are not limited to, algorithm-related schemes, data structure schemes, data interface schemes, code execution flow schemes, and code obfuscation schemes. Each sub-scheme in the multiple sub-schemes has multiple candidate schemes. Each candidate scheme has a corresponding sub-scheme identifier (ID), which is used to uniquely identify a sub-scheme and can be pre-assigned by the server. The sub-scheme identifier may be, for example, the sub-scheme name, a server-globally unique sub-scheme number, or a combination of the sub-scheme name and the server-globally unique sub-scheme number, etc. This application does not limit the specific composition of the sub-scheme identifier.

[0085] The algorithm-related scheme refers to the corresponding algorithm scheme used to process data (e.g., verification, encryption, encoding) when generating the token. The data structure scheme determines the data structure of the token, specifying the data structure (e.g., position, hiding method) of each data component (field) involved in token generation. The data interface scheme is the interface form used when generating the token. The code execution flow scheme is the process scheme for generating the token. The code obfuscation scheme is the obfuscation scheme for the code used to generate the token.

[0086] In this embodiment, the preset trigger condition is a condition pre-set by the server to trigger the generation of the general code for generating tokens, so that the client can generate tokens based on the general code. This preset trigger condition can be set according to actual needs. For example, in one specific implementation, the server can use real-time, random, or idle time as the preset trigger condition to trigger the generation of the code for generating tokens, executing operations 101-105 of this embodiment, and then executing operation 106 when the client needs it later. In another specific implementation, some preset user events can be used as the preset trigger condition. The server can listen to preset user events through the client, such as whether there are mouse or keyboard input signals generated by user operations. When the client listens to these user events, it will trigger the server to generate the general code for generating tokens, executing operations 101-106 of this embodiment. In yet another specific implementation, the server can use a preset period as the preset trigger condition, periodically triggering the generation of the general code for generating tokens through a timer, executing operations 101-105 of this embodiment, and then executing operation 106 when the client needs it later.

[0087] Then, operations 102-103 and 104-105 can be performed respectively.

[0088] 102. Generate the first session key based on the token version number and the sub-scheme identifiers of multiple target sub-schemes.

[0089] The token version number is the version number assigned by the server to the token generated this time according to a preset allocation method (such as random allocation or sequential allocation). The token version number can be an integer, a decimal, a floating-point number, or a number, a letter, or a string composed of numbers and letters, etc. This application embodiment does not limit the allocation method and composition of the token version number.

[0090] Therefore, the server can use the first session key to record the method used to generate the token in the total code used to generate the token.

[0091] 103. Assign a first session key identifier (ID) to the first session key and store the correspondence between the first session key and the first session key identifier in the correspondence table.

[0092] Each session key ID is used to uniquely identify a session key, and the first session key identifier is used to uniquely identify the first session key. The mapping table includes the correspondence between each first session key generated by the server and its corresponding session key ID.

[0093] Then, execute operation 106.

[0094] 104. Obtain the sub-code corresponding to each of the multiple target sub-schemes.

[0095] 105. Based on the sub-codes corresponding to each of the multiple target sub-schemes, obtain the total code used to generate the token this time.

[0096] The master code has a one-to-one correspondence with the first session key.

[0097] Operations 102-103 and 104-105 can be executed simultaneously or in any order; this application embodiment does not impose any restrictions on this.

[0098] 106. Send the total code and the first session key identifier to the client so that the client can generate a token based on the total code.

[0099] In practical applications, the server can send the master code and the first session key identifier to the client when the client needs to send the request content of the business request to the server, or it can send the master code and the first session key identifier to the client in advance so that the client can generate a token based on the master code before sending the request content of the business request to the server.

[0100] In this way, the server can dynamically adjust the primary target scheme of the total code used to generate tokens each time, ensuring that the total code sent to the client for token generation is different each time. This results in different tokens generated by the client each time. Through a massive number of token generation schemes and dynamic adjustment strategies, the difficulty of reverse engineering the token generation code is greatly increased, effectively preventing attackers from integrating the token generation code into automated tools to automatically generate tokens, thus improving token security. Even if an attacker spends a significant amount of time reverse engineering a portion of the code used to generate a token, this portion is rendered invalid due to the dynamic adjustment strategy, rendering the attacker's reverse engineering of that portion meaningless. Furthermore, this prevents attackers from using automated tools to automatically generate tokens from reverse-engineered code to access network data and system resources, or to further tamper with or implant viruses into network data and system resources, effectively protecting the security of network data and system resources.

[0101] Optionally, in some implementations, the algorithm-related schemes may include: encoding algorithm schemes, encryption algorithm schemes, and verification algorithm schemes.

[0102] In the algorithm-related schemes, multiple candidate schemes are provided for the verification, encryption and encoding stages in the token generation process, for selection each time.

[0103] For example, the verification algorithm used in the verification stage may include multiple candidate schemes such as MD5, SHA-1, SHA-2, CRC32, CRC16, CRC8, LRC, SM3, or other verification algorithms, and each candidate scheme can be assigned a corresponding verification algorithm scheme identifier (ID) as a sub-scheme identifier. The encryption algorithm used in the encryption stage may include multiple candidate schemes such as AES128, AES256, 3DES, SM4, RC5, RC6, or other encryption algorithms, and each candidate scheme can be assigned a corresponding encryption algorithm scheme identifier as a sub-scheme identifier. The encoding algorithm used in the encoding stage may include, but is not limited to, multiple candidate schemes such as Base81, Base56, Base64, or other encoding schemes, and each candidate scheme can be assigned a corresponding encoding algorithm scheme identifier as a sub-scheme identifier.

[0104] Optionally, in some implementations, the data structure scheme may include: a data storage location scheme, a scheme for inserting redundant data, and a data hiding scheme.

[0105] The fields involved in generating the token can use different data structures in the token, thus allowing the generated token to have different data structures.

[0106] In this embodiment, the data storage location scheme is used to determine the position of each field involved in generating the token within the token's data structure. In different data storage location schemes, the positions of each field involved in generating the token within the token's data structure may differ or not be entirely the same; even the same field may have different positions within the token's data structure. Based on the target data storage location scheme in the first session key, the server can determine the position of each field within the token's data structure, thereby extracting the specific information of each field from the corresponding position.

[0107] For example, in a specific example, taking the fields involved in generating the token, including token version number, token ID, token type, token source, token attributes, client current time, etc., the positions of each field in the token's data structure under the following different data storage location schemes are as follows:

[0108] Data storage location scheme 1: data[0] = token version number, data[1] = token ID, data[2] = token type, data[3] = token source, data[4] = token attribute, data[5] = client current time, ...;

[0109] Data storage location scheme 2: data[0] = token ID, data[1] = token version number, data[2] = token type, data[3] = client current time, data[4] = token attribute, data[5] = token source, ...;

[0110] Data storage location scheme 3: data[0] = client current time, data[1] = token source, data[2] = token ID, data[3] = token type, data[4] = token attribute, data[5] = token version number, ...;

[0111] …

[0112] Data storage location scheme N:…

[0113] Where data[] represents the position of each field in the token's data structure. For example, data[1] = tokenID means that the field "tokenID" is in the first position in the token's data structure.

[0114] In this embodiment, a redundant data insertion scheme is used to represent a scheme for inserting redundant data into fields participating in token generation. According to the redundant data insertion scheme, different amounts of redundant data can be inserted at different positions. Each redundant data insertion scheme may include: the number of invalid fields to be inserted, the position of each invalid field in the token's data structure, and the redundant data assigned to each invalid field. According to the redundant data insertion scheme, different amounts of redundant data for invalid fields can be inserted at different positions in the fields participating in token generation (e.g., before or after a certain position in the token's data structure).

[0115] For ease of distinction, in this embodiment, the fields involved in generating the token can be divided into valid fields and invalid fields. Valid fields are those required by the preset rules for the token, such as token version number, token ID, token type, token source, token attributes, client current time, and some optional data. The specific information (i.e., values) of these valid fields can be called valid data. Invalid fields are those inserted in this implementation, in addition to the valid fields specified by the preset rules, to increase the difficulty of reverse engineering the token-generating code and improve token security. The specific information (i.e., values) of these invalid fields can be called redundant data (i.e., invalid data). Based on the target data storage location scheme and the target redundant data insertion scheme in the first session key, the server can determine the specific position of each valid field in the token's data structure, thereby extracting the specific information of each valid field from the corresponding position. Furthermore, by comparing the redundant data at each position in the target redundant data insertion scheme with the redundant data at the corresponding position in the token returned by the client, the server can detect whether the total code sent to the client has been reverse-engineered or tampered with.

[0116] For example, in a specific case, the following scheme for inserting redundant data could be provided as a candidate scheme:

[0117] Scheme 1 for inserting redundant data: data[0] = random number, data[1] = random number, data[2] = random number, data[3] = random number, data[4] = token version number, data[5] = token ID, data[6] = token type, data[7] = token source, data[8] = token attribute, data[9] = client current time, ...;

[0118] Scheme 2 for inserting redundant data: data[0] = token ID, data[1] = token version number, data[2] = token type, data[3] = client current time, data[4] = token attribute, data[5] = token source, data[6] = random number, data[7] = random number, data[8] = random number, ...;

[0119] Scheme 3 for inserting redundant data: data[0] = current client time, data[1] = random number, data[2] = token source, data[3] = random number, data[4] = token ID, data[5] = token type, data[6] = random number, data[7] = token attribute, data[8] = token version number, ...;

[0120] …

[0121] Inserting redundant data scheme N:…

[0122] The random number can be set by the server according to preset rules, such as an integer greater than 0 and less than 255.

[0123] Based on the target redundant data insertion scheme in the first session key, after receiving the token and the second session key returned by the client, the server can extract valid data (i.e., specific information or values ​​of each field other than redundant data) only from the corresponding position in the token according to the target data storage location scheme and the target redundant data insertion scheme. In addition, it can also detect whether the total code sent to the client has been tampered with by checking whether the value at the position where the random number is inserted in the token is consistent with the value of the random number at the corresponding position in the target redundant data insertion scheme. Alternatively, based on the above preset rule settings, if the value at the position where the random number is inserted in the token is 0 or 255, it can be directly determined that the total code sent to the client has been tampered with.

[0124] In this embodiment, the data hiding scheme is a scheme to hide all fields or some preset fields involved in generating the token. Each data hiding scheme includes: a hidden field and a hiding method corresponding to the hidden field, wherein the hidden field is the field to be hidden, which can be for all fields, or for one or several fields, depending on specific needs. The number of hidden fields targeted by each data hiding scheme can be the same as or different from the total number of valid and invalid fields, and this embodiment does not impose any restrictions on this. For example, in a specific implementation, when the data hiding scheme targets some preset fields involved in generating the token, if the number of hidden fields is greater than the total number of valid and invalid fields, the hiding process can be performed only on the valid and invalid fields involved in the hidden fields; if the number of hidden fields is less than the total number of valid and invalid fields, the hiding process can be performed only on the corresponding hidden fields among the valid and invalid fields. Through the data hiding scheme, each hidden field involved in generating the token can be processed by performing hiding operations (such as encryption / decryption, encoding / decoding, inversion, XOR, shift, etc.) based on the data hiding method corresponding to each hidden field to hide the specific information (i.e., assignment) of each hidden field. After receiving the token sent by the client, the server can use the corresponding restoration operation to restore the hidden fields based on the target data hiding scheme in the first session key, thereby obtaining the specific information of each hidden field.

[0125] Table 1 below shows the optional data hiding methods for several data hiding schemes in the embodiments of this application, as well as the hiding operation, restoration operation, and applicable scope (i.e., the data form that can be used as a hidden field) corresponding to each data hiding method.

[0126] Table 1

[0127]

[0128] For example, in a specific example, taking the above-mentioned scheme 1 for inserting redundant data as an example, several candidate schemes for the corresponding data hiding scheme could be:

[0129] Data hiding scheme 1: data[0] = random number^0x11, data[1] = random number^0x22, data[2] = random number^0x33, data[3] = random number^0x44, data[4] = token version number^0x55, data[5] = token ID^0x66, data[6] = token type^0x77, data[7] = token source^0x88, data[8] = token attribute^0x99, data[9] = client current time^0xAA, ...

[0130] Restore operation: Token version number = data[4]^0x55, Token ID = data[5]^0x66, Token type = data[6]^0x77, Token source = data[7]^0x88, Token attribute = data[8]^0x99, Client current time = data[9]^0xAA, ...

[0131] Data hiding scheme 2: data[0] = random number + 0x11, data[1] = random number + 0x22, data[2] = random number + 0x33, data[3] = random number + 0x44, data[4] = token version number + 0x55, data[5] = token ID + 0x66, data[6] = token type + 0x77, data[7] = token source + 0x88, data[8] = token attribute + 0x99, data[9] = client current time + 0xAA, ...

[0132] Restore operation: Token version number = data[4]-0x55, Token ID = data[5]-0x66, Token type = data[6]-0x77, Token source = data[7]-0x88, Token attribute = data[8]-0x99, Client current time = data[9]-0xAA, ...

[0133] Data hiding scheme 3: data[0] = random number^0x11, data[1] = random number +0x22, data[2] = random number <<1, data[3] = random number^0xFF, data[4] = ~token version number, data[5] = token ID^0x66, data[6] = token type +0x77, data[7] = token source <<2, data[8] = token attribute^0x99, data[9] = ~client current time, ...

[0134] Restore operation: Token version number = ~data[4], Token ID = data[5]^0x66, Token type = data[6]-0x77, Token source = data[7]>>2, Token attribute = data[8]^0x99, Client current time = ~data[9], ...

[0135] …

[0136] Data hiding scheme N: ...

[0137] In data hiding scheme 1, the data hiding method is XOR (XOR operator ^). In data hiding scheme 2, the data hiding method is addition (addition operator +, subtraction operator -). In data hiding scheme 3, the data hiding methods include XOR (XOR operator ^), addition (addition operator +, subtraction operator -), shift (left shift operator <<, right shift operator >>), and negation (negation operator ~). In practical applications, the above data hiding methods can be used individually or in combination.

[0138] In this embodiment, the data interface scheme is the interface used when generating tokens. The interface refers to the interface referenced between execution units when the client generates a token. The data interface scheme may include any one or more of the following: adding invalid parameters, data transmission, data return, etc.

[0139] The method of adding invalid parameters refers to adding invalid parameters in one or more preset positions in the interface function used to upload the parameters (i.e., specific information) of each field when generating the token. This makes it possible for the fields used to generate the token to include one or more invalid parameters. Compared with the method of directly passing in valid parameters in related technologies, this method can increase the difficulty for attackers to reverse-engineer the code used to generate the token.

[0140] For example, in a specific case, taking the Session Key generated by the server as the parameter required when generating the token, several candidate solutions for adding invalid parameters could be:

[0141] Invalid parameter solution 1: function build_token(random array 1, random array 2, session key generated by server)

[0142] Invalid parameter solution 2: function build_token(random number, server-generated Session Key)

[0143] Invalid parameter solution 3: function build_token(random array 1, SessionKey generated by server, random number, random number)

[0144] …

[0145] Invalid parameter scheme N:…

[0146] The `build_token()` function is an interface function. Invalid parameter scheme 1 means that two invalid parameters are added before the valid parameter input position to pass in random array 1 and random array 2, which are invalid for token generation. The Session Key generated by the server is then passed in the third position. Invalid parameter scheme 2 means that an invalid parameter is added before the valid parameter input position to pass in a random number invalid for token generation. The Session Key generated by the server is then passed in the second position. Invalid parameter scheme 3 means that an invalid parameter is added before the valid parameter input position to pass in random array 1 invalid for token generation, and two invalid parameters are added after the valid parameter input position to pass in random numbers invalid for token generation. The Session Key generated by the server is then passed in the second position.

[0147] The data transmission scheme refers to the method by which parameters of each field are uploaded to the token generation function used to generate the token. For example, it may include, but is not limited to: variable passing method, array passing method, object method passing method, closure variable passing method, global variable passing method, object property passing method, etc.

[0148] Among them, the data return scheme refers to the way in which the token generation function used to generate tokens returns tokens, which may include, but is not limited to: directly returning variables, returning arrays, returning object methods, returning closure variables, returning global variables, etc.

[0149] In practical applications, the schemes of adding invalid parameters, data transmission, and data return can be used individually or in combination to effectively increase the difficulty for attackers to reverse engineer the code used to generate tokens.

[0150] In this embodiment, the code execution flow scheme is a token generation flow scheme. The code execution flow scheme may include any one or more of the following schemes: a traditional sequential execution flow scheme, a timer scheme using a short time interval, a callback function scheme that passes the scheme code as a parameter, a scheme using closure calls, or a scheme that uses an object to encapsulate a certain process in token generation, etc.

[0151] The traditional sequential execution process involves sequentially inputting data for token generation, verifying the data using a verification algorithm, encrypting it using an encryption algorithm, and encoding it using a fixed encoding algorithm, and then executing the process sequentially to generate the token.

[0152] One approach uses a timer with a short time interval. This involves setting a timer for a short interval, at which point the system calls the token generation function to execute the token generation process. This short time interval can be set according to actual needs, such as 0 seconds, milliseconds, seconds, or minutes. The timer will then call the token generation function to execute the token generation process at the designated time interval.

[0153] For example, an example of using a timer scheme with a shorter time interval is: setTimeout(build_toke, 0);

[0154] Where 0 represents the time interval, and 0 indicates a higher priority. The system will immediately call the token generation function to execute the token generation process after completing the current task.

[0155] By using a timer scheme with shorter time intervals, the token generation process can be changed from a traditional synchronous execution process to an asynchronous execution process. This can effectively prevent attackers from tracing the token generation process and increase the difficulty for attackers to reverse engineer the code.

[0156] One approach is to pass the callback function with the scheme code as a parameter. In this approach, during the token generation process, the sub-code of one or more target sub-schemes used to generate the token is passed as a parameter to the token generation function. This obfuscates the token generation process and increases the difficulty for attackers to reverse engineer the code.

[0157] In practical applications, the sub-codes of one or more target sub-schemes used to generate tokens can be nested layer by layer. That is, the sub-code of one target sub-scheme is passed as a parameter to the token generation function, and then the sub-code of another target sub-scheme is passed as a parameter in the sub-code of that target sub-scheme, and so on, with different target sub-schemes being passed in layer by layer.

[0158] For example, in an implementation example of generating a token, the specific information of each field can be passed in first. When encrypting each field, the sub-code of the target encryption algorithm scheme is passed in as a parameter for execution. After encryption is completed, the sub-code of the target verification algorithm scheme is passed in as a parameter for execution. After verification is completed, the sub-code of the target encoding algorithm scheme is passed in as a parameter for execution. That is, the sub-code of the target encryption algorithm scheme, the sub-code of the target verification algorithm scheme, and the sub-code of the target encoding algorithm scheme are nested and passed in as parameters in sequence.

[0159] The following is a code example of a callback function scheme that takes the scheme code as a parameter:

[0160]

[0161]

[0162] var token=build_token(prepare_data,encrypt_aes256,base64_encode);

[0163] In the code implementation example above, callback1 represents the specific information passed to each field, that is, assigning values ​​to each field. For example, assigning the specific information of the token attribute to data[0], assigning the specific information of the token ID to data[1], assigning the specific information of the token source to data[3], etc. callback2 passes the sub-code of the target encryption algorithm scheme as a parameter for encryption; callback3 represents that after encryption is completed, the encryption result is assembled with the Session Key, and the sub-code of the target encoding algorithm scheme is passed as a parameter of the sub-code of the target encryption algorithm scheme for execution encoding.

[0164] One approach uses closure calls, where a function declares another function within a function that implements a specific function to achieve the same functionality. A closure is defined as a function A that declares and returns a function B, or a variable that can reference a non-global variable. The functions acting as closures are the sub-code corresponding to each target sub-scheme. Using closure calls on the sub-code corresponding to different target sub-schemes can alter the format of the sub-code relative to the atomic code, thus obfuscating the code and increasing the difficulty for attackers to reverse engineer it.

[0165] Below is a code example of passing specific information for each field in a scheme that uses closure calls:

[0166]

[0167] In the code implementation example above, function build_token is the token generation function, and function prepare_data() is the function used to assign values ​​to each field by passing in the specific information of each field. In the token generation function function build_token, the fields are not directly assigned values. Instead, the function prepare_data() is declared in the token generation function function build_token, and the fields are assigned values ​​by calling function prepare_data().

[0168] One approach involves encapsulating a specific process in token generation using an object. This means that an object can be used to encapsulate sub-code for a particular process (such as assigning values ​​to fields, verification, encryption, or encoding). This allows the format of the sub-code at a given stage to change relative to the atomic code, thereby obfuscating the code and increasing the difficulty for attackers to reverse engineer it.

[0169] Below is a code example of passing specific information for each field in a scheme that uses closure calls:

[0170]

[0171]

[0172] In the code implementation example above, `obj.prepare_data = function(data)` represents the sub-code that uses an object to encapsulate the process of assigning values ​​to each field; `obj.encrypt = encrypt_aes256` represents the sub-code that uses an object to encapsulate the target encryption algorithm scheme in the encryption process; `obj.encode = base64_encode` represents the sub-code that uses an object to encapsulate the target encoding scheme in the encoding process; and `obj.build_token = function()` represents the total code that uses an object to encapsulate the token generation.

[0173] In practical applications, the various schemes in the code execution flow scheme can be used individually or in combination, thereby effectively increasing the difficulty for attackers to reverse engineer the code used to generate tokens.

[0174] In this embodiment of the application, the code obfuscation scheme is a scheme for obfuscating the code used to generate tokens. The code obfuscation scheme may include any one or more of the following schemes: control flow flattening (CFF) scheme, random addition of invalid code scheme, keyword extraction and hiding scheme, variable renaming scheme using different styles, code content self-verification scheme, etc.

[0175] The basic idea behind the CFF (Continuous Forwarding) approach is to use a master dispatcher to control the execution flow of basic blocks within a program (either main code or sub-code), thus obscuring the sequential relationships between these blocks and increasing the difficulty of program analysis. For example, in one specific example, if-else statements can be replaced with do-while statements, and then flow control can be achieved using switch statements, thereby blurring the sequential relationships between basic blocks.

[0176] One approach is to randomly add invalid code, which involves adding invalid code randomly to the main code or sub-code to increase the difficulty of reverse engineering the main code.

[0177] The following is a code implementation example of a scheme to randomly add invalid codes:

[0178] build_token = function(){

[0179] this.prepare_data();

[0180] var encrypted_data=this.encrypt(data)

[0181] function1(data) / / Invalid function call

[0182] var a = data[0] / / Invalid code

[0183] var cipher=[]

[0184] a+=1 / / Invalid code

[0185] cipher.push(Session Key generated by the server)

[0186] if(a){ / / Invalid condition check code: because a+=1 has already been executed, this must be true.

[0187] cipher.push(encrypted_data)

[0188] function2(cipher) / / Invalid function call

[0189] }

[0190] var token=this.base64(cipher)

[0191] return token;

[0192] }

[0193] In the code implementation example above, invalid function call function1(data), invalid code var a=data[0], invalid code a+=1, invalid judgment code if(a), and invalid function call function2(cipher) were added to the code that generates the token.

[0194] The keyword extraction and hiding scheme involves extracting commonly used keywords (such as constants, constant strings, constant constants, etc.) from the main code or sub-code and encrypting them using a preset method. These keywords are then decrypted and restored when used, preventing plaintext appearance in the code. For example, to determine if code has been formatted, the function `function.toString()` can be used to convert the code to text. After extracting and hiding `toString`, its usage becomes `function[getProperty(11)]()`. `getProperty(11)` will return the string `toString`, where 11 is the index number of the string `toString`.

[0195] Among them, different styles are used to rename the variables. That is, different styles are used to rename the preset variables. For example, token can be renamed to $$1 or _0x90a0f0. For var token = encrypt(data), it can be represented as: var $$1 = encrypt(data) or var_0x90a0f0 = encrypt(data).

[0196] The code content self-verification scheme involves converting the total code or the sub-code corresponding to a specific target sub-scheme into text. For example, the function `function.toString()` is used to convert the sub-code corresponding to a target sub-scheme into text. A preset verification algorithm is then used to calculate the verification value of the text, which is stored on the server. After receiving the second session key identifier returned by the client, the server can calculate the verification value of the total code or the sub-code corresponding to a specific sub-scheme identifier, based on the sub-scheme identifiers in the second session key, using the same method. This verification value is then compared with the stored corresponding verification value to determine whether the total code or sub-code has been formatted or tampered with. If the verification value calculated based on the multiple sub-scheme identifiers in the second session key is inconsistent with the corresponding verification value stored on the server, it indicates that the total code or sub-code has been formatted or tampered with.

[0197] In practical applications, CFF schemes, random addition of invalid code schemes, keyword extraction and hiding schemes, variable renaming schemes using different styles, and code content self-verification schemes can be used individually or in combination to effectively increase the difficulty for attackers to reverse engineer the code used to generate tokens.

[0198] In the above embodiments, the CFF scheme, the scheme of randomly adding invalid code, the keyword extraction and hiding scheme, and the scheme of renaming variables using different styles achieve the effect of code obfuscation, making the code difficult for humans to identify and reverse analyze, without affecting the client's execution of the code. The client can still identify and execute the obfuscated code.

[0199] In the algorithm-related schemes, data structure schemes, data interface schemes, code execution flow schemes, and code obfuscation schemes of the above embodiments, the algorithm-related schemes (including encoding algorithm schemes, encryption algorithm schemes, and verification algorithm schemes) and data structure schemes (including data storage location schemes, redundant data insertion schemes, and data hiding schemes) affect the specific content of the generated token. That is, using different encoding algorithm schemes, encryption algorithm schemes, verification algorithm schemes, data storage location schemes, redundant data insertion schemes, and data hiding schemes will result in different specific content of the generated token. However, the data interface scheme, code execution flow scheme, and code obfuscation scheme only affect the total code used to generate the token itself. Random combinations of different data interface schemes, code execution flow schemes, and code obfuscation schemes will greatly increase the difficulty for attackers to reverse engineer the total code, but will not affect the specific content of the generated token.

[0200] Optionally, in some implementations, in operation 101, in response to the achievement of a preset triggering condition, a candidate solution can be sequentially selected from the candidate solutions corresponding to each sub-solution as the target sub-solution corresponding to each sub-solution; or, a candidate solution can be randomly selected from the candidate solutions corresponding to each sub-solution as the target sub-solution corresponding to each sub-solution.

[0201] Based on this embodiment, the target sub-scheme corresponding to each sub-scheme can be dynamically determined, so that the target scheme of the code used to generate tokens changes dynamically each time, which greatly increases the difficulty for attackers to reverse analyze the code that generates tokens, effectively preventing attackers from reverse analyzing the code that generates tokens, thus making it impossible for attackers to integrate the code that generates tokens into automated tools to automatically generate tokens.

[0202] Optionally, in some implementations, candidate solutions and sub-codes corresponding to each sub-solution can be pre-set; or, the candidate solutions and sub-codes corresponding to each sub-solution can be further updated.

[0203] Based on this embodiment, the sub-schemes in the target scheme used to generate tokens can be dynamically updated, thereby further increasing the difficulty for attackers to reverse engineer the token generation scheme or code.

[0204] Optionally, in some implementations, in operation 104, the sub-code corresponding to each target sub-scheme can be obtained from the candidate schemes corresponding to each pre-set sub-scheme and the sub-codes corresponding to each candidate scheme.

[0205] Figure 2 A flowchart illustrating a method for dynamically generating tokens according to another embodiment of this application is shown below. Figure 2 As shown, in Figure 1 Based on the illustrated embodiment, it may also include:

[0206] 201, in response to receiving the request content, token, and second session key identifier sent by the client.

[0207] The second session key identifier is used to uniquely identify the second session key.

[0208] The request content refers to the content that the client requests the server to process. For example, the request content may be a network data access request, a system resource access request, a user's personal information update request, etc. This application does not restrict the specific business type and specific content corresponding to the request content.

[0209] 202. Obtain the second session key corresponding to the second session key identifier from the correspondence table.

[0210] 203, in response to obtaining the second session key corresponding to the second session key identifier from the correspondence table, obtain the multiple sub-scheme identifiers included in the second session key.

[0211] If the second session key corresponding to the second session key identifier is obtained from the correspondence table, it means that the second session key identifier exists and is an authentic session key identifier. Otherwise, if the second session key corresponding to the second session key identifier is not obtained from the correspondence table, it means that the second session key identifier is a tampered session key identifier, and the subsequent process of this embodiment will not be executed, or a response message requiring authentication will be sent to the client.

[0212] In this embodiment, "first" and "second" are used only to distinguish different or potentially different referents. The second session key identifier represents the session key identifier received by the client. It may be an unaltered session key identifier issued by the server to the client. In this case, the second session key identifier is the same as the first session key identifier, and the multiple sub-scheme identifiers in the second session key identified by the second session key identifier are the sub-scheme identifiers of the multiple target sub-schemes in the first target scheme. Alternatively, the second session key identifier may also be a session key identifier that has been altered after being issued by the server. In this case, the second session key identifier is different from the first session key identifier.

[0213] 204, Based on the sub-scheme identified by the multiple sub-scheme identifiers, obtain valid data from the token.

[0214] The valid data consists of the values ​​assigned to each valid field (i.e., the fields that the token must include in the preset rules, such as token version number, token ID, token type, token source, token attribute, client current time, optional data, etc.). The token version number (specific value) is assigned by the server to the token used for this generation according to a preset allocation method (e.g., random allocation, sequential allocation). The values ​​of valid fields such as token ID, token type, token source, token attribute, client current time, and optional data are obtained and uploaded by the client. Depending on the application's business, optional data may include user input data, mouse movement data, keyboard input statistics, and environment-related data (e.g., window size, current operating system, CPU model, etc.). This application embodiment does not impose any restrictions on this.

[0215] For example, in one implementation, based on the sub-schemes identified by the multiple sub-scheme identifiers included in the second session key, it is possible to know the target encoding algorithm scheme, target encryption algorithm scheme, target verification algorithm scheme, target data storage location scheme, target redundant data insertion scheme, target data hiding scheme, target data interface scheme, target code execution flow scheme, and target code obfuscation scheme used in this token generation. Corresponding schemes can be used to extract valid data from the token. For instance, according to the target encoding algorithm scheme, a corresponding decoding algorithm is used to decode the data; according to the target encryption algorithm scheme, a corresponding decryption algorithm is used to decrypt the data; according to the target verification algorithm scheme, a corresponding verification algorithm is used to verify the data; after successful verification, redundant data is deleted according to the target redundant data insertion scheme; and the storage location of valid data is found and valid data is extracted according to the target data storage location scheme.

[0216] 205, responding to the receipt of valid data from the token, and processing the requested content.

[0217] Based on this embodiment, after the client generates a token based on the total code, it can return the received second session key identifier, the generated token, and the request content to the server. In this way, the server can obtain the corresponding second session key based on the second session key identifier, and extract valid data from the token according to the sub-scheme identified by the multiple sub-scheme identifiers in the second session key, thereby improving the security and identifiability of the token.

[0218] Optionally, in some implementations, in operation 102, a first session key can be generated based on the token version number, the sub-scheme identifiers of multiple target sub-schemes in the first target scheme, and the expiration time information of the first target scheme. In this case, the first session key also includes the expiration time information of the first target scheme.

[0219] The expiration time information can include the start time and the validity period. In specific implementation, the start time can be the time when the server generates the first target solution or the total code. The validity period can be set according to actual needs, or a period not greater than the preset period can be randomly selected as the validity period, and can be updated as needed, such as 30 seconds, 2 minutes, 1 hour, etc.

[0220] As shown in Table 2 below, this is a specific example of the data format of the session key (i.e., the first session key) generated by the server in this application embodiment. Those skilled in the art will know that the session key in this application embodiment can adopt any other format, and may also include other content besides that shown in Table 2.

[0221] Table 2

[0222]

[0223]

[0224] In Table 2, the Session Key is 16 bytes in size, and the size of each part of the Session Key is shown in Table 1. Based on the above data structure, the corresponding parts of the Session Key can be read from their respective positions. The identifier for each target sub-scheme is used to uniquely identify each target sub-scheme; it can be the name of the target sub-scheme or its number among multiple candidate schemes in its respective sub-scheme group. For example, the candidate schemes for the encryption algorithm scheme sub-scheme include AES128, AES256, 3DES, ..., and the corresponding encryption algorithm scheme identifiers can be pre-set as 1, 2, 3, ...; the candidate schemes for the encoding algorithm scheme sub-scheme include Base81, Base56, Base64, ..., and the corresponding encoding algorithm scheme identifiers can be pre-set as 1, 2, 3, ...; the candidate schemes for the verification algorithm scheme sub-scheme include MD5, hash1, hash256, CRC32, CRC16, CRC8, LRC, ..., and the corresponding verification algorithm scheme identifiers can be pre-set as 1, 2, 3, 4, 5, 6, 7, ... After reading the identifiers of each target sub-scheme from the corresponding positions in the Session Key, the target sub-scheme used in this Session Key can be determined based on the identifiers of each target sub-scheme. For example, if the information read from the second byte of the Session Key is 1, it indicates that the verification algorithm scheme identifier is 1. At this time, it can be determined that the verification algorithm scheme used to generate the token is MD5. If the information read from the third byte of the Session Key is 2, it indicates that the encryption algorithm scheme identifier is 2. At this time, it can be determined that the encryption algorithm scheme used to generate the token is AES256. And so on, the target sub-schemes used to generate the token can be determined.

[0225] Figure 3 A flowchart illustrating a method for dynamically generating tokens according to another embodiment of this application is shown below. Figure 3 As shown, in Figure 2 Based on the illustrated embodiment, operation 203 may include:

[0226] 2031, retrieve the expiration time information from the second session key.

[0227] 2032, confirm whether the second session key has expired based on the expiration time information in the second session key.

[0228] For example, based on the start time and validity period in the expiration time information of the second session key, the time when the server receives the token can be used as the current time to determine whether the token is within the validity period. If the token is within the validity period, it is confirmed that the second session key has not expired; otherwise, if the token is not within the validity period, it is confirmed that the second session key has expired.

[0229] 2033, in response to the second session key not expiring, retrieve the identifiers of multiple sub-schema included in the second session key.

[0230] Otherwise, if the second session key has not expired, operation 2033 and its subsequent processes will not be executed, or a response message requiring authentication will be sent to the client.

[0231] Based on the technical solution provided in this application, the first session key generated by the server also includes the expiration time information of the first target scheme. In this way, after receiving the second session key identifier returned by the client and obtaining the corresponding second session key, it is possible to confirm whether the second session key has expired based on the expiration time information in the second session key. Only when the second session key has not expired can the sub-scheme identified by the multiple sub-scheme identifiers in the second session key be obtained to extract valid data from the token. A shorter expiration time can be set to prevent attackers from reverse engineering the total code used to generate the token. Even if an attacker spends a lot of time reverse engineering a portion of the code used to generate the token, this portion of code has expired and cannot be integrated into an automated tool to automatically generate the token, thereby improving the security of the token.

[0232] Based on this embodiment, a shorter validity period can be set to prevent attackers from reverse engineering the total code used to generate tokens. Even if an attacker spends a lot of time reverse engineering a portion of the code used to generate tokens, this portion of code has expired and cannot be integrated into an automated tool to automatically generate tokens, thereby improving token security.

[0233] Optionally, in some implementations, after the first session key is generated by operation 102, the first session key can be encrypted using a preset encryption algorithm and a confidential server key to obtain an encrypted first session key. In operation 103, the correspondence between the encrypted first session key and the first session key identifier is stored in a correspondence table.

[0234] The server key can be generated by the server according to a preset method, such as random generation or generation using a preset algorithm; this embodiment does not impose any restrictions on this. The preset encryption algorithm can be a high-strength encryption algorithm, such as AES256, or other encryption algorithms with a strength no less than AES256. This preset encryption algorithm and the confidential server key are stored only on the server and will not be disseminated, thereby improving the confidentiality and security of the first session key.

[0235] Accordingly, in operation 202, the encrypted second session key corresponding to the second session key identifier is obtained from the correspondence table, and the encrypted second session key is decrypted using a preset encryption algorithm and a server key to obtain the second session key.

[0236] Based on this embodiment, the server can encrypt and store the first session key, which can improve the confidentiality and security of the first session key.

[0237] Optionally, in some implementations, in operation 106, the total code, the first session key identifier, and the pre-acquired client key can be sent to the client; wherein the client key is used as a client encryption token.

[0238] The client key can be generated by the server in a preset manner, such as random generation or generation using a preset algorithm. This application embodiment does not impose any restrictions on this.

[0239] When the server sends the main code, the first session key identifier, and the pre-acquired client key to the client, it can record the correspondence between the first session key identifier and the client key. Based on this correspondence, the server can determine the client key corresponding to the first session key identifier, which can then be used to decrypt the encrypted token sent by the client. The client ID is used to uniquely identify a client.

[0240] Alternatively, when the server sends the total code, the first session key identifier, and the pre-acquired client key to the client, it can also record the correspondence between the first session key identifier, the client key, and the client identifier (ID). Based on this correspondence, the server can determine the first session key identifier and the client key sent to the client, so as to use the client key to decrypt the encrypted token sent by the client.

[0241] Accordingly, in operation 201, the client sends a request, an encrypted token, and a second session key identifier. Accordingly, in operation 204, the encrypted token is decrypted using the client key to obtain the token, and then, based on the sub-scheme identified by the multiple sub-scheme identifiers in the second session key, valid data is obtained from the token.

[0242] Based on this embodiment, when the server sends the total code and the first session key to the client, it also sends the client key. In this way, after the client generates a token, it can directly use the client key to encrypt the token, which helps to improve the confidentiality and security of the token.

[0243] Optionally, in some implementations, before executing the embodiments of this application, the server and the client may use a preset method, such as Transport Layer Security (TLS) or a similar method, to perform two-way authentication to ensure that the total code used to generate the token and the first session key can be sent to the legitimate client, thereby improving data security.

[0244] Figure 4 This is a flowchart illustrating a method for dynamically generating tokens according to another embodiment of this application. This embodiment is applied to a client, such as... Figure 4 As shown.

[0245] 301, in response to receiving the total code and second session key identifier sent by the server.

[0246] The second session key identifier is used to uniquely identify the second session key. The second session key is generated based on the token version number and multiple sub-scheme identifiers corresponding to the second target scheme. The second session key includes multiple sub-scheme identifiers. The second target scheme includes multiple target sub-schemes corresponding to multiple sub-schemes, and the multiple sub-scheme identifiers are used to identify the multiple target sub-schemes. The multiple sub-schemes may include: algorithm-related schemes, data structure schemes, data interface schemes, code execution flow schemes, and code obfuscation schemes. Each of the multiple sub-schemes has multiple candidate schemes. The total code is obtained based on the sub-code corresponding to each target sub-scheme in the multiple target sub-schemes.

[0247] 302, Token generated based on total code.

[0248] 303 sends the request content, token, and second session key identifier to the server.

[0249] The request content refers to the content that the client requests the server to process. For example, the request content may be a network data access request, a system resource access request, a user's personal information update request, etc. This disclosure does not restrict the specific business type and specific content corresponding to the request content.

[0250] The client receives the master code and the second session key identifier sent by the server. Before sending each request to the server, the client generates a token based on the master code and then sends the request content, the token, and the second session key identifier together to the server.

[0251] In this way, because the total code used to generate tokens is different each time the server sends it to the client, the token generated by the client is also different each time. Through a massive number of token generation schemes and a dynamically adjusted token generation scheme strategy, the difficulty for attackers to reverse engineer the token generation code is greatly increased, effectively preventing attackers from integrating the token generation code into automated tools to automatically generate tokens, thus improving token security. Even if an attacker spends a lot of time reverse engineering a portion of the code used to generate a token in a particular instance, this portion of code is rendered invalid due to the dynamically adjusted token generation scheme strategy, making the attacker's reverse engineering of that portion of the code meaningless. Furthermore, this prevents attackers from using automated tools to automatically generate tokens using reverse-engineered code to access network data and system resources, or further tamper with or implant viruses into network data and system resources, effectively ensuring the security of network data and system resources.

[0252] Optionally, in some implementations, the algorithm-related schemes may include: encoding algorithm schemes, encryption algorithm schemes, and verification algorithm schemes; and / or, the data structure schemes may include: data storage location schemes, redundant data insertion schemes, and data hiding schemes.

[0253] Based on this embodiment, since the second target scheme includes multiple target sub-schemes corresponding to multiple sub-schemes, and since the multiple sub-schemes include: encoding algorithm scheme, encryption algorithm scheme, verification algorithm scheme, data storage location scheme, redundant data insertion scheme, data hiding scheme, data interface scheme, code execution flow scheme, and code obfuscation scheme, and each sub-scheme has multiple candidate schemes, the number of schemes that can be combined to generate tokens can reach hundreds or even tens of millions. Through a massive number of token generation schemes and dynamic adjustment of token generation scheme strategies, the difficulty of reverse engineering the token generation code by attackers is greatly increased, effectively preventing the token generation code from being reverse engineered by attackers. This makes it impossible for attackers to integrate the token generation code into automated tools to automatically generate tokens, thereby improving the security of the token.

[0254] Optionally, in some implementations, the second session key is generated based on the token version number, the identifiers of multiple sub-schemes corresponding to the second target scheme, and the expiration time information of the second target scheme. Accordingly, the second session key also includes the expiration time information of the second target scheme, so that the server can confirm whether the second session key has expired based on the expiration time information in the second session key.

[0255] The expiration time information can include the start time and the validity period. In specific implementation, the start time can be the time when the server generates the second target solution or the total code. The validity period can be set according to actual needs, or a period not greater than the preset period can be randomly selected as the validity period, and can be updated as needed, such as 30 seconds, 2 minutes, 1 hour, etc.

[0256] Based on this embodiment, a shorter validity period can be set to prevent attackers from reverse engineering the total code used to generate tokens. Even if an attacker spends a lot of time reverse engineering a portion of the code used to generate tokens, this portion of code has expired and cannot be integrated into an automated tool to automatically generate tokens, thereby improving token security.

[0257] Optionally, in some implementations, operation 301 may specifically involve receiving the total code, the second session key identifier, and the client key sent by the server. Accordingly, in this embodiment, after operation 302, the token may be encrypted using the client key to obtain an encrypted token; in operation 303, the request content, the encrypted token, and the second session key identifier are specifically sent to the server.

[0258] Based on this embodiment, after the client generates a token, it can directly use the client key to encrypt the token, which helps to improve the confidentiality and security of the token.

[0259] The following example illustrates the process of dynamically generating tokens according to an embodiment of this application:

[0260] S1, in response to the achievement of a preset trigger condition, the server determines the first target scheme of the total code used to generate the token according to a preset method. The first target scheme includes multiple target sub-schemes corresponding to multiple sub-schemes. These multiple sub-schemes may include, but are not limited to: encoding algorithm schemes, encryption algorithm schemes, verification algorithm schemes, data storage location schemes, redundant data insertion schemes, data hiding schemes, data interface schemes, code execution flow schemes, and code obfuscation schemes. Each of the multiple sub-schemes has multiple candidate schemes.

[0261] S2, the server generates the first session key based on the token version number, the sub-scheme identifiers of multiple target sub-schemes in the first target scheme, and the expiration time information of the first target scheme.

[0262] S3, the server uses a preset encryption algorithm and a confidential server key to encrypt the first session key, thus obtaining the encrypted first session key.

[0263] S4, the server assigns a first session key ID to the first session key and stores the correspondence between the encrypted first session key and the first session key ID in the correspondence table.

[0264] S5, the server obtains the sub-code corresponding to each of the multiple target sub-solutions.

[0265] S6, the server obtains the total code used to generate the token this time based on the sub-code corresponding to each of the multiple target sub-schemes.

[0266] S7, the server sends the total code, the first session key identifier, and the client key to the client.

[0267] S8, in response to receiving the total code, second session key identifier and client key sent by the server, the client generates a token based on the total code.

[0268] At this point, depending on whether the encrypted first session key identifier sent by the server has been tampered with, the second session key identifier received by the client will be either different from or the same as the first session key identifier sent by the server. If the first session key identifier sent by the server has not been tampered with, the second session key identifier received by the client is the same as the first session key identifier sent by the server; otherwise, if the first session key identifier sent by the server has been tampered with, the second session key identifier received by the client will no longer be the same as the first session key identifier sent by the server.

[0269] For example, in one implementation, the client executes the sub-code corresponding to the target code execution flow scheme in the main code. Following this flow, it executes the sub-codes corresponding to the target data interface scheme and target data structure scheme in the main code to pass valid data to the appropriate locations. This may involve executing sub-codes corresponding to the target data hiding scheme to perform data hiding operations on the valid data and invalid data in the main code. Then, following the order of the sub-codes for the target verification algorithm scheme, target encryption algorithm scheme, and target execution encoding algorithm scheme in the main code, the client performs corresponding verification, encryption, and encoding by executing the sub-codes for these schemes. The main code is obfuscated using a code obfuscation scheme.

[0270] S9, the client uses the client key to encrypt the token, obtaining the encrypted token.

[0271] S10, the client sends the request content, the encrypted token, and the second session key identifier to the server.

[0272] S11, in response to receiving the request content, encrypted token, and second session key identifier sent by the client, the server retrieves the second session key corresponding to the second session key identifier from the corresponding relationship table.

[0273] S12, in response to obtaining the second session key corresponding to the second session key identifier from the correspondence table, the server obtains the expiration time information in the second session key.

[0274] Otherwise, if the second session key is not obtained, this operation and subsequent processes will not be performed.

[0275] S13, the server confirms whether the second session key has expired based on the expiration time information in the second session key.

[0276] S14, in response to the second session key not expiring, the server obtains the identifiers of multiple sub-scheme included in the second session key.

[0277] Otherwise, if the second session key has expired, this operation and subsequent procedures will not be performed.

[0278] S15, the server uses the client key to decrypt the encrypted token and obtain the token.

[0279] S16, the server obtains valid data from the token based on the sub-scheme identified by the multiple sub-scheme identifiers included in the second session key.

[0280] For example, in one implementation, the server, based on the sub-scheme identifiers included in the second session key, can determine the target encoding algorithm scheme, target encryption algorithm scheme, target verification algorithm scheme, target data storage location scheme, target redundant data insertion scheme, target data hiding scheme, target data interface scheme, target code execution flow scheme, and target code obfuscation scheme used in generating the token. It can then employ corresponding schemes to extract valid data from the token. For instance, it can use the corresponding decoding algorithm to decode the data according to the target encoding algorithm scheme, the corresponding decryption algorithm to decrypt the data according to the target encryption algorithm scheme, the corresponding verification algorithm to verify the data according to the target verification algorithm scheme, delete redundant data according to the target redundant data insertion scheme, and find the storage location of the valid data and extract the valid data according to the target data storage location scheme.

[0281] S17, in response to obtaining valid data from the token, the server processes the request content sent by the client.

[0282] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

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

[0284] Figure 5 This is a schematic diagram of a device for dynamically generating tokens according to an embodiment of this application. The device for dynamically generating tokens in this embodiment is applied to a server and can be used to implement the various methods for dynamically generating tokens implemented in the server-side implementation of this application. For example... Figure 5 As shown, the device for dynamically generating tokens in this embodiment includes: a determining module 401, a first generating module 402, an allocating module 403, a first obtaining module 404, a second obtaining module 405, and a first sending module 406. Wherein:

[0285] The determining module 401 is used to determine, in response to the achievement of a preset triggering condition, a first target scheme for the total code used to generate the token in this instance, according to a preset method. The first target scheme includes multiple target sub-schemes corresponding to multiple sub-schemes. The multiple sub-schemes include: algorithm-related schemes, data structure schemes, data interface schemes, code execution flow schemes, and code obfuscation schemes. Each sub-scheme in the multiple sub-schemes has multiple candidate schemes.

[0286] The first generation module 402 is used to generate a first session key based on the token version number and the sub-scheme identifiers of the multiple target sub-schemes;

[0287] The allocation module 403 is used to allocate a first session key identifier to the first session key and store the correspondence between the first session key and the first session key identifier in a correspondence table; wherein, the first session key identifier is used to uniquely identify the first session key; and the sub-scheme identifier is used to uniquely identify a sub-scheme;

[0288] The first acquisition module 404 is used to acquire the sub-code corresponding to each target sub-scheme in the plurality of target sub-schemes respectively;

[0289] The second acquisition module 405 is used to acquire the total code used to generate the token this time based on the sub-code corresponding to each target sub-scheme in the plurality of target sub-schemes;

[0290] The first sending module 406 is used to send the total code and the first session key identifier to the client so that the client can generate a first token based on the total code.

[0291] For detailed implementation and specific operations of each module in the device for dynamically generating tokens in this embodiment, please refer to the method embodiments for dynamically generating tokens implemented by the server in the above application, which will not be repeated here.

[0292] Figure 6 This is a schematic diagram of a device for dynamically generating tokens according to another embodiment of this application. The device for dynamically generating tokens in this embodiment is applied to a client and can be used to implement the various methods for dynamically generating tokens implemented in the client described above in this application. Figure 6 As shown, the device for dynamically generating tokens in this embodiment includes: a receiving module 501, a second generating module 502, and a second sending module 503. Wherein:

[0293] The receiving module 501 is used to receive the total code and the second session key identifier sent by the server; wherein, the second session key identifier is used to uniquely identify the second session key; the second session key is generated based on the token version number and multiple sub-scheme identifiers corresponding to the second target scheme, and the second session key includes the multiple sub-scheme identifiers; the second target scheme includes multiple target sub-schemes corresponding to multiple sub-schemes, and the multiple sub-scheme identifiers are used to identify the multiple target sub-schemes; wherein, the multiple sub-schemes include: algorithm-related schemes, data structure schemes, data interface schemes, code execution flow schemes, and code obfuscation schemes; each of the multiple sub-schemes has multiple candidate schemes; the total code is obtained based on the sub-code corresponding to each target sub-scheme in the multiple target sub-schemes;

[0294] The second generation module 502 is used to generate a token based on the total code;

[0295] The second sending module 503 is used to send the request content, the token, and the second session key identifier to the server.

[0296] For detailed implementation and specific operations of each module in the device for dynamically generating tokens in this embodiment, please refer to the various methods for dynamically generating tokens implemented on the client side of this application, which will not be repeated here.

[0297] Figure 7 This is a schematic diagram of a system for dynamically generating tokens according to an embodiment of this application. This system for dynamically generating tokens can be used to implement the methods for dynamically generating tokens described in the above embodiments of this application. Figure 7As shown, the system for dynamically generating tokens in this embodiment includes: a server 701 and a client 702. Wherein:

[0298] Server 601, in response to the achievement of a preset trigger condition, determines a first target scheme for the total code used to generate the token, according to a preset method. The first target scheme includes multiple target sub-schemes corresponding to multiple sub-schemes. The multiple sub-schemes include: algorithm-related schemes, data structure schemes, data interface schemes, code execution flow schemes, and code obfuscation schemes. Each sub-scheme in the multiple sub-schemes has multiple candidate schemes. A first session key is generated based on the token version number and the sub-scheme identifiers of the multiple target sub-schemes. A first session key identifier is assigned to the first session key, and the correspondence between the first session key and the first session key identifier is stored in a correspondence table. The first session key identifier is used to uniquely identify the first session key; the sub-scheme identifier is used to uniquely identify a sub-scheme. The sub-codes corresponding to each target sub-scheme in the multiple target sub-schemes are obtained. Based on the sub-codes corresponding to each target sub-scheme in the multiple target sub-schemes, the total code used to generate the token is obtained. The total code and the first session key identifier are sent to the client so that client 602 can generate a token based on the total code.

[0299] Client 602 is configured to respond to receiving a total code and a second session key identifier sent by server 601; wherein, the second session key identifier is used to uniquely identify the second session key; the second session key is generated based on a token version number and multiple sub-scheme identifiers corresponding to the second target scheme, and the second session key includes the multiple sub-scheme identifiers; the second target scheme includes multiple target sub-schemes corresponding to multiple sub-schemes, and the multiple sub-scheme identifiers are used to identify the multiple target sub-schemes; wherein, the multiple sub-schemes include: algorithm-related schemes, data structure schemes, data interface schemes, code execution flow schemes, and code obfuscation schemes; each of the multiple sub-schemes has multiple candidate schemes; the total code is obtained based on the sub-codes corresponding to each target sub-scheme in the multiple target sub-schemes; a token is generated based on the total code; and the request content, the token, and the second session key identifier are sent to server 601.

[0300] In this application embodiment, the specific implementation of the server 601 and the client 602 can be referred to the apparatus of the method for dynamically generating tokens in the corresponding embodiments of this application above, and will not be repeated here.

[0301] In addition, this application also provides an electronic device, which includes:

[0302] One or more processors;

[0303] Storage device for storing one or more programs.

[0304] When the one or more programs are executed by the one or more processors, the one or more processors implement the method for dynamically generating tokens as described in any of the above embodiments of this application.

[0305] In addition, embodiments of this application also provide a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the method for dynamically generating tokens as described in any of the above embodiments of this application.

[0306] Figure 8 A schematic block diagram of an example electronic device 700 that can be used to implement embodiments of this application is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workbenches, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the application described and / or claimed herein.

[0307] like Figure 8 As shown, the electronic device 700 includes a computing unit 701, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 702 or a computer program loaded from a storage unit 708 into a random access memory (RAM) 703. The RAM 703 may also store various programs and data required for the operation of the electronic device 700. The computing unit 701, ROM 702, and RAM 703 are interconnected via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0308] Multiple components in electronic device 700 are connected to I / O interface 705, including: input unit 706, such as keyboard, mouse, etc.; output unit 707, such as various types of displays, speakers, etc.; storage unit 708, such as disk, optical disk, etc.; and communication unit 709, such as network card, modem, wireless transceiver, etc. Communication unit 709 allows electronic device 700 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0309] The computing unit 701 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 701 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 701 performs the various methods and processes described above, such as the method for detecting webshell files. For example, in some embodiments, the method for detecting webshell files may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 708. In some embodiments, part or all of the computer program may be loaded and / or installed on the electronic device 700 via ROM 702 and / or communication unit 709. When the computer program is loaded into RAM 703 and executed by the computing unit 701, one or more steps of the method for detecting webshell files described above may be performed. Alternatively, in other embodiments, the computing unit 701 may be configured to perform the method for detecting webshell files by any other suitable means (e.g., by means of firmware).

[0310] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0311] The program code used to implement the methods of this application may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0312] In the context of this application, 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. Machine-readable media 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 fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0313] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0314] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), the Internet, and blockchain networks.

[0315] Computer systems can include clients and servers. Clients and servers are generally geographically separated and typically interact via communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. A server can be a cloud server, also known as a cloud computing server or cloud host, a hosting product within the cloud computing service ecosystem, addressing the shortcomings of traditional physical hosts and VPS (Virtual Private Server, or simply "VPS") services, such as high management difficulty and weak business scalability. Servers can also be servers for distributed systems or servers incorporating blockchain technology.

[0316] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this application can be achieved, and this is not limited herein.

[0317] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for dynamically generating tokens, characterized in that, Applied to the server side, including: In response to the achievement of a preset triggering condition, a first target scheme for the total code used to generate the token is determined according to a preset method. The first target scheme includes multiple target sub-schemes corresponding to multiple sub-schemes. The multiple sub-schemes include: algorithm-related schemes, data structure schemes, data interface schemes, code execution flow schemes, and code obfuscation schemes. Each sub-scheme in the multiple sub-schemes has multiple candidate schemes. A first session key is generated based on the token version number and the sub-scheme identifiers of the multiple target sub-schemes; Assign a first session key identifier to the first session key, and store the correspondence between the first session key and the first session key identifier in a correspondence table; wherein, the first session key identifier is used to uniquely identify the first session key; the sub-scheme identifier is used to uniquely identify a sub-scheme; Obtain the sub-code corresponding to each of the multiple target sub-solutions; Based on the sub-codes corresponding to each of the multiple target sub-schemes, obtain the total code used to generate the token this time; The total code and the first session key identifier are sent to the client so that the client can generate a token based on the total code.

2. The method according to claim 1, characterized in that, The first target scheme for determining the total code used to generate the token in this instance, according to a preset method, includes: For each of the sub-solutions, one candidate solution is selected sequentially from the candidate solutions corresponding to each sub-solution as the target sub-solution for that sub-solution; or... For each of the sub-solutions, one candidate solution is randomly selected from the candidate solutions corresponding to each sub-solution as the target sub-solution.

3. The method according to claim 2, characterized in that, Also includes: Candidate solutions and corresponding sub-codes for each of the sub-solutions are pre-defined. or, The candidate schemes corresponding to each sub-scheme and the sub-codes corresponding to the candidate schemes are further updated.

4. The method according to any one of claims 1-3, characterized in that, The step of obtaining the sub-code corresponding to each of the plurality of target sub-solutions includes: The sub-codes corresponding to each target sub-scheme are obtained from the candidate schemes corresponding to each of the pre-set sub-schemes and the sub-codes corresponding to each candidate scheme.

5. The method according to any one of claims 1-3, characterized in that, Also includes: In response to receiving the request content, token, and second session key identifier sent by the client; Obtain the second session key corresponding to the second session key identifier from the correspondence table; In response to obtaining the second session key corresponding to the second session key identifier from the correspondence table, obtain the multiple sub-scheme identifiers included in the second session key; Valid data is obtained from the token based on the sub-scheme identified by the multiple sub-scheme identifiers; In response to obtaining valid data from the token, the request content is processed.

6. The method according to claim 5, characterized in that, The generation of the first session key based on the token version number and the sub-scheme identifiers of the multiple target sub-schemes includes: The first session key is generated based on the token version number, the sub-scheme identifiers of the multiple target sub-schemes, and the expiration time information of the first target scheme.

7. The method according to claim 6, characterized in that, The step of retrieving the second session key corresponding to the second session key identifier from the correspondence table, and retrieving multiple sub-scheme identifiers included in the second session key, includes: Obtain the expiration time information from the second session key; Confirm whether the second session key has expired based on the expiration time information in the second session key; In response to the second session key not expiring, the identifiers of multiple sub-scheme schemes included in the second session key are obtained.

8. The method according to claim 7, characterized in that, Sending the total code and the first session key identifier to the client includes: The total code, the first session key identifier, and the pre-acquired client key are sent to the client; wherein the client key is used by the client to encrypt the token.

9. The method according to claim 8, characterized in that, The received request content, token, and second session key identifier sent by the client include: The client sends the request content, the encrypted token, and the second session key identifier. The step of obtaining valid data from the token based on the sub-scheme identified by the plurality of sub-scheme identifiers includes: The encrypted token is decrypted using the client key to obtain the token; Based on the sub-scheme identified by the multiple sub-scheme identifiers, valid data is obtained from the token.

10. A method for dynamically generating tokens, characterized in that, Applied to a client, the method includes: In response to receiving the total code and second session key identifier sent by the server; wherein, the second session key identifier is used to uniquely identify the second session key; the second session key is generated based on the token version number and multiple sub-scheme identifiers corresponding to the second target scheme, and the second session key includes the multiple sub-scheme identifiers; the second target scheme includes multiple target sub-schemes corresponding to multiple sub-schemes, and the multiple sub-scheme identifiers are used to identify the multiple target sub-schemes; wherein, the multiple sub-schemes include: algorithm-related schemes, data structure schemes, data interface schemes, code execution flow schemes, and code obfuscation schemes; each of the multiple sub-schemes has multiple candidate schemes; the total code is obtained based on the sub-code corresponding to each target sub-scheme in the multiple target sub-schemes; Generate a token based on the total code; The request content, the token, and the second session key identifier are sent to the server.

11. The method according to claim 10, characterized in that, The second session key is generated based on the token version number, the multiple sub-scheme identifiers, and the expiration time information of the second target scheme.

12. The method according to claim 10 or 11, characterized in that, The received total code and second session key identifier sent by the server include: Receive the total code, the second session key identifier, and the client key sent by the server; After generating the token based on the total code, the process also includes: The token is encrypted using the client key to obtain an encrypted token; Sending the request content, the token, and the second session key identifier to the server includes: The request content, the encrypted token, and the encrypted second session key are sent to the server.

13. A device for dynamically generating tokens, characterized in that, Applied to the server side, including: The determination module is used to determine, in response to the achievement of a preset triggering condition, the first target scheme of the total code used to generate the token in this instance according to a preset method. The first target scheme includes multiple target sub-schemes corresponding to multiple sub-schemes. The multiple sub-schemes include: algorithm-related schemes, data structure schemes, data interface schemes, code execution flow schemes, and code obfuscation schemes. Each sub-scheme in the multiple sub-schemes has multiple candidate schemes. The first generation module is used to generate a first session key based on the token version number and the sub-scheme identifiers of the multiple target sub-schemes; The allocation module is used to allocate a first session key identifier to the first session key and store the correspondence between the first session key and the first session key identifier in a correspondence table; wherein, the first session key identifier is used to uniquely identify the first session key; and the sub-scheme identifier is used to uniquely identify a sub-scheme. The first acquisition module is used to acquire the sub-code corresponding to each of the multiple target sub-schemes; The second acquisition module is used to acquire the total code used to generate the token this time based on the sub-code corresponding to each target sub-scheme in the plurality of target sub-schemes; The first sending module is used to send the total code and the first session key identifier to the client so that the client can generate a token based on the total code.

14. A device for dynamically generating tokens, characterized in that, Applied to the client side, including: A receiving module is configured to respond to receiving a total code and a second session key identifier sent by the server; wherein, the second session key identifier is used to uniquely identify the second session key; the second session key is generated based on a token version number and multiple sub-scheme identifiers corresponding to the second target scheme, and the second session key includes the multiple sub-scheme identifiers; the second target scheme includes multiple target sub-schemes corresponding to multiple sub-schemes, and the multiple sub-scheme identifiers are used to identify the multiple target sub-schemes; wherein, the multiple sub-schemes include: algorithm-related schemes, data structure schemes, data interface schemes, code execution flow schemes, and code obfuscation schemes; each of the multiple sub-schemes has multiple candidate schemes; the total code is obtained based on the sub-code corresponding to each target sub-scheme in the multiple target sub-schemes; The second generation module is used to generate tokens based on the total code; The second sending module is used to send the request content, the token, and the second session key identifier to the server.

15. An electronic device, characterized in that, The electronic device includes: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1-12.

16. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-12.

Images