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

Abstract

The present application provides a method and device, an electronic device and a storage medium for dynamically generating tokens. The present application determines the first target scheme of the total code used for generating tokens each time in a preset manner in response to reaching a preset trigger condition, generates a 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 first verification value obtained by processing the sub-scheme identifiers of the multiple target sub-schemes using a preset verification algorithm, and obtains the sub-codes corresponding to each target sub-scheme respectively, and then obtains the total code based on the sub-codes corresponding to each target sub-scheme in the multiple target sub-schemes, and then sends the total code and the first session key to the client, so that the client generates a token based on the total code. In this way, through a large number of token generation schemes and dynamically adjusting the token generation scheme strategy, the difficulty of the code generated by the token being reversely analyzed by the attacker is greatly increased, thereby improving the security of the token.

Description

Technical field

[0001] The present application relates to network security technology, and in particular to a method and device for dynamically generating tokens, an electronic device, and a storage medium. [Background Technology]

[0002] With the development of internet technology, the amount of data and resources stored and provided via networks is increasing, and the resulting network security issues are becoming increasingly serious. Currently, network security threats are becoming increasingly severe, and various applications urgently need better security technologies. Protecting the security of data and resources stored on networks is becoming increasingly important.

[0003] Currently, a common method is for the client to generate a token as a temporary key and send it to the server. The token is equivalent to an account name and password, and is used to determine whether to allow the request and to identify the user who requested the token. It allows the client to access network data and system resources without providing a password or other credentials. The server verifies that the token is correct and determines whether the client can access network data and system resources.

[0004] In the process of implementing the present application, the inventor discovered through research that the code used by the client to generate tokens can be easily reverse-engineered by attackers. Afterwards, the attackers can use automated tools to automatically generate tokens using these codes and send them to the server. However, it is difficult for the server to distinguish whether the received token is sent by a user with access rights through the client or by the attacker. As a result, the attacker can access network data and system resources through the token, or further tamper with network data and system resources or implant viruses, which may cause great losses to users. [Summary of the invention]

[0005] Multiple aspects of the present application provide a method and device, an electronic device, and a storage medium for dynamically generating tokens, so as to increase the difficulty of reverse analysis of the code used to generate the tokens by attackers, thereby improving the security of the tokens.

[0006] In one aspect of the present application, a method for dynamically generating a token is provided, which is applied to a server and includes:

[0007] In response to a preset trigger condition being met, a first target solution for the total code used to generate the token is determined in a preset manner, wherein the first target solution includes multiple target sub-solutions corresponding to multiple sub-solutions; wherein the multiple sub-solutions include: an algorithm-related solution, a data structure solution, a data interface solution, a code execution process solution, and a code obfuscation solution; and each of the multiple sub-solutions has multiple candidate solutions.

[0008] generating a first session key based on the token version number, the sub-scheme identifiers of the multiple target sub-schemes, and a first verification value obtained by processing the sub-scheme identifiers of the multiple target sub-schemes using a preset verification algorithm; the sub-scheme identifier is used to uniquely identify a sub-scheme;

[0009] Respectively obtain a subcode corresponding to each target sub-scheme in the multiple target sub-schemes;

[0010] Based on the subcodes corresponding to the respective target sub-schemes in the plurality of target sub-schemes, obtaining a total code for generating the token this time;

[0011] The total code and the first session key are sent to the client, so that the client generates a token based on the total code.

[0012] Another aspect of the present application provides another method for dynamically generating a token, which is applied to a client, and the method includes:

[0013] In response to receiving the total code and second session key sent by the server; wherein the second session key is generated based on the token version number, multiple sub-scheme identifiers corresponding to the second target scheme, and a second verification value obtained by processing the multiple sub-scheme identifiers using a preset verification algorithm, and the second session key includes the multiple sub-scheme identifiers and the second verification value; the second target scheme includes multiple target sub-schemes corresponding to multiple sub-schemes; wherein the multiple sub-schemes include: an algorithm-related scheme, a data structure scheme, a data interface scheme, a code execution process scheme, and a code obfuscation scheme; 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 identified by the multiple sub-scheme identifiers;

[0014] generating a token based on the total code;

[0015] Send the request content, the token, and the second session key to the server.

[0016] In another aspect of the present application, a device for dynamically generating a token is provided, which is applied to a server, comprising:

[0017] a determination module, configured to determine, in response to a preset trigger condition being met, a first target solution for the total code currently used to generate the token in accordance with a preset method, wherein the first target solution includes multiple target sub-solutions corresponding to multiple sub-solutions; wherein the multiple sub-solutions include: an algorithm-related solution, a data structure solution, a data interface solution, a code execution process solution, and a code obfuscation solution; and each of the multiple sub-solutions has multiple candidate solutions;

[0018] A first generation module is configured to generate a first session key based on a token version number, sub-scheme identifiers of the multiple target sub-schemes, and a first verification value obtained by processing the sub-scheme identifiers of the multiple target sub-schemes using a preset verification algorithm; the sub-scheme identifier is used to uniquely identify a sub-scheme;

[0019] A first acquisition module is used to respectively acquire a subcode corresponding to each target sub-scheme in the multiple target sub-schemes;

[0020] A second acquisition module is configured to acquire a total code for generating a token this time based on a sub-code corresponding to each target sub-scheme in the plurality of target sub-schemes;

[0021] The first sending module is configured to send the total code and the first session key to the client, so that the client generates a token based on the total code.

[0022] In another aspect of the present application, another apparatus for dynamically generating a token is provided, which is applied to a client and includes:

[0023] A receiving module, configured to respond to receiving a total code and a second session key sent by a server; wherein the second session key is generated based on a token version number, multiple sub-scheme identifiers corresponding to a second target scheme, and a second verification value obtained by processing the multiple sub-scheme identifiers using a preset verification algorithm; the second session key includes the multiple sub-scheme identifiers and the second verification value; the second target scheme includes multiple target sub-schemes corresponding to multiple sub-schemes; wherein the multiple sub-schemes include: an algorithm-related scheme, a data structure scheme, a data interface scheme, a code execution process scheme, and a code obfuscation scheme; each of the multiple sub-schemes has multiple candidate schemes; and the total code is obtained based on the sub-code corresponding to each target sub-scheme in the multiple target sub-schemes identified by the multiple sub-scheme identifiers.

[0024] a second generating module, configured to generate a token based on the total code;

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

[0026] In another aspect of the present application, an electronic device is provided, comprising:

[0027] one or more processors;

[0028] a storage device for storing one or more programs,

[0029] 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 above aspect.

[0030] In another aspect of the present application, a computer-readable storage medium is provided, on which a computer program is stored. When the program is executed by a processor, the method for dynamically generating tokens provided in the above aspect is implemented.

[0031] 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 each time is different, so that the token generated by the client each time is also different. Since the first target scheme includes multiple target sub-schemes corresponding to multiple sub-schemes, and since the multiple sub-schemes include algorithm-related schemes, data structure schemes, data interface schemes, code execution process schemes, and code obfuscation schemes, each sub-scheme has multiple candidate schemes. Therefore, the schemes that can be combined to generate token codes can reach hundreds or even tens of millions. Through a large number of token generation schemes and dynamic adjustment of token generation scheme strategies, the difficulty of reverse analysis of token generation codes by attackers is greatly increased, effectively preventing the token generation codes from being reverse analyzed by attackers, making it impossible for attackers to integrate token generation codes into automated tools to automatically generate tokens, thereby improving the security of tokens. Even if an attacker spends a lot of time reverse-analyzing part of the code used to generate tokens, due to the dynamic adjustment of the token generation scheme strategy, this part of the code has become invalid, making the attacker's reverse analysis of the code used to generate tokens meaningless.

[0032] In addition, based on the technical solution provided in the present application, the server can generate a 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 first verification value obtained by processing the sub-scheme identifiers of multiple target sub-schemes using a preset verification algorithm, and send the total code for generating the token together with the first session key to the client. After the client generates the token based on the total code, it can return the received second session key and the generated token together to the server. In this way, the server can verify the second session key based on the verification value in the second session key returned by the client, which helps to identify whether the session key received by the client has been tampered with, thereby ensuring the security of the token.

[0033] In addition, based on the technical solution provided in the present application, the server can generate a first session key based on the token version number, the sub-scheme identifiers of multiple target sub-schemes, and a first verification value obtained by processing the sub-scheme identifiers of multiple target sub-schemes using a preset verification algorithm, and send the total code for generating the token together with the first session key to the client. After the client generates the token based on the total code, it can return the received second session key and the generated token together to the server. In this way, after the second key passes the verification, the server can verify the token and extract data 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.

[0034] In addition, based on the technical solution provided in this application, it is possible to prevent attackers from using automated tools to reverse-analyze the code to automatically generate tokens to access network data and system resources, or further tamper with or implant viruses into network data and system resources, thereby effectively ensuring the security of network data and system resources.

Brief Description of the Drawings

[0035] In order to more clearly illustrate the technical solutions in the embodiments of the present application, a brief introduction will be given below to the drawings required for use in the embodiments or descriptions of the prior art. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0036] Figure 1 A flowchart of a method for dynamically generating tokens provided in one embodiment of the present application;

[0037] Figure 2 A flowchart of a method for dynamically generating tokens provided in another embodiment of the present application;

[0038] Figure 3 A flowchart of a method for dynamically generating tokens provided in another embodiment of the present application;

[0039] Figure 4 A flowchart of a method for dynamically generating tokens provided in yet another embodiment of the present application.

[0040] Figure 5 A schematic diagram of the structure of an apparatus for dynamically generating tokens provided in one embodiment of the present application;

[0041] Figure 6 A schematic structural diagram of an apparatus for dynamically generating tokens provided in another embodiment of the present application;

[0042] Figure 7 A schematic diagram of the structure of a system for dynamically generating tokens provided in one embodiment of the present application;

[0043] Figure 8 FIG. 1 is a schematic block diagram of an exemplary electronic device that can be used to implement embodiments of the present application. [Specific implementation method]

[0044] To make the purpose, technical solutions, and advantages of the embodiments of this application more clear, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of this application. Obviously, the described embodiments are part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0045] It should be noted that the terminals involved in the embodiments of the present 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 (for example, smart glasses, smart watches, smart bracelets, etc.), etc.

[0046] Those skilled in the art will understand that the terms "first" and "second" in the embodiments of the present 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.

[0047] In this document, the term "and / or" simply describes a relationship between related objects, indicating that three possible relationships exist. For example, "A and / or B" can represent: A exists alone, A and B exist simultaneously, or B exists alone. Furthermore, the character " / " in this document generally indicates that the related objects are in an "or" relationship.

[0048] In related technologies, clients generate tokens based on fixed codes. For example, in one related technology, clients generate tokens using the following corresponding codes: using a fixed function interface and a fixed data format to input the data used to generate the token, then using a fixed verification algorithm to verify the data, using an encryption algorithm to encrypt it, and then using a fixed encoding algorithm to encode it. The order of generating the token is also fixed.

[0049] The following is an example of a client generating a token based on JavaScript code in the related art (javascript code):

[0050] function build_token(){

[0051] var data = [];

[0052] data[0] = token version number

[0053] / / Generate token ID according to certain rules

[0054] data[1] = Token ID

[0055] data[2] = token type

[0056] data[3] = token source

[0057] data[4] = token attributes

[0058] / / Get the current time of the client

[0059] data[5]=client current time

[0060] data[6] = optional data 1

[0061] data[7] = optional data 2

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

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

[0064] data[6+n]=CRC16 check value

[0065] / / Encrypted data

[0066] var encrypted_data=encrypt_by_aes256(data)

[0067] var cipher = []

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

[0069] cipher.push(encrypted_data)

[0070] / / Encoding data

[0071] var token=base64_encode(cipher)

[0072] return token;

[0073] }

[0074] Among them, function build_token() is the token generation function. The client generates a token by executing the code in functionbuild_token(). data[] represents the position of each field in the token's data structure. For example, data[0] = token version number indicates that the field "token version number" is at the 0th position in the token's data structure. data[1] = token ID indicates that the field "token ID" is at the 1st position in 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, aes256 encryption algorithm, and base64 encoding algorithm to sequentially generate tokens.

[0075] Because in related technologies, the client generates tokens based on fixed codes, and the codes used by the client to generate tokens can be easily reverse-engineered by attackers. Afterwards, attackers can use automated tools to automatically generate tokens using these codes and send them to the server. However, the server finds it difficult to distinguish whether the received token is sent by a user with access rights through the client or by an attacker. As a result, attackers can access network data and system resources through the token, or further tamper with network data and system resources or implant viruses, which may cause great losses to users.

[0076] Therefore, there is an urgent need to provide a method and device for dynamically generating tokens, an electronic device, and a computer-readable storage medium to increase the difficulty of reverse analysis of the code used to generate tokens by attackers, thereby improving the security of the tokens.

[0077] The design idea of ​​this application is that the server dynamically adjusts the scheme of the total code used to generate the token each time, ensuring that the total code sent to the client each time and used to generate the token is different, so that the token generated by the client each time is also different. Through a large number of token generation schemes and dynamic adjustment of the token generation scheme strategy, the difficulty of the code used to generate the token by the attacker is greatly increased, and the code used to generate the token is effectively prevented from being reverse analyzed by the attacker, so that the attacker cannot integrate the code used to generate the token into the automated tool to automatically generate the token, thereby improving the security of the token. Even if the attacker spends a lot of time to reverse analyze part of the code used to generate the token, due to the dynamic adjustment of the token generation scheme strategy, this part of the code has become invalid, making it meaningless for the attacker to reverse analyze the code used to generate the token.

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

[0079] Figure 1 This is a flow chart of a method for dynamically generating tokens provided in an embodiment of the present application. This embodiment is applied to the server, such as Figure 1 shown.

[0080] 101. In response to a preset trigger condition being met, a first target solution for the total code used to generate the token this time is determined in a preset manner.

[0081] The first target solution includes multiple target sub-solutions corresponding to the multiple sub-solutions.

[0082] Among them, the multi-part sub-scheme may include but is not limited to: an algorithm-related scheme, a data structure scheme, a data interface scheme, a code execution process scheme and a code obfuscation scheme. There are multiple candidate schemes for each of the multi-part sub-schemes. Each candidate scheme has a corresponding sub-scheme identifier (ID), wherein each sub-scheme identifier is used to uniquely identify a sub-scheme and can be pre-assigned by the server. The sub-scheme identifier can be, for example, a sub-scheme name, a sub-scheme number that is globally unique on the server, or a sub-scheme name and a sub-scheme number that is globally unique on the server, etc. The implementation of this application does not impose any restrictions on the specific composition of the sub-scheme identifier.

[0083] Among them, the algorithm-related scheme is the corresponding algorithm scheme used to process data (such as verification, encryption, encoding, etc.) when generating a token. The data structure scheme is used to determine the data structure of the token. It is the scheme for the data structure (such as location, hiding method, etc.) of each part of the data (i.e., field) involved in generating the token. The data interface scheme is the scheme for the interface form used when generating the token. The code execution process 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.

[0084] In the embodiment of the present application, the preset trigger condition is a condition preset by the server for triggering the generation of a total code for generating a token, so that the client can generate a token based on the total code. The preset trigger condition can be set according to actual needs. For example, in a specific implementation, the server can use real-time, random, or idle time as a preset trigger condition to trigger the generation of the total code for generating a token, execute operations 101-104 of this embodiment, and execute operation 105 when the client needs it later. For example, in another specific implementation, some preset user events can be used as preset trigger conditions. The server can monitor the preset user events through the client, such as whether there is a mouse input signal or keyboard input signal generated by a user operation. When the client monitors these user events, it will trigger the server to generate the total code for generating a token and execute operations 101-105 of this embodiment. For example, in yet another specific implementation, the server can use a preset period as a preset trigger condition, periodically trigger the generation of the total code for generating a token through a timer, execute operations 101-104 of this embodiment, and execute operation 105 when the client needs it later.

[0085] Thereafter, operations 102 and 103 may be performed respectively.

[0086] 102 , generating a first session key based on the token version number, the sub-scheme identifiers of the plurality of target sub-schemes, and a first verification value obtained by processing the sub-scheme identifiers of the plurality of target sub-schemes using a preset verification algorithm.

[0087] Among them, the token version number is the version number assigned by the server to the token used for generation 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. The embodiment of the present application does not limit the allocation method and composition of the token version number.

[0088] Therefore, the server can use the first session key to record the total code used to generate the token this time and the method used to generate the token.

[0089] Thereafter, operation 105 is performed.

[0090] 103 , respectively obtain a subcode corresponding to each target sub-scheme in the multiple target sub-schemes.

[0091] Operations 102 and 103 may be performed simultaneously or in any order, and this embodiment of the present application does not impose any limitation on this.

[0092] 104. Based on the subcodes corresponding to the target sub-schemes in the plurality of target sub-schemes, obtain a total code for generating the token this time.

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

[0094] 105 : Send the total code and the first session key to the client, so that the client generates a token based on the total code.

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

[0096] In this way, 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, resulting in a different token generated by the client each time. By using a large number of token generation schemes and dynamically adjusting the token generation scheme strategy, the difficulty of reverse engineering the token generation code by attackers is greatly increased, effectively preventing the token generation code from being reverse analyzed 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 tokens. Even if an attacker spends a considerable amount of time reverse engineering a portion of the code used to generate tokens, due to the dynamic adjustment of the token generation scheme strategy, this portion of code has been invalidated, making the attacker's attempt to reverse analyze the code used to generate tokens in that particular instance meaningless. Furthermore, this prevents attackers from using automated tools to automatically generate tokens using the reverse-analyzed code to access network data and system resources, or from further tampering with or injecting viruses into network data and system resources, effectively ensuring the security of network data and system resources.

[0097] Optionally, in some implementations, the algorithm-related schemes may include, but are not limited to: an encoding algorithm scheme, an encryption algorithm scheme, and a verification algorithm scheme.

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

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

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

[0101] The fields involved in generating a token may adopt different data structures in the token, so that the generated token may have different data structures.

[0102] In an embodiment of the present application, a data storage location scheme is used to determine the location of each field involved in generating a token in the token's data structure. In different data storage location schemes, the locations of each field involved in generating a token in the token's data structure are different or not completely the same, and even the location of the same field in the token's data structure is different. Based on the target data storage location scheme in the first session key, the server can determine the location of each field in the token's data structure, thereby extracting specific information about each field from the corresponding location.

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

[0104] 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 attributes, data[5] = client current time, ...;

[0105] 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 attributes, data[5] = token source, ...;

[0106] 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 attributes, data[5] = token version number, ...;

[0107] …

[0108] Data storage location scheme N:…

[0109] Among them, data[] represents the position of each field in the data structure of the token. For example, data[1] = token ID represents the first position of the field "token ID" in the data structure of the token.

[0110] In an embodiment of the present application, a redundant data insertion scheme is used to represent a scheme for inserting redundant data into a field that participates in generating a token. According to the redundant data insertion scheme, different amounts of redundant data can be inserted into 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 data structure of the token, and the redundant data assigned to each invalid field. According to the redundant data insertion scheme, different amounts of redundant data of invalid fields can be inserted into different positions in the field that participates in generating a token (for example, before or after a certain position in the data structure of the token).

[0111] For ease of distinction, in an embodiment of the present application, the fields involved in generating a token can be divided into valid fields and invalid fields, wherein the valid fields are the fields that the token needs to include in the preset rules, such as the token version number, token ID, token type, token source, token attributes, client current time, and some optional data. The specific information (i.e., assigned values) of these valid fields can be called valid data; the invalid fields are the fields inserted in the implementation of this application in addition to the valid fields specified in the above preset rules, which are used to increase the difficulty of reverse analysis of the code generating the token by attackers and improve the security of the token. The specific information (i.e., assigned 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 insertion redundant data scheme in the first session key, the server can determine the specific location of each valid field in the data structure of the token, thereby extracting the specific information of each valid field from the corresponding location; and by comparing the redundant data of each location in the target insertion redundant data scheme with the redundant data of the corresponding location in the token returned by the client, it can detect whether the total code sent by the server to the client has been reversed or tampered with.

[0112] For example, in a specific example, the following redundant data insertion scheme may be provided as a candidate scheme:

[0113] Insert redundant data scheme 1: 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, ...;

[0114] Insert redundant data 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, data[6] = random number, data[7] = random number, data[8] = random number, ...;

[0115] Insert redundant data scheme 3: data[0] = client current 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, ...;

[0116] …

[0117] Insert redundant data scheme N:…

[0118] The random number may be set by the server according to a preset rule, for example, it may be set to an integer greater than 0 and less than 255.

[0119] Based on the target insertion redundant data scheme in the first session key, after the server receives the token and the second session key returned by the client, it can extract only valid data (that is, the specific information or assignment of each valid field other than redundant data) from the corresponding position in the token according to the target data storage location scheme and the target insertion redundant data scheme; in addition, it can also detect whether the total code sent to the client has been tampered with by detecting 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 insertion redundant data scheme, or, based on the above-mentioned preset rule settings, if the value at each invalid field position in the token is 0 or 255, it can be directly determined that the total code sent to the client has been tampered with.

[0120] In the embodiment of the present application, the data hiding scheme is a scheme for hiding all fields or certain preset fields involved in generating a 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 that needs to be hidden, which can be for all fields or for one or several fields, and can be determined according to specific needs. The number of hidden fields targeted by each data hiding scheme can be consistent with or inconsistent with the total number of valid fields and invalid fields, and the embodiment of the present application does not limit this. For example, in a specific implementation, when the data hiding scheme targets certain preset fields involved in generating a token, if the number of hidden fields is greater than the total number of valid fields and invalid fields, only the valid fields and invalid fields involved in the hidden fields can be hidden; if the number of hidden fields is less than the total number of valid fields and invalid fields, only the corresponding hidden fields in the valid fields and invalid fields can be hidden. Through the data hiding scheme, each hidden field involved in generating a token can be subjected to a hiding operation (such as encryption and decryption, encoding and decoding, negation, XOR, shifting, 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 restore the hidden fields using corresponding restoration operations based on the target data hiding scheme in the first session key, thereby obtaining specific information of each hidden field.

[0121] As shown in Table 1 below, there are several optional data hiding methods for the data hiding schemes in the embodiments of the present application, as well as the corresponding hiding operations, restoration operations, and applicable scopes for hidden fields (i.e., the data forms that can be used as hidden fields) for each data hiding method.

[0122] Table 1

[0123]

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

[0125] 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, ...

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

[0127] 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 attributes + 0x99, data[9] = client current time + 0xAA, ...

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

[0129] 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, ...

[0130] 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], ...

[0131] …

[0132] Data hiding scheme N:…

[0133] In data hiding scheme 1, the data hiding method is exclusive OR (exclusive OR 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 also include exclusive OR (exclusive OR operator ^), addition (addition operator +, subtraction operator -), shift (left shift operator <<, right shift operator >>), and negation (negation operator ~). In practical applications, data hiding schemes can use the above data hiding methods individually or in combination.

[0134] In the embodiments of the present application, the data interface solution is the interface format used when generating tokens. The interface refers to the interface referenced by each execution unit when the client generates a token. The data interface solution may include any one or more of the following solutions: adding invalid parameters, data transmission, and data return.

[0135] Among them, the scheme 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 a token, so that the field used to generate the token includes one or more invalid parameters. Compared with the method of directly passing in valid parameters in related technologies, it can increase the difficulty for attackers to reverse analyze the code used to generate the token.

[0136] For example, in a specific example, taking the Session Key generated by the server as a parameter that needs to be passed in when generating a token, several candidate solutions for adding invalid parameters can be:

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

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

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

[0140] …

[0141] Invalid parameter scheme N: ...

[0142] Among them, function build_token() is an interface function. Invalid parameter solution 1 means that before the position where valid parameters are passed in, two invalid parameters are added, which are used to pass in random array 1 and random array 2, which are invalid for generating tokens. The third position is used to pass in the Session Key generated by the server. Invalid parameter solution 2 means that before the position where valid parameters are passed in, an invalid parameter is added, which is used to pass in a random number that is invalid for generating tokens. The second position is used to pass in the Session Key generated by the server. Invalid parameter solution 3 means that before the position where valid parameters are passed in, an invalid parameter is added, which is used to pass in random array 1, which is invalid for generating tokens. Two invalid parameters are added after the position where valid parameters are passed in, which are used to pass in random numbers that are invalid for generating tokens. The second position is used to pass in the Session Key generated by the server.

[0143] Among them, the data transmission scheme refers to a method of uploading parameters of each field to the token generation function used to generate the token, which may include but is not limited to: variable transfer method, array transfer method, object method transfer method, closure variable transfer method, global variable transfer method, object attribute transfer method, etc.

[0144] Among them, the data return scheme refers to the way in which the token generation function used to generate the token returns the token, which may include but is not limited to: direct variable return method, array return method, object method return method, closure variable return method, global variable return method, etc.

[0145] In practical applications, the invalid parameter addition scheme, data transmission scheme, and data return scheme can be used individually or in combination to effectively increase the difficulty for attackers to reverse analyze the code used to generate tokens.

[0146] In the embodiment of the present application, the code execution process scheme is a process scheme for generating tokens. The code execution process scheme may include any one or more of the following schemes: a traditional sequential execution process scheme, a timer scheme with a short time interval, a callback function scheme with the solution code passed as a parameter, a solution using a closure call, a solution using an object to encapsulate a process in the token generation, etc.

[0147] Among them, the traditional sequential execution process solution is to sequentially input the data used to generate the token, use the verification algorithm data for verification, use the encryption algorithm for encryption, and use the fixed encoding algorithm for encoding, and then execute the token generation in sequence.

[0148] Among them, a timer solution with a short time interval is used. That is, a short time interval is set by the timer, and the system calls the token generation function to execute the token generation process when the corresponding time is reached. The short time interval can be set according to actual needs, such as 0, a few milliseconds, a few seconds, or a few minutes. The timer can call the token generation function to execute the token generation process when the corresponding time is reached according to the set time interval.

[0149] For example, an example of using a timer with a short interval is: setTimeout(build_toke,0);

[0150] Among them, 0 is the time interval, 0 represents a higher priority, and the system calls the token generation function immediately after completing the current task to execute the token generation process.

[0151] By using a timer with a shorter time interval, the token generation process can be changed from a traditional synchronous execution process to an asynchronous execution process, which can effectively prevent attackers from tracking the token generation process and increase the difficulty for attackers to reverse analyze the code.

[0152] Among them, the callback function scheme that passes the scheme code as a parameter, that is, in the process of generating tokens, the sub-code of one or several target sub-schemes used to generate tokens are passed as parameters to the token generation function to confuse the token generation process and increase the difficulty for attackers to reverse analyze the code.

[0153] In specific applications, the subcodes of one or several target sub-schemes for generating tokens can be nested layer by layer, that is, the subcode of a target sub-scheme is passed as a parameter to the token generation function, and the subcode of another target sub-scheme is passed as a parameter in the subcode of the target sub-scheme, and so on, with the subcodes of different target sub-schemes being passed in layer by layer.

[0154] 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 subcode of the target encryption algorithm scheme is passed in as a parameter for execution. After the encryption is completed, the subcode of the target verification algorithm scheme is passed in as a parameter of the subcode of the target encryption algorithm scheme for execution. After the verification is completed, the subcode of the target encoding algorithm scheme is passed in as a parameter of the subcode of the target verification algorithm scheme for execution. That is, the subcode of the target encryption algorithm scheme, the subcode of the target verification algorithm scheme, and the subcode of the target encoding algorithm scheme are nested layer by layer and passed in as parameters in sequence.

[0155] The following is an example of a code implementation for a callback function solution that passes the solution code as a parameter:

[0156]

[0157]

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

[0159] Among them, the solution using closure calls implements a specific function by calling another function declared within the function that implements the corresponding function. A closure means that if function A declares function B and returns a variable that can reference a non-global variable, then function A is a closure. The function that serves as a closure is the sub-code corresponding to each target sub-solution. Using closure calls for the sub-code corresponding to different target sub-solutions can change the format of the sub-code relative to the atomic code, thereby achieving code obfuscation and increasing the difficulty for attackers to reverse-engineer the code.

[0160] The following is a code implementation example of using a closure call to pass in specific information about each field:

[0161]

[0162]

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

[0164] Among them, the solution of using objects to encapsulate a process in generating a token, that is, using objects to encapsulate the sub-code of a process in generating a token (such as assigning values ​​to various fields, the verification process, the encryption process, the encoding process, etc.). This can change the format of the sub-code of the corresponding link relative to the atomic code, thereby achieving code obfuscation and increasing the difficulty for attackers to reverse analyze the code.

[0165] The following is a code implementation example of using a closure call to pass in specific information about each field:

[0166]

[0167]

[0168] In the above code implementation example, obj.prepare_data = function (data) means using an object to encapsulate the subcode of the process of assigning values ​​to each field, obj.encrypt = encrypt_aes256 means using an object to encapsulate the subcode of the target encryption algorithm scheme in the encryption process, obj.encode = base64_encode means using an object to encapsulate the subcode of the target encoding scheme in the encoding process, and obj.build_token = function () means using an object to encapsulate the total code for generating a token.

[0169] In actual applications, each solution in the code execution process solution can be used individually or in combination, thereby effectively increasing the difficulty for attackers to reverse analyze the code used to generate tokens.

[0170] In the embodiment of the present 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.

[0171] The basic idea of ​​the CFF solution is to use a master dispatcher to control the execution flow of basic blocks within a program (main code or sub-code). This can obscure the context between basic blocks and increase the difficulty of program analysis. For example, in one specific example, replacing if-else statements with do-while statements and then using switch statements to control the flow can obscure the context between basic blocks.

[0172] Among them, the random addition of invalid codes scheme is to randomly add some invalid codes to the total code or sub-code to increase the difficulty of reversing the total code.

[0173] The following is a code implementation example of a scheme for randomly adding invalid codes:

[0174] build_token = function() {

[0175] this.prepare_data();

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

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

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

[0179] var cipher = []

[0180] a+=1 / / Invalid code

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

[0182] if(a){ / / Invalid judgment code: Because a+=1 has been executed, this must be true

[0183] cipher.push(encrypted_data)

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

[0185] }

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

[0187] return token;

[0188] }

[0189] In the above code implementation example, 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) are added to the token generation code.

[0190] The keyword extraction and hiding scheme extracts commonly used keywords (such as constants, constant strings, and constant constants) from the main code or sub-code and encrypts them using a preset method. These keywords are then decrypted and restored when used, preventing the plain text of commonly used keywords from appearing in the code. For example, to determine whether the code is formatted, the function function.toString() can be used to convert the code into text. After extracting and hiding toString, the usage becomes function[getProperty(11)](). getProperty(11) will return the string toString, where 11 is the index number of the string toString.

[0191] 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 expressed accordingly as: var$$1 = encrypt (data), or var_0x90a0f0 = encrypt (data).

[0192] Among them, the code content self-verification scheme converts the total code or the sub-code corresponding to a target sub-scheme into text, for example, using the function function.toString() to convert the sub-code corresponding to a target sub-scheme into text, and uses a preset verification algorithm to calculate the verification value of the text and store it on the server. After receiving the second session key returned by the client, the server can use the same method to calculate the verification value of the total code generated by the sub-codes corresponding to the multiple sub-scheme identifiers in the second session key, or the sub-code corresponding to one of the sub-scheme identifiers. The 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 the sub-code corresponding to the sub-scheme has been formatted or tampered with.

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

[0194] In the above embodiments, the CFF scheme, the random addition of invalid code scheme, the keyword extraction and hiding scheme, and the variable renaming scheme using different styles achieve the effect of code obfuscation, making the code difficult to be manually identified and reverse analyzed, and does not affect the client's execution of the code. The client can still identify and execute the obfuscated code.

[0195] In the algorithm-related schemes, data structure schemes, data interface schemes, code execution process schemes and code obfuscation schemes of the above-mentioned embodiments, the algorithm-related schemes (including the encoding algorithm scheme, the encryption algorithm scheme and the verification algorithm scheme) and the data structure scheme (including the data storage location scheme, the insertion of redundant data scheme and the data hiding scheme) will affect the specific content of the generated token, that is, the use of different encoding algorithm schemes, encryption algorithm schemes, verification algorithm schemes, data storage location schemes, insertion of redundant data schemes and data hiding schemes will result in different specific contents of the generated token; while the data interface scheme, code execution process scheme and code obfuscation scheme only affect the total code itself used to generate the token. The random combination of different data interface schemes, code execution process schemes and code obfuscation schemes will greatly increase the difficulty for attackers to reverse the total code, but will not affect the specific content of the generated token.

[0196] Optionally, in some of the implementations, in operation 101, in response to reaching a preset trigger condition, one candidate solution can be selected in sequence from the candidate solutions corresponding to each partial sub-solution as the target sub-solution corresponding to each partial sub-solution; or, one candidate solution can be randomly selected from the candidate solutions corresponding to each partial sub-solution as the target sub-solution corresponding to each partial sub-solution.

[0197] Based on this embodiment, the target sub-scheme corresponding to each partial sub-scheme can be dynamically determined, so that the target scheme of the code used to generate the token changes dynamically each time, which greatly increases the difficulty of the code generating the token being reverse analyzed by the attacker, and effectively prevents the code generating the token from being reverse analyzed by the attacker, so that the attacker cannot integrate the code generating the token into the automation tool to automatically generate the token.

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

[0199] Based on this embodiment, each sub-scheme in the target scheme of the code for generating tokens can be dynamically updated, thereby further increasing the difficulty of reverse analysis of the scheme or code for generating tokens by attackers.

[0200] Optionally, in some implementations, in operation 103 , the subcode corresponding to each target sub-scheme may be obtained from the preset candidate schemes corresponding to each partial sub-scheme and the subcode corresponding to each candidate scheme.

[0201] Figure 2 A flowchart of a method for dynamically generating tokens provided in another embodiment of the present application is shown in FIG. Figure 2 As shown, in Figure 1 Based on the embodiment shown, the following may also be included:

[0202] 201 : In response to receiving the request content, the token, and the second session key used to generate the token sent by the client.

[0203] The second session key includes multiple sub-scheme identifiers and a second verification value.

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

[0205] In the embodiments of this application, the terms "first" and "second" are used only to distinguish between different or potentially different referents. The second session key represents the session key received by the client. It may be the unaltered session key issued by the server to the client, in which case the second session key is the first session key. Alternatively, the second session key may be a session key issued by the server that has been tampered with, in which case the second session key is different from the first session key.

[0206] 202. Use a preset verification algorithm to process multiple sub-scheme identifiers in the second session key to obtain a third verification value.

[0207] 203 : Based on whether the second check value and the third check value are the same, confirm whether the second session key is consistent with the first session key issued to the client.

[0208] That is, in operation 203, the server can compare whether the second verification value is the same as the third verification value. If the second verification value is the same as the third verification value, it can be considered that the second session key is consistent with the first session key issued to the client, and the first session key issued to the client has not been tampered with, and operation 204 is executed; otherwise, if the second verification value is different from the third verification value, it can be considered that the second session key is inconsistent with the first session key issued to the client, and the subsequent process of this embodiment is not executed, or a response message requiring identity authentication is further fed back to the client.

[0209] 204. Obtain valid data from the token based on the sub-scheme identified by the multiple sub-scheme identifiers in the second session key.

[0210] The valid data is the value assigned to each valid field (i.e., the fields that the token needs to include in the preset rules, such as token version number, token ID, token type, token source, token attributes, client current time, optional data, etc.), wherein the token version number (specific assignment) is assigned by the server to the token used for generation this time according to a preset allocation method (such as random allocation, sequential allocation), and the value assignment of valid fields such as token ID, token type, token source, token attributes, client current time, optional data, etc. is obtained and uploaded by the client. Depending on the application business, the 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 embodiments of the present application do not impose any restrictions on this.

[0211] For example, in one implementation, based on the sub-scheme identified by the multiple sub-scheme identifiers included in the second session key, 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 process scheme and target code obfuscation scheme used to generate the token this time can be known, and the corresponding scheme can be used to extract valid data from the token. For example, according to the target encoding algorithm scheme, the corresponding decoding algorithm is used to decode the data, according to the target encryption algorithm scheme, the corresponding decryption algorithm is used to decrypt the data, and according to the target verification algorithm scheme, the corresponding verification algorithm is used to verify the data. After the verification is passed, the redundant data is deleted according to the target redundant data insertion scheme, and the storage location of the valid data is found according to the target data storage location scheme to extract the valid data.

[0212] 205 : In response to obtaining valid data from the token, process the request content sent by the client.

[0213] Based on this embodiment, after the client generates a token based on the total code, it can return the received second session key and the generated token together to the server. In this way, the server can verify the second session key based on the verification value in the second session key returned by the client, which helps to identify whether the session key received by the client has been tampered with, thereby ensuring the security of the token; after the second key passes the verification, the server can verify and extract data from the token based on the sub-scheme identifiers of multiple target sub-schemes in the second session key, thereby improving the security and identifiability of the token.

[0214] Optionally, in some implementations, in operation 102, a first session key may be generated based on the token version number, sub-scheme identifiers of multiple target sub-schemes in the first target scheme, the first check value, 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.

[0215] The expiration time information may include a starting time and a valid duration. In a specific implementation, the starting time may be the time when the server generates the first target solution or the total code; the valid duration may be set according to actual needs, or a duration not greater than a preset duration may be randomly selected as the valid duration, and may be updated as needed, for example, to 30 seconds, 2 minutes, 1 hour, etc.

[0216] As shown in Table 2 below, a specific example of the data format of the session key (i.e., the first session key) generated by the server in an embodiment of the present application is provided. Those skilled in the art will appreciate that the session key (Session Key) in the embodiment of the present application may adopt any other format and may include other content in addition to that shown in Table 2.

[0217] Table 2

[0218]

[0219]

[0220] In Table 2, the Session Key is 16 bytes in size, and the size of each component of the Session Key is shown in Table 1. Based on the above data structure, each component of the Session Key can be read from the corresponding position in the Session Key. Each target sub-scheme identifier is used to uniquely identify each target sub-scheme and can be the name of each target sub-scheme or the number of each target sub-scheme among the multiple candidate sub-schemes of the sub-scheme to which it belongs. For example, the multiple candidate schemes of the encryption algorithm scheme include AES128, AES256, 3DES, ..., and the corresponding encryption algorithm scheme identifiers can be pre-set as 1, 2, 3, ... in sequence; the multiple candidate schemes of the encoding algorithm scheme include Base81, Base56, Base64, ..., and the corresponding encoding algorithm scheme identifiers can be pre-set as 1, 2, 3, ... in sequence; the multiple candidate schemes of the verification algorithm 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, ... in sequence. After reading the identifiers of each target sub-scheme from the corresponding position 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, when the information read from the second byte of the Session Key is 1, it means 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 this time is MD5; when the information read from the third byte of the Session Key is 2, it means 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 this time is AES256; ..., and so on, the target sub-schemes used to generate the token this time can be determined.

[0221] Figure 3 A flowchart of a method for dynamically generating tokens provided in another embodiment of the present application is shown as follows: Figure 3 As shown, in Figure 2 Based on the embodiment shown, after operation 201, the following steps may be further included:

[0222] 301. Obtain expiration time information in the second session key.

[0223] 302: Determine whether the second session key is expired based on the expiration time information in the second session key.

[0224] In response to the second session key not being expired, operation 202 is started; otherwise, operation 202 and its subsequent processes are not performed, or a response message indicating that identity authentication is required is further fed back to the client.

[0225] For example, based on the start time and validity period in the expiration time information in 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.

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

[0227] Optionally, in some implementations, in operation 105, the first session key may be encrypted using a preset encryption algorithm and a confidential server key to obtain the encrypted first session key, and then the total code and the encrypted first session key may be sent to the client. The server key may be generated by the server according to a preset method, such as randomly generated or generated using a preset algorithm, and this embodiment of the present application does not limit this.

[0228] The preset encryption algorithm can be an encryption algorithm with higher encryption strength, such as AES256 or another encryption algorithm with encryption strength not less than AES256. The preset encryption algorithm and the confidential server key are only stored on the server and are not distributed or transmitted to the client, thereby improving the confidentiality and security of the first session key.

[0229] Accordingly, in operation 201, the request content, token, and encrypted second session key sent by the client are received. After operation 201, the encrypted second session key can be decrypted using a preset encryption algorithm and the server key. In response to the decryption of the second session key, operation 301 is executed. Otherwise, if the second session key is not decrypted, it means that the encrypted second session key sent by the client is not the encrypted first session key previously sent by the server to the client. In this case, the encrypted first session key sent by the server to the client may have been tampered with or is forged information. In this case, operation 301 and its subsequent processes are not executed, or a response message indicating that identity authentication is required is fed back to the client.

[0230] Based on this embodiment, the client uses a preset encryption algorithm and a confidential server key to encrypt the first session key, and then sends the encrypted first session key and the total code to the client. Since the preset encryption algorithm and the confidential server key are only stored on the server and only the server can know them, the confidentiality and security of the first session key can be improved.

[0231] Optionally, in some implementations, in operation 105, when sending the total code and the encrypted first session key to the client, the total code, the encrypted first session key, and a pre-acquired client key may be sent to the client; the client key is used to encrypt the client token. The client key may be generated by the server according to a preset method, such as random generation or generation using a preset algorithm, and this embodiment of the application is not limited thereto.

[0232] When the server sends the total code, the encrypted first session key, and the pre-acquired client key to the client, it can record the session key identifier (ID) of the encrypted first session key, and the correspondence between the client key and the client identifier (ID), so that based on the correspondence, the first session key and the client key sent to the client can be determined, where the session key ID is used to uniquely identify a session key, and the client ID is used to uniquely identify a client.

[0233] Accordingly, in operation 201, the request content, the encrypted token, and the encrypted second session key sent by the client are received. Accordingly, in operation 204, the encrypted token is decrypted using the client key to obtain the token; then, valid data is obtained from the token based on the sub-scheme identified by the multiple sub-scheme identifiers in the second session key.

[0234] Based on this embodiment, the server sends the client key at the same time as the total code and the encrypted first session key to the client. In this way, after the client generates the second token, it can directly use the client key to encrypt the token, which helps to improve the confidentiality and security of the token.

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

[0236] Figure 4 A flowchart of a method for dynamically generating a token according to another embodiment of the present application is provided. This embodiment is applied to a client, such as Figure 4 shown.

[0237] 401: In response to receiving the total code and the second session key sent by the server.

[0238] Among them, the second session key is generated based on the token version number, multiple sub-scheme identifiers corresponding to the second target scheme, and a second verification value obtained by processing the multiple sub-scheme identifiers corresponding to the second target scheme using a preset verification algorithm. The second session key includes multiple sub-scheme identifiers corresponding to the second target scheme and the second verification value.

[0239] The second target solution includes multiple target sub-solutions corresponding to the multiple sub-solutions. The multiple sub-solutions may include: an algorithm-related solution, a data structure solution, a data interface solution, a code execution process solution, and a code obfuscation solution. Each of the multiple sub-solutions has multiple candidate solutions. The total code is obtained based on the sub-codes corresponding to each target sub-solution in the multiple target sub-solutions identified by the multiple sub-solution identifiers.

[0240] 402, Generate token based on total code.

[0241] Specifically, by sequentially executing the sub-codes corresponding to each target sub-scheme in the total code after obfuscation based on the code obfuscation scheme, according to the corresponding target code execution process scheme, the target data interface scheme is used to pass valid data to the corresponding position (that is, assign values ​​to each valid field involved in generating the token respectively), and performing corresponding processing based on the target algorithm-related scheme to obtain the token.

[0242] For example, in one implementation, for the total code obfuscated based on the code obfuscation scheme, by executing the sub-code corresponding to the target code execution process scheme in the total code, according to the corresponding target code execution process scheme, by executing the sub-code corresponding to the target data interface scheme and the target data structure scheme in the total code, the target data interface scheme is used to pass valid data to the corresponding position, wherein the sub-code corresponding to the target data hiding scheme may be executed to perform some corresponding data hiding operations on the valid data passed in and the invalid data in the total code; then, according to the sub-code order of the target verification algorithm scheme, the target encryption algorithm scheme, and the target execution encoding algorithm scheme in the total code, the corresponding verification, encryption, and encoding are performed by executing the sub-code of the target verification algorithm scheme, the target encryption algorithm scheme, and the target execution encoding algorithm scheme.

[0243] 403. Send the request content, token, and second session key to the server.

[0244] The request content is the content that the client requests the server to process. For example, the request content can be a network data access request, a system resource access request, a user personal information update request, etc. The implementation of this disclosure does not limit the specific business type and specific content corresponding to the request content.

[0245] The client receives the total code and the second session key sent by the server, generates a token based on the total code before sending a request content to the server each time, and then sends the request content, the token, and the second session key together to the server.

[0246] In this way, since the total token code sent by the server to the client each time is different, the token generated by the client each time is also different. The massive number of token generation schemes and the dynamically adjusted token generation scheme strategy greatly increase the difficulty of reverse analysis of the token generation code by attackers, effectively preventing the token generation code from being reverse analyzed 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. Even if an attacker spends a lot of time reverse-analyzing part of the code used to generate tokens, due to the dynamic adjustment of the token generation scheme strategy, this part of the code has become invalid, making the attacker's reverse analysis of the code used to generate tokens in a specific time meaningless. In addition, it prevents attackers from using automated tools to automatically generate tokens using the reverse-analyzed code to access network data and system resources, or further tamper with network data and system resources or insert viruses, effectively protecting the security of network data and system resources.

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

[0248] Based on this embodiment, since the second target scheme includes multiple target sub-schemes corresponding to the 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 process scheme and code obfuscation scheme, each sub-scheme has multiple candidate schemes, then the schemes that can be combined to generate token codes can reach hundreds or even tens of millions. Through a large number of token generation schemes and dynamically adjusted token generation scheme strategies, the difficulty of reverse analysis of the token generation code by attackers is greatly increased, and the token generation code is effectively prevented from being reverse analyzed by attackers, so that attackers cannot integrate the token generation code into automated tools to automatically generate tokens, thereby improving the security of tokens.

[0249] Optionally, in some implementations, the second session key is generated based on the token version number, multiple sub-scheme identifiers corresponding to the second target scheme, the second verification value, 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 is expired based on the expiration time information in the second session key.

[0250] The expiration time information may include a starting time and a valid duration. In a specific implementation, the starting time may be the time when the server generates the second target solution or the total code; the valid duration may be set according to actual needs, or a duration not greater than a preset duration may be randomly selected as the valid duration, and may be updated as needed, for example, to 30 seconds, 2 minutes, 1 hour, etc.

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

[0252] Optionally, in some implementations, in operation 401 , the total code and the encrypted second session key sent by the server may be received.

[0253] Based on this embodiment, since the second session key sent by the server is encrypted, the confidentiality and security of the second session key can be improved.

[0254] Optionally, in some implementations, in operation 401, the total code, the encrypted second session key, and the client key sent by the server may be received. Accordingly, in this embodiment, after operation 402, the token may be encrypted using the client key to obtain an encrypted token; and in operation 403, the request content, the encrypted token, and the encrypted second session key may be sent to the server.

[0255] 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.

[0256] The following uses a specific application as an example to further illustrate the process of dynamically generating tokens in accordance with an embodiment of the present application:

[0257] S1. In response to a preset trigger condition being met, the server determines, in a preset manner, a first target solution for the total code used to generate the token. The first target solution includes multiple target sub-solutions corresponding to multiple sub-solutions. These multiple sub-solutions may include, but are not limited to, an encoding algorithm solution, an encryption algorithm solution, a validation algorithm solution, a data storage location solution, a redundant data insertion solution, a data hiding solution, a data interface solution, a code execution process solution, and a code obfuscation solution. Each of these multiple sub-solutions may have multiple candidate solutions.

[0258] S2, the server generates a first session key based on the token version number, the sub-scheme identifiers of multiple target sub-schemes in the first target scheme, the first verification value obtained by processing the sub-scheme identifiers of multiple target sub-schemes in the first target scheme using a preset verification algorithm, and the expiration time information of the first target scheme.

[0259] S3. The server encrypts the first session key using a preset encryption algorithm and a confidential server key to obtain an encrypted first session key.

[0260] S4. The server obtains the subcode corresponding to each target sub-scheme in the multiple target sub-schemes.

[0261] S5. The server obtains the total code used to generate the token this time based on the sub-code corresponding to each target sub-scheme in the multiple target sub-schemes.

[0262] S6: The server sends the total code, the encrypted first session key, and the client key to the client.

[0263] S7: In response to receiving the total code, the encrypted second session key, and the client key from the server, the client generates a token based on the total code. The second session key includes multiple sub-scheme identifiers and a second check value. The sub-schemes identified by the multiple sub-scheme identifiers can be considered as the multiple sub-schemes included in the second target scheme.

[0264] At this time, depending on whether the encrypted first session key sent by the server has been tampered with, the encrypted second session key received by the client is different from or the same as the encrypted first session key sent by the server. If the encrypted first session key sent by the server has not been tampered with, the encrypted second session key received by the client is the encrypted first session key sent by the server, and the second target scheme is the first target scheme; otherwise, if the encrypted first session key sent by the server has been tampered with, the encrypted second session key received by the client is no longer the encrypted first session key sent by the server, and the second target scheme is also different from the first target scheme. The second session key includes multiple sub-scheme identifiers and a second verification value. Depending on whether the second session key is a tampered session key, the multiple sub-scheme identifiers and second verification value in the second session key are the same as or at least partially different from the sub-scheme identifiers and first verification values ​​of the multiple target sub-schemes in the first session key.

[0265] For example, in one implementation, the client executes the subcode corresponding to the target code execution process scheme in the overall code, and according to the corresponding target code execution process scheme, executes the subcode corresponding to the target data interface scheme and the target data structure scheme in the overall code, and transmits valid data to the corresponding location. The subcode corresponding to the target data hiding scheme may be executed to perform some corresponding data hiding operations on the valid data and invalid data in the overall code; then, according to the subcode sequence of the target validation algorithm scheme, target encryption algorithm scheme, and target execution encoding algorithm scheme in the overall code, the client performs corresponding verification, encryption, and encoding by executing the subcode of the target validation algorithm scheme, target encryption algorithm scheme, and target execution encoding algorithm scheme. The overall code is the code obfuscated based on the code obfuscation scheme.

[0266] S8: The client encrypts the token using the client key to obtain an encrypted token.

[0267] S9: The client sends the request content, the encrypted token, and the encrypted second session key to the server.

[0268] S10 , in response to receiving the request content, the encrypted token, and the encrypted second session key sent by the client, decrypting the encrypted second session key using the server key.

[0269] S11 , in response to obtaining the second session key through decryption, the server obtains expiration time information in the second session key.

[0270] Otherwise, if the second session key is not decrypted, the subsequent process will not be performed.

[0271] S12: The server confirms whether the second session key has expired based on the expiration time information in the second session key.

[0272] S13, in response to the second session key not being expired, the server processes the multiple sub-scheme identifiers in the second session key using a preset verification algorithm to obtain a third verification value.

[0273] Otherwise, if the second session key has expired, the subsequent process will not be performed.

[0274] S14: The server confirms whether the second session key is consistent with the first session key sent to the client based on whether the second check value is the same as the third check value.

[0275] S15, if the second check value is the same as the third check value, the second session key is consistent with the first session key, and the server uses the client key to decrypt the encrypted token to obtain the token.

[0276] Otherwise, if the second verification value is different from the third verification value, the subsequent process is not performed.

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

[0278] For example, in one implementation, the server can 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 process scheme and target code obfuscation scheme used to generate the token this time based on the sub-scheme identified by the multiple sub-scheme identifiers included in the second session key, and can use the corresponding scheme to extract valid data from the token, for example, according to the target encoding algorithm scheme, use the corresponding decoding algorithm to decode the data, according to the target encryption algorithm scheme, use the corresponding decryption algorithm to decrypt the data, according to the target verification algorithm scheme, use the corresponding verification algorithm to verify the data, according to the target redundant data insertion scheme, delete redundant data, and according to the target data storage location scheme, find the storage location of the valid data and extract the valid data.

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

[0280] It should be noted that for the aforementioned method embodiments, for simplicity of description, they are all expressed as a series of action combinations, but those skilled in the art should be aware that this application is not limited by the order of the actions described, because according to this application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily required by this application.

[0281] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0282] Figure 5 This is a schematic diagram of the structure of a device for dynamically generating tokens provided in one embodiment of the present application. The device for dynamically generating tokens in this embodiment is applied to the server and can be used to implement the various methods for dynamically generating tokens implemented by the server mentioned above. Figure 5 As shown, the apparatus for dynamically generating a token in this embodiment includes: a determination module 501, a first generation module 502, a first acquisition module 503, a second acquisition module 504, and a first sending module 505. Among them:

[0283] Determination module 501 is configured to determine, in response to a preset trigger condition being met, a first target solution for the overall code used to generate the token in a preset manner, wherein the first target solution includes multiple target sub-solutions corresponding to multiple sub-solutions; wherein the multiple sub-solutions include: an algorithm-related solution, a data structure solution, a data interface solution, a code execution process solution, and a code obfuscation solution; and each of the multiple sub-solutions has multiple candidate solutions.

[0284] A first generating module 502 is configured to generate a first session key based on the token version number, the sub-scheme identifiers of the multiple target sub-schemes, and a first verification value obtained by processing the sub-scheme identifiers of the multiple target sub-schemes using a preset verification algorithm; wherein the sub-scheme identifier is used to uniquely identify a sub-scheme;

[0285] A first acquisition module 503 is configured to respectively acquire a subcode corresponding to each target sub-scheme in the plurality of target sub-schemes;

[0286] A second acquisition module 504 is configured to acquire a total code for generating a token this time based on the sub-code corresponding to each target sub-scheme in the multiple target sub-schemes;

[0287] The first sending module 505 is configured to send the total code and the first session key to the client, so that the client generates a token based on the total code.

[0288] The detailed implementation and specific operations of each module in the device for dynamically generating tokens in this embodiment can be found in the method embodiments for dynamically generating tokens implemented by the above-mentioned server side of this application, and will not be repeated here.

[0289] Figure 6 This is a schematic diagram of the structure of a device for dynamically generating tokens provided in another embodiment of the present application. The device for dynamically generating tokens in this embodiment is applied to the client and can be used to implement the various methods for dynamically generating tokens implemented by the client mentioned above. Figure 6 As shown, the apparatus for dynamically generating tokens in this embodiment includes: a receiving module 601, a second generating module 602, and a second sending module 603.

[0290] Receiving module 601 is configured to receive a total code and a second session key sent by a server; wherein the second session key is generated based on a token version number, multiple sub-scheme identifiers corresponding to a second target scheme, and a second verification value obtained by processing the multiple sub-scheme identifiers using a preset verification algorithm; the second session key includes the second target scheme and the second verification value; the second target scheme includes multiple target sub-schemes corresponding to multiple sub-schemes; wherein the multiple sub-schemes include: an algorithm-related scheme, a data structure scheme, a data interface scheme, a code execution process scheme, and a code obfuscation scheme; each of the multiple sub-schemes has multiple candidate schemes; and the total code is obtained based on the sub-code corresponding to each target sub-scheme in the multiple target sub-schemes identified by the multiple sub-scheme identifiers.

[0291] A second generating module 602 is configured to generate a token based on the total code;

[0292] The second sending module 603 is configured to send the request content, the token, and the second session key to the server.

[0293] The detailed implementation and specific operations of each module in the device for dynamically generating tokens in this embodiment can be found in the method embodiments for dynamically generating tokens implemented by the client side mentioned above in this application, and will not be repeated here.

[0294] Figure 7 This is a schematic diagram of the structure of a system for dynamically generating tokens provided in one embodiment of the present application. The system for dynamically generating tokens in this embodiment can be used to implement the methods for dynamically generating tokens in the above embodiments of the present application. Figure 7 As shown, the system for dynamically generating tokens in this embodiment includes: a server 701 and a client 702. Among them:

[0295] The server 701 is configured to, in response to a preset trigger condition being met, determine, in a preset manner, a first target solution for generating a total code for this token generation, wherein the first target solution includes multiple target sub-solutions corresponding to multiple sub-solutions; wherein the multiple sub-solutions include: an algorithm-related solution, a data structure solution, a data interface solution, a code execution process solution, and a code obfuscation solution; and each of the multiple sub-solutions has multiple candidate solutions; generate a first session key based on a token version number, sub-solution identifiers of the multiple target sub-solutions, and a first verification value obtained by processing the sub-solution identifiers of the multiple target sub-solutions using a preset verification algorithm; the sub-solution identifier is used to uniquely identify a sub-solution; obtain a sub-code corresponding to each of the multiple target sub-solutions; obtain a total code for generating the token this time based on the sub-code corresponding to each of the multiple target sub-solutions; and send the total code and the first session key to the client 702 so that the client 702 generates a token based on the total code.

[0296] The client 702 is configured to generate a token based on the total code in response to receiving the total code and the second session key sent by the server 701 ; and send the request content, the token, and the second session key to the server 701 .

[0297] In the embodiments of the present application, the specific implementation of the server 701 and the client 702 can refer to the devices of the method for dynamically generating tokens in the above-mentioned corresponding embodiments of the present application, and will not be repeated here.

[0298] In addition, an embodiment of the present application further provides an electronic device, comprising:

[0299] one or more processors;

[0300] a storage device for storing one or more programs,

[0301] 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 described in any of the above embodiments of the present application.

[0302] In addition, an embodiment of the present application also provides a computer-readable storage medium on which a computer program is stored. When the program is executed by a processor, the method for dynamically generating tokens described in any of the above embodiments of the present application is implemented.

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

[0304] like Figure 8 As shown, the electronic device 800 includes a computing unit 801, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 802 or a computer program loaded from a storage unit 808 into a random access memory (RAM) 803. In the RAM 803, various programs and data required for the operation of the electronic device 800 can also be stored. The computing unit 801, the ROM 802, and the RAM 803 are connected to each other via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0305] Multiple components in the electronic device 800 are connected to the I / O interface 805, including an input unit 806, such as a keyboard, a mouse, etc.; an output unit 807, such as various types of displays, speakers, etc.; a storage unit 808, such as a magnetic disk, an optical disk, etc.; and a communication unit 809, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 809 allows the electronic device 800 to exchange information / data with other devices via a computer network such as the Internet and / or various telecommunication networks.

[0306] The computing unit 801 can be a variety of general and / or special processing components with processing and computing capabilities. Some examples of the computing unit 801 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various dedicated artificial intelligence (AI) computing chips, various computing units that run machine learning model algorithms, digital signal processors (DSPs), and any appropriate processors, controllers, microcontrollers, etc. The computing unit 801 performs the various methods and processes described above, such as the detection method for Webshell files. For example, in some embodiments, the detection method for Webshell files can be implemented as a computer software program that is tangibly contained in a machine-readable medium, such as a storage unit 808. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 800 via ROM 802 and / or communication unit 809. When the computer program is loaded into RAM 803 and executed by the computing unit 801, one or more steps of the detection method for the Webshell file described above can be performed. Alternatively, in other embodiments, the computing unit 801 can be configured to execute the detection method for the Webshell file by any other appropriate means (e.g., by means of firmware).

[0307] Various embodiments of the systems and techniques described above 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 chips (SOCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments can include being implemented in one or more computer programs that are executable and / or interpreted on a programmable system that includes at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0308] The program code for implementing the methods of the present application can be written in any combination of one or more programming languages. Such program code can be provided to a processor or controller of a general-purpose computer, a special-purpose computer, or other programmable data processing device, so that when the program code is executed by the processor or controller, the functions / operations specified in the flow charts and / or block diagrams are implemented. The program code can be executed entirely on the machine, partially on the machine, as a stand-alone software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0309] In the context of the present application, a machine-readable medium can be a tangible medium that can contain or store a program for use by an instruction execution system, device or equipment or used in combination with an instruction execution system, device or equipment. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared or semiconductor system, device or equipment, or any suitable combination of the foregoing. A more specific example of a machine-readable storage medium can include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0310] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the computer. Other types of devices can also be used to provide interaction with the user; for example, the 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 acoustic input, voice input, or tactile input).

[0311] The systems and techniques described herein can be implemented in a computing system that includes back-end components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., a user computer with a graphical user interface or a web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such back-end components, middleware components, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a local area network (LAN), a wide area network (WAN), the Internet, and a blockchain network.

[0312] A computer system may include a client and a server. The client and server are generally remote from each other and typically interact via a communication network. This client-server relationship is established by computer programs running on the respective computers, establishing a client-server relationship. The server may be a cloud server, also known as a cloud computing server or cloud host, a host product within the cloud computing service ecosystem that addresses the management difficulties and limited scalability of traditional physical hosts and VPS services ("Virtual Private Servers" or simply "VPS"). The server may also be a server in a distributed system or a server integrated with blockchain.

[0313] It should be understood that the various forms of the processes shown above can be used to reorder, add, or delete steps. For example, the steps described in this disclosure can be performed in parallel, sequentially, or in a different order, as long as the desired results of the technical solutions disclosed in this application can be achieved. This is not a limitation herein.

[0314] The above specific embodiments do not constitute a limitation on the scope of protection of this application. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions may be made based on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application shall be included within the scope of protection of this application.

Claims

1. A method for dynamically generating a token, characterized in that: Applied to the server, including: In response to reaching a preset trigger condition, a first target solution for the total code used to generate the token this time is determined in a preset manner, wherein the first target solution includes multiple target sub-solutions corresponding to the multiple sub-solutions; wherein the multiple sub-solutions include: an algorithm-related solution, a data structure solution, a data interface solution, a code execution flow solution, and a code obfuscation solution; and each of the multiple sub-solutions has multiple candidate solutions; Generate a first session key based on the token version number, the sub-scheme identifiers of the multiple target sub-schemes, and a first verification value obtained by processing the sub-scheme identifiers of the multiple target sub-schemes using a preset verification algorithm; the sub-scheme identifier is used to uniquely identify a sub-scheme; Respectively obtain the subcode corresponding to each target sub-scheme in the multiple target sub-schemes; Based on the subcodes corresponding to the target sub-schemes in the multiple target sub-schemes, obtaining a total code for generating the token this time; The total code and the first session key are sent to the client so that the client generates a token based on the total code.

2. The method according to claim 1, characterized in that: The first target scheme of determining the total code for generating the token in a preset manner includes: For each of the partial sub-schemes, one candidate scheme is selected in sequence from the candidate schemes corresponding to each of the partial sub-schemes as the target sub-scheme corresponding to each of the partial sub-schemes; or, For each of the partial sub-schemes, a candidate scheme is randomly selected from the candidate schemes corresponding to each of the partial sub-schemes as the target sub-scheme corresponding to each of the partial sub-schemes.

3. The method according to claim 2, characterized in that Also includes: Presetting candidate solutions corresponding to the partial sub-solutions and sub-codes corresponding to the candidate solutions; or, The candidate solutions corresponding to the partial sub-solutions and the sub-codes corresponding to the candidate solutions are further updated.

4. The method according to any one of claims 1 to 3, characterized in that: The obtaining of the subcode corresponding to each target sub-scheme in the plurality of target sub-schemes respectively includes: The subcodes corresponding to the target sub-schemes are obtained from the preset candidate schemes corresponding to the partial sub-schemes and the subcodes corresponding to the candidate schemes.

5. The method according to any one of claims 1 to 3, characterized in that: Also includes: In response to receiving the request content, the token, and the second session key used to generate the token sent by the client, wherein the second session key includes a plurality of sub-scheme identifiers and a second verification value; Using the preset verification algorithm, the plurality of sub-scheme identifiers are processed to obtain a third verification value; confirming whether the second session key is consistent with the first session key based on whether the second check value is the same as the third check value; In response to the second session key being consistent with the first session key, obtaining valid data from the token based on the subschemes identified by the multiple subscheme 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 generating the first session key based on the token version number, the sub-scheme identifiers of the multiple target sub-schemes, and a first verification value obtained by verifying the sub-scheme identifiers of the multiple target sub-schemes using a preset verification algorithm includes: The first session key is generated based on the token version number, the sub-scheme identifiers of the multiple target sub-schemes, the first verification value, and the expiration time information of the first target scheme.

7. The method according to claim 6, characterized in that After receiving the request content, the token, and the second session key for generating the token sent by the client, the method further includes: Obtaining expiration time information in the second session key; confirming 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 being expired, the operation of using the preset verification algorithm to process the multiple sub-scheme identifiers to obtain a third verification value is performed.

8. The method according to claim 7, characterized in that The sending the total code and the first session key to the client comprises: Encrypt the first session key using a preset encryption algorithm and a server key to obtain an encrypted first session key; The total code and the encrypted first session key are sent to the client.

9. The method according to claim 8, characterized in that The response to receiving the request content, the token, and the second session key for generating the token sent by the client includes: Receiving the request content, the token, and the encrypted second session key sent by the client; After receiving the request content, the token, and the second session key for generating the token sent by the client, the method further includes: Decrypting the encrypted second session key using a preset encryption algorithm and the server key; In response to obtaining the second session key through decryption, the operation of obtaining the expiration time information in the second session key is performed.

10. The method according to claim 9, characterized in that The sending the total code and the encrypted first session key to the client comprises: The total code, the encrypted first session key, and a pre-acquired client key are sent to the client; wherein the client key is used by the client to encrypt the token.

11. The method according to claim 10, characterized in that The receiving the request content, the token, and the encrypted second session key sent by the client includes: receiving the request content, the encrypted token, and the encrypted second session key sent by the client; The acquiring valid data from the token based on the sub-schemes identified by the multiple sub-scheme identifiers comprises: Decrypting the encrypted token using the client key to obtain the token; Valid data is obtained from the token based on the sub-schema identified by the multiple sub-schema identifiers.

12. A method for dynamically generating a token, characterized in that: Applied to the client, including: In response to receiving the total code and the second session key sent by the server; wherein the second session key is generated based on the token version number, multiple sub-scheme identifiers corresponding to the second target scheme, and a second verification value obtained by processing the multiple sub-scheme identifiers using a preset verification algorithm, and the second session key includes the multiple sub-scheme identifiers and the second verification value; the second target scheme includes multiple target sub-schemes corresponding to multiple sub-schemes; wherein the multiple sub-schemes include: an algorithm-related scheme, a data structure scheme, a data interface scheme, a code execution process scheme, and a code obfuscation scheme; 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 identified by the multiple sub-scheme identifiers; generating a token based on the total code; Send the request content, the token, and the second session key to the server.

13. The method according to claim 12, characterized in that The second session key is generated based on the token version number, the multiple sub-scheme identifiers, the second verification value, and the expiration time information of the second target scheme; the second session key also includes the expiration time information of the second target scheme.

14. The method according to claim 12 or 13, characterized in that The receiving of the total code and the second session key sent by the server includes: The total code and the encrypted second session key sent by the server are received.

15. The method according to claim 14, characterized in that The receiving the total code and the encrypted second session key sent by the server includes: Receiving the total code, the encrypted second session key, and the client key sent by the server; After generating a token based on the total code, the method further includes: Encrypting the token using the client key to obtain an encrypted token; The sending the request content, the token, and the second session key to the server includes: The request content, the encrypted token, and the encrypted second session key are sent to the server.

16. A device for dynamically generating tokens, characterized in that: Applied to the server, including: A determination module, configured to determine, in response to reaching a preset trigger condition, a first target solution of the total code for generating the token this time in a preset manner, wherein the first target solution includes a plurality of target sub-solutions corresponding to the plurality of sub-solutions; wherein the plurality of sub-solutions include: an algorithm-related solution, a data structure solution, a data interface solution, a code execution flow solution, and a code obfuscation solution; and each of the plurality of sub-solutions has a plurality of candidate solutions; A first generating module, configured to generate a first session key based on a token version number, sub-scheme identifiers of the plurality of target sub-schemes, and a first verification value obtained by processing the sub-scheme identifiers of the plurality of target sub-schemes using a preset verification algorithm; the sub-scheme identifier is used to uniquely identify a sub-scheme; A first acquisition module is used to respectively acquire a subcode corresponding to each target sub-scheme in the multiple target sub-schemes; A second acquisition module, configured to acquire a total code for generating a token this time based on a sub-code corresponding to each target sub-scheme in the multiple target sub-schemes; The first sending module is used to send the total code and the first session key to the client, so that the client generates a token based on the total code.

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

18. An electronic device, characterized in that: The electronic device comprises: one or more processors; a 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 according to any one of claims 1 to 15.

19. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method according to any one of claims 1 to 15 is implemented.

Images