Resource access request processing method, device, storage medium and electronic device

Abstract

The present invention discloses a method, device, storage medium and electronic device for processing resource access requests. The method comprises: determining an initial token when a target client connects to a server for the first time, the initial token is determined by negotiation between the target client and the server based on a preset algorithm; iterating the initial token N times to obtain a server first access token; identifying the correctness of the target client's first access token based on the server's first access token to obtain an identification result, the target client's first access token is obtained by the target client iterating the initial token N times; the identification result indicates that the target client is allowed to access resources in the server when the target client's first access token is a correct token, and when the target client is not accessing the server for the first time, iterating the server's last access token to determine whether the target client's access request is legal. The present invention solves the technical problem of high security risks in the process of clients accessing server resources in the prior art.

Description

Technical Field

[0001] The present invention relates to the field of information security technology, and in particular to a method, device, storage medium and electronic device for processing a resource access request. Background Art

[0002] In recent years, the zero-trust model has been valued and respected. Its core principle is to never trust, always verify, and always authenticate and authorize based on all available data points, including user identity, location, device, data source, service or workload. Continuous verification means that there are no trusted areas, devices or users. In the existing technology, access security is guaranteed by fixed tokens or regular tokens. However, due to one or more token leaks, attackers can illegally access target resources and put all resources at risk.

[0003] In addition, in the prior art, new tokens are periodically issued to the client by the server, and the old tokens are invalidated to ensure security. However, since security needs to be specially guaranteed each time a new token is issued, especially through complex algorithms such as token negotiation, there are many processes involved, and the above method only reduces the risk of token leakage within a certain time range, that is, the leaked token will become invalid after a certain period of time, and it cannot be absolutely safe.

[0004] To address the above-mentioned problems, no effective solution has been proposed yet. Summary of the invention

[0005] The embodiments of the present invention provide a method, device, storage medium and electronic device for processing resource access requests, so as to at least solve the technical problem of high security risk existing in the process of client accessing server resources in the prior art.

[0006] According to one aspect of an embodiment of the present invention, a method for processing a resource access request is provided, comprising: when a target client connects to a server for the first time, determining an initial token, wherein the initial token is determined by negotiation between the target client and the server based on a preset algorithm; iterating the initial token N times to obtain a first access token of the server; identifying the correctness of the first access token of the target client based on the first access token of the server to obtain an identification result, wherein the first access token of the target client is obtained by the target client iterating the initial token N times, and N is a positive integer greater than 1; when the identification result indicates that the first access token of the target client is a correct token, allowing the target client to access resources in the server, wherein, when the target client is not accessing the server for the first time, the server iterates the last access token of the server to determine whether the access request of the target client is legal, and the last access token is obtained by iterating the first access token of the server K times, and K+1 is the number of times the target client accesses the server.

[0007] Furthermore, the method for processing resource access requests also includes: the target client iterates the initial token N times to obtain the first access token of the target client in the following manner: step 11, using the initial token as a salt value, performing a salted hash calculation on the initial token to obtain a first token; step 12, using the first token as a salt value, performing a salted hash calculation on the sum of the initial token and the first token to obtain a first secret value; step 13, using the initial token as a salt value, performing a salted hash calculation on the first secret value to obtain a second token; step 14, using the second token as a salt value, updating the first token based on the second token, performing a salted hash calculation on the sum of the initial token and the second token to obtain a second secret value; step 15, using the initial token as a salt value, performing a salted hash calculation on the second secret value to obtain a third token; step 16, repeating steps 14 to 15 until the number of executions reaches N times, and determining that the third token is the first access token of the target client.

[0008] Furthermore, the method for processing resource access requests also includes: step 21, using the initial token as a salt value, performing a salted hash calculation on the initial token to obtain a first token; step 22, using the first token as a salt value, performing a salted hash calculation on the sum of the initial token and the first token to obtain a first secret value; step 23, using the initial token as a salt value, performing a salted hash calculation on the first secret value to obtain a second token; step 24, using the second token as a salt value, updating the first token based on the second token, performing a salted hash calculation on the sum of the initial token and the second token to obtain a second secret value; step 25, using the initial token as a salt value, performing a salted hash calculation on the second secret value to obtain a third token; step 26, identifying whether the third token is consistent with the first access token of the target client; if the third token is consistent with the first access token of the target client, determining that the third token is the first access token of the server; if the third token is inconsistent with the first access token of the target client, repeating steps 24 to 25 until the number of executions reaches N times, and rejecting the access request of the target client.

[0009] Furthermore, the method for processing resource access requests also includes: step 31, when the target client successfully accesses the server for the first time and the target client accesses a single resource in the server, receiving the resource access request sent by the target client, wherein the resource access request includes at least the client identifier of the target client and the target token, and the target token is obtained by iterating the token of the last access to the server by the target client; step 32, determining the last access token of the server based on the client identifier; step 33, using the last access token as a salt value, performing a salted hash calculation on the last access token of the server to obtain a first token; step 34, using the first token as a salt value, performing a salted hash calculation on the sum of the last access token and the first token to obtain a first secret value; step 35, using the last access token as a salt value, performing a salted hash calculation on the first secret value to obtain a second token.

[0010] Furthermore, the method for processing resource access requests also includes: step 41, when the target client successfully accesses the server for the first time and the target client accesses multiple resources in the server, receiving a resource access request sent by the target client, wherein the resource access request includes at least a client identifier of the target client and a target token, and the target token is obtained by iterating the token of the last access to the server by the target client; step 42, determining the K-1th access token of the server based on the client identifier, and Q accessible resources corresponding to the target client, wherein each accessible resource has a corresponding sub-command card, Q is a positive integer greater than 1; step 43, using the K-1th access token as the salt value, performing salted hash calculation on the sum of the K-1th access token of the server and the secret value corresponding to the K-1th access token to obtain the current secret value; step 44, using the sub-token of the K+ith accessible resource accessed by the target client this time as the salt value, performing salted hash calculation on the current secret value to obtain the Kth access token, wherein 1≤i≤Q; step 45, repeating steps 43 to 44 until the number of executions reaches Q times, and obtaining the token corresponding to the target client accessing multiple accessible resources.

[0011] Furthermore, the method for processing resource access requests also includes: after performing a salted hash calculation on the first secret value to obtain a second token, when the second token is consistent with the target token, determining that the target client's resource access request is a normal access request, and allowing the target client to access the server; when the second token is inconsistent with the target token, determining that the target client's resource access request is an illegal access request, and prohibiting the target client from accessing the server.

[0012] Furthermore, the method for processing resource access requests also includes: after determining that the resource access request of the target client is a normal access request, updating the target token in the server, and sending the target application resources and / or confirmation information to the target client so that the target client updates the target token in the target client.

[0013] According to another aspect of an embodiment of the present invention, a device for processing resource access requests is also provided, including: a token determination module, used to determine an initial token when a target client connects to a server for the first time, wherein the initial token is determined by negotiation between the target client and the server based on a preset algorithm; an iterative calculation module, used to iterate the initial token N times to obtain a first access token of the server; a request identification module, used to identify the correctness of the first access token of the target client based on the first access token of the server to obtain an identification result, wherein the first access token of the target client is obtained by the target client iterating the initial token N times; a result identification module, used to allow the target client to access resources in the server when the identification result indicates that the first access token of the target client is a correct token, wherein, when the target client is not accessing the server for the first time, the server iterates the last access token of the server to determine whether the access request of the target client is legal, and the last access token is obtained by iterating the first access token of the server K times, and K+1 is the number of times the target client accesses the server.

[0014] According to another aspect of an embodiment of the present invention, a computer-readable storage medium is provided, in which a computer program is stored, wherein the computer program is configured to execute the above-mentioned method for processing resource access requests when running.

[0015] According to another aspect of an embodiment of the present invention, there is also provided an electronic device, which includes one or more processors; a memory for storing one or more programs, which, when the one or more programs are executed by the one or more processors, enables the one or more processors to run the programs, wherein the programs are configured to execute the above-mentioned method for processing resource access requests when running.

[0016] According to another aspect of an embodiment of the present invention, a computer program product is provided, including a computer program / instruction, and when the computer program / instruction is executed by a processor, the method for processing a resource access request is implemented.

[0017] In an embodiment of the present invention, an initial token is iterated N times to obtain a first access token of a server, and the correctness of the first access token of a target client is identified based on the first access token of the server to determine whether a resource access request is a normal access request. First, the initial token is determined when the target client first connects to the server; then the initial token is iterated N times to obtain the first access token of the server; secondly, the correctness of the first access token of the target client is identified based on the first access token of the server to obtain an identification result; finally, when the identification result indicates that the first access token of the target client is a correct token, the target client is allowed to access resources in the server; wherein, the initial token is determined by negotiation between the target client and the server based on a preset algorithm, the first access token of the target client is obtained by the target client iterating the initial token N times, N is a positive integer greater than 1, and when the target client is not accessing the server for the first time, the server iterates the last access token of the server to determine whether the access request of the target client is legal, the last access token is obtained by iterating the first access token of the server K times, and K+1 is the number of times the target client accesses the server.

[0018] In the above process, the token can be automatically generated using a preset algorithm, without the need for the target client and server to distribute it each time, thereby improving the efficiency of token generation and the security of the token; in addition, by iterating the token, even if the attacker captures the current token for multiple accesses, the token for the next access cannot be predicted, further improving the security of the process of accessing server resources based on the token; and the secret value secretly maintained in the token's iteration algorithm is always changing, unguessable, and will not be exposed to the Internet, further improving the security of the process of accessing server resources based on the token, thereby solving the technical problem of high security risks in the process of clients accessing server resources in related technologies.

[0019] It can be seen that the technical solution of the present invention achieves the purpose of processing resource requests, thereby achieving the technical effect of improving the security of the client in the process of accessing server resources, and further solving the technical problem of high security risks in the process of the client accessing server resources in the related technology. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The drawings described herein are used to provide a further understanding of the present invention and constitute a part of this application. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the drawings:

[0021] Figure 1 is a flow chart of a method for processing a resource access request according to an embodiment of the present invention;

[0022] Figure 2 is a schematic diagram of an optional method for processing a resource access request according to an embodiment of the present invention;

[0023] Figure 3 is a schematic diagram of an optional device for processing resource access requests according to an embodiment of the present invention;

[0024] Figure 4 is a schematic diagram of an optional server according to an embodiment of the present invention. DETAILED DESCRIPTION

[0025] In order to enable those skilled in the art to better understand the scheme of the present invention, the technical scheme in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present invention.

[0026] It should be noted that the terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0027] It should be noted that the relevant information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for display, data for analysis, etc.) involved in the present invention are all information and data authorized by the user or fully authorized by all parties. For example, an interface is set between the system and the relevant user or organization. Before obtaining relevant information, it is necessary to send an acquisition request to the aforementioned user or organization through the interface, and obtain relevant information after receiving the consent information fed back by the aforementioned user or organization.

[0028] Example 1

[0029] According to an embodiment of the present invention, a method embodiment of a method for processing a resource access request is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0030] Figure 1 is a flowchart of an optional method for processing a resource access request according to an embodiment of the present invention, such as Figure 1 As shown, the method comprises the following steps:

[0031] Step S102, when the target client connects to the server for the first time, an initial token is determined, wherein the initial token is determined by negotiation between the target client and the server based on a preset algorithm.

[0032] Step S104, iterate the initial token N times to obtain the first access token of the server.

[0033] Step S106, identifying the correctness of the first access token of the target client based on the first access token of the server to obtain an identification result, wherein the first access token of the target client is obtained by the target client iterating the initial token N times.

[0034] Step S108, when the identification result indicates that the first access token of the target client is a correct token, the target client is allowed to access resources in the server, wherein, when it is not the first time for the target client to access the server, the server iterates the last access token of the server to determine whether the access request of the target client is legal, and the last access token is obtained by iterating the first access token of the server K times, and K+1 is the number of times the target client accesses the server.

[0035] Based on the scheme defined in the above steps S102 to S108, it can be known that in an embodiment of the present invention, the initial token is iterated N times to obtain the first access token of the server, and the correctness of the first access token of the target client is identified based on the first access token of the server to determine whether the resource access request is a normal access request. First, the initial token is determined when the target client first connects to the server; then the initial token is iterated N times to obtain the first access token of the server; secondly, the correctness of the first access token of the target client is identified based on the first access token of the server to obtain an identification result; finally, when the identification result indicates that the first access token of the target client is a correct token, the target client is allowed to access the resources in the server; wherein, the initial token is determined by negotiation between the target client and the server based on a preset algorithm, the first access token of the target client is obtained by the target client iterating the initial token N times, N is a positive integer greater than 1, and when the target client does not access the server for the first time, the server iterates the last access token of the server to determine whether the access request of the target client is legal, the last access token is obtained by iterating the first access token of the server K times, and K+1 is the number of times the target client accesses the server.

[0036] In the above process, the token can be automatically generated using a preset algorithm, without the need for the target client and server to distribute it each time, thereby improving the efficiency of token generation and the security of the token; in addition, by iterating the token, even if the attacker captures the current token for multiple accesses, the token for the next access cannot be predicted, further improving the security of the process of accessing server resources based on the token; and the secret value secretly maintained in the token's iteration algorithm is always changing, unguessable, and will not be exposed to the Internet, further improving the security of the process of accessing server resources based on the token, thereby solving the technical problem of high security risks in the process of clients accessing server resources in related technologies.

[0037] It can be seen that the technical solution of the present invention achieves the purpose of processing resource requests, thereby achieving the technical effect of improving the security of the client in the process of accessing server resources, and further solving the technical problem of high security risks in the process of the client accessing server resources in the related technology.

[0038] In step S102, this embodiment processes the first connection request of the target client through the server. Optionally, the server may include a server with functions such as a proxy gateway and a network security boundary. The device itself isolates the network between the target client and the server's resources and performs access control.

[0039] In this embodiment, the token is usually expressed as a token in the technical implementation, wherein the user's identity security depends on the token, and the user needs to verify the token each time he accesses the server through the target client. In addition, in this embodiment, when the target client connects to the server for the first time, the initial token can be determined based on a preset algorithm through negotiation, for example, Figure 2 As shown, the initial token distribution can be completed based on the key exchange algorithm.

[0040] Optionally, before the initial token is distributed through the key exchange algorithm, it is also necessary to ensure the accuracy of the user's identity through multi-factor authentication, password authentication, etc.

[0041] It should be noted that the key exchange algorithm can ensure that both the server and the client generate agreed tokens, and the token itself will not be transmitted on the channel, thus ensuring security.

[0042] Optionally, in this embodiment, the key exchange algorithm is an ECDHE key exchange algorithm. The basic process of determining the initial token using the ECDHE key exchange algorithm is as follows:

[0043] (1) The target client randomly generates a first random value R a , the second random value is calculated by the following formula:

[0044] P a (x,y)=R a *Q(x,y)

[0045] Among them, Q(x,y) is the base point of a recognized elliptic curve algorithm, P a (x,y) is the second random value, and then the target client will P a (x,y) is sent to the server.

[0046] (2) The server randomly generates a third random value R b , the third random value is calculated by the following formula:

[0047] P b (x,y)=R b *Q(x,y)

[0048] Among them, P b (x, y) is a third random value, and the server sends the third random value to the target client.

[0049] (3) The target client calculates the fourth random value using the following formula:

[0050] S a (x,y)=R a *P b (x,y)

[0051] Among them, S a (x, y) is the fourth random value.

[0052] (4) The server calculates the fifth random value using the following formula:

[0053] S b (x,y)=R b *P a (x,y)

[0054] Among them, S b (x,y) is the fifth random value.

[0055] (5) The above algorithm ensures that S a (x,y)=S b (x,y)=S, where S is the target random value, and then the x vector of S is extracted as the initial token.

[0056] In step S104, the server iterates the initial token N times to obtain the server's first access token.

[0057] In step S106, the server obtains an identification result by identifying whether the first access token of the target client is consistent with the first access token of the server. Optionally, the first access token of the target client is obtained by the target client iterating the initial token N times, where N is a positive integer greater than 1.

[0058] Furthermore, the target client iterates the initial token N times in the following manner to obtain the target client's first access token:

[0059] Step 11, using the initial token as a salt value, performing salted hash calculation on the initial token to obtain a first token;

[0060] Step 12, using the first token as a salt value, performing a salted hash calculation on the sum of the initial token and the first token to obtain a first secret value;

[0061] Step 13, using the initial token as a salt value, performing salted hash calculation on the first secret value to obtain a second token;

[0062] Step 14, using the second token as a salt value, updating the first token based on the second token, performing a salted hash calculation on the sum of the initial token and the second token to obtain a second secret value;

[0063] Step 15, using the initial token as a salt value, performing salted hash calculation on the second secret value to obtain a third token;

[0064] Step 16, repeating steps 14 to 15 until the number of executions reaches N times, and determining that the third token is the first access token of the target client.

[0065] In this embodiment, the hash algorithm used is SHA256, and t is the initial token. In order to hide the connection between the first access token and the initial token, when the target client first accesses the resource, its initial token is not used directly, but is hashed N times in a certain form.

[0066] In step 11, the first hash operation process of the initial token t is:

[0067] [t] 1 =sha(t,t) (1)

[0068] Where t is the initial token calculated by the key agreement algorithm. The salt value of the hash operation in the above formula uses the initial token itself. [t] 1 represents the first token, the superscript 1 represents the result of one hash operation on the initial token, and similarly, the use of square brackets plus the superscript k represents the result of k hash operations on the initial token.

[0069] In step 12, the sum of the initial token and the first token t+[t] 1 Perform salted hash calculation to obtain the first secret value. The calculation formula is as follows:

[0070] secret = sha(t+[t] 1 ,[t] 1 ) (2)

[0071] The result is base64 encoded, using the salt value of the first token [t] 1 , secret is the first secret value.

[0072] In step 13, the first secret value is hashed with salt to obtain a second token, and the calculation formula is as follows:

[0073] [t] 2 =sha(secret,t) (3)

[0074] The salt value used is the initial token, [t] 2 For the second token.

[0075] In step 14, the second token is used as the salt value, the first token is updated based on the second token, and the sum of the initial token and the second token is hashed with salt to obtain the second secret value. The calculation formula is as follows:

[0076] secret = sha(t+[t]2 ,[t] 2 ) (4)

[0077] In step 15, the second secret value is hashed with the initial token as the salt value to obtain the third token. The calculation formula is as follows:

[0078] [t] 3 =sha(secret, t) (5)

[0079] In step 16, steps 14 to 15 are repeated until the number of executions reaches N times, and the third token is determined to be the first access token of the target client. The specific formula is as follows:

[0080] [t] N =sha(secret, t)

[0081] secret = sha(secret + [t] N ,[t] N ) (6)

[0082] It is easy to notice that by hiding the relationship between the first access token and the initial token, because the hash operation is irreversible, even if the attacker captures the first access token, he cannot guess the initial token, thereby improving the security of the client in the process of accessing server resources.

[0083] In another alternative, the correctness of the first access token of the target client is identified based on the first access token of the server through the following steps:

[0084] Step 21, using the initial token as a salt value, performing salted hash calculation on the initial token to obtain a first token;

[0085] Step 22, using the first token as a salt value, performing a salted hash calculation on the sum of the initial token and the first token to obtain a first secret value;

[0086] Step 23, using the initial token as a salt value, performing salted hash calculation on the first secret value to obtain a second token;

[0087] Step 24, using the second token as a salt value, updating the first token based on the second token, performing a salted hash calculation on the sum of the initial token and the second token to obtain a second secret value;

[0088] Step 25, using the initial token as a salt value, performing salted hash calculation on the second secret value to obtain a third token;

[0089] Step 26, identifying whether the third token is consistent with the first access token of the target client; if the third token is consistent with the first access token of the target client, determining that the third token is the first access token of the server; if the third token is inconsistent with the first access token of the target client, repeating steps 24 to 25 until the number of executions reaches N times, and rejecting the access request of the target client.

[0090] In this embodiment, the calculation formulas executed in steps 21-26 are as shown in the above formulas (1)-(6), which will not be repeated here. Optionally, the server does not know the number of iterations generated by the client, so the server can only repeat the iteration according to formula (6) until the integer N is found so that the token calculated by the server is consistent with that of the client. Alternatively, if the server calculates a maximum of N iterations and still fails to make the token it calculates consistent with that of the client, the access is illegal and the access request of the target client can be rejected.

[0091] It should be noted that since the secret value is stored confidentially on the target client and server and has never been transmitted on the network, it is relatively safe. The token for each access is different, and even if it is captured multiple times, the attacker cannot calculate the next token. In fact, the secret value can be seen as a summary of all previous historical tokens, but even if the attacker obtains all historical tokens, the secret value cannot be obtained because the original token is unknown to the attacker, and therefore the N value used for the first access is also unknown. Due to the iteration of each token, there is no need to use timestamps, random numbers, etc. to prevent replay attacks.

[0092] In step S108, when the identification result indicates that the first access token of the target client is a correct token, the target client is allowed to access resources in the server. For example, when the identification result indicates that the first access token of the target client is consistent with the first access token of the server, the target client is allowed to access resources in the server; when the identification result indicates that the first access token of the target client is inconsistent with the first access token of the server, the target client is prohibited from accessing resources in the server.

[0093] Optionally, when the target client is not accessing the server for the first time, the server needs to iterate the token of the server's last access K times to obtain the server's current access token. When the server's current access token is consistent with the target client's current access token, the target client is allowed to access resources in the server. Optionally, K+1 is the current number of times the target client has accessed the server.

[0094] Furthermore, in this embodiment, the following two basic principles of the zero trust model (ZTNA model) are followed:

[0095] (1) Resource segmentation principle: Traditional networks expose direct access to all data assets, servers, and applications. The zero trust model divides these resources into subsets and eliminates the ability for users to directly access them without first passing through a strictly controlled gateway, i.e., “network isolation.” In the ZTNA model, network target resources are relatively independent, so even if a target resource is invaded, it will not threaten other target resources.

[0096] (2) Access control principles: Regardless of whether users are physically located in the office or working remotely, they should only be able to access information and resources that match their respective roles. Each part of the network should be authenticated and authorized to ensure that traffic is sent from trusted users, and the environment for access terminals needs to be restricted.

[0097] In the prior art, users authenticate on the AAA server, access the target network through VPN and other methods, and obtain access rights to the corresponding application resources by matching policies. The authentication process is only once, and each access is no longer subject to verification. In this embodiment, the user's identity security depends on the dynamic token, and each access needs to verify the dynamic token. The dynamic token needs to meet the following conditions:

[0098] (1) The token must be changed for each access and is not fixed.

[0099] (2) The token is generated by negotiation using an algorithm only during the initial distribution. The server does not need to distribute it every time. The token is automatically generated using an agreed algorithm in the future. That is, the client knows how to generate the token and use it to access. The server knows what kind of token the client will generate so that it can be verified when access comes.

[0100] (3) The parameters required for dynamic token generation will not be transmitted on the network, thus ensuring that the token cannot be calculated by humans.

[0101] (4) The token is not generated based on the token of the last or previous access. To an attacker, the token should look random, but the server can predict the token of the client's next access. If they do not match, the server will deny access.

[0102] Optionally, after the first access verification is passed, the server and client perform the following security verification process for each access:

[0103] (1) The target client calculates the access token and initiates access with the token.

[0104] (2) After receiving the access request, the server uses the same algorithm as the target client to iterate the access token. If the token provided by the target client is the same as the token provided by the server, the access is legal. Otherwise, the access is deemed illegal and denied.

[0105] (3) After the server responds to the client's access, it considers the access successful and updates the token based on the iterative procedure. The target client must use the token to access successfully next time. The target client receives the server's response and considers the access successful. It updates the token based on the iterative procedure and uses the token to access next time.

[0106] To meet the above requirements for tokens, the target client and server determine the token for each access through a specific iteration. For example, the token used for the kth access is the result of N+k-1 iterations of the original token.

[0107] In an optional embodiment, when the target client successfully accesses the server for the first time and the target client accesses a single resource in the server, the second token is determined by the following steps, wherein the second token is a token corresponding to the server when the target client accesses the single resource in the server:

[0108] Step 31, receiving a resource access request sent by a target client, wherein the resource access request includes at least a client identifier of the target client and a target token, and the target token is obtained by iterating a token used by the target client to access the server last time;

[0109] Step 32, determining the last access token of the server based on the client identifier;

[0110] Step 33, using the last access token as a salt value, performing salted hash calculation on the last access token of the server to obtain a first token;

[0111] Step 34, using the first token as a salt value, performing a salted hash calculation on the sum of the last access token and the first token to obtain a first secret value;

[0112] Step 35, using the last access token as a salt value, performing salted hash calculation on the first secret value to obtain a second token.

[0113] In this embodiment, the client identifier can be an IP address, physical address, etc. of the target client, and the server can identify the corresponding target client based on the client identifier. Optionally, the target token is a token generated based on the target client's last access to the server.

[0114] Optionally, in steps 31-32, if Figure 2As shown, when the target client accesses a single resource in the server, the server iterates N times to calculate the first access token and verifies the legitimacy of the access. In each subsequent access, the token is iterated until the access ends. That is, the server can determine the client identifier of the target client and the target token through the access request of the target client, and the server can determine the server's last access token based on the client identifier of the target client. In steps 33-35, the second token can be calculated by the above formulas (1)-(3) respectively, and the single resource and retrograde access to the server can be performed based on the second token.

[0115] It should be noted that determining the current token through the client identifier improves the accuracy of determining the current token based on the unique client identifier.

[0116] In another optional embodiment, when the target client successfully accesses the server for the first time and the target client accesses multiple resources in the server, the token corresponding to the target client accessing the multiple accessible resources is determined by the following steps:

[0117] Step 41, receiving a resource access request sent by a target client, wherein the resource access request includes at least a client identifier of the target client and a target token, and the target token is obtained by iterating a token used by the target client to access the server last time;

[0118] Step 42, determining the K-1th access token of the server and Q accessible resources corresponding to the target client based on the client identifier, wherein each accessible resource has a corresponding sub-token, and Q is a positive integer greater than 1;

[0119] Step 43, using the K-1th access token as a salt value, performing a salted hash calculation on the sum of the K-1th access token of the server and the secret value corresponding to the K-1th access token to obtain a current secret value;

[0120] Step 44, using the sub-token of the K+ith accessible resource accessed by the target client as the salt value, performing salted hash calculation on the current secret value to obtain the Kth access token, where 1≤i≤Q;

[0121] Step 45, repeating steps 43 to 44 until the number of executions reaches Q times, and obtaining a token corresponding to when the target client accesses multiple accessible resources.

[0122] In this embodiment, if Figure 2As shown, when the target client accesses multiple resources in the server, that is, when the resource access type is a multi-resource access type, the server will issue another token for each accessed resource, and iterate N times to calculate the access token, while verifying the legitimacy of the access. Then, at each access, the server iterates the token according to the accessed resource until the access ends. That is, the server can greatly reduce the risk of leakage of each token by combining the various subsets of resources divided in the zero trust model and using the irreversibility of the hash algorithm to combine the token iterations of multi-resource access. For example, the accessible application resources are divided into several subsets, and the access rights of i resource subsets are obtained through a rigorous authentication process. It is usually possible to match the policies related to the terminal operating environment of the accessing user, the policies related to the user's organizational information, and other general policies, and then decide which resource subsets to authorize access rights for.

[0123] Optionally, the server determines the K-1th access token of the server and Q accessible resources corresponding to the target client based on the client identifier, where each accessible resource has a corresponding sub-token, Q is a positive integer greater than 1, and then allocates i sub-tokens to the target client, one sub-token for each resource, which are denoted as t1, t2, ..., t i Sub-tokens can be distributed through a highly secure key exchange algorithm or directly transmitted in a secure channel. Sub-tokens are usually proof of user access to corresponding resources and can be distributed, revoked, etc. based on policy matching.

[0124] This embodiment stipulates that the first access is used to verify the legitimacy of the client's identity and does not actually access a specific resource. After the first access, the verification process for subsequent accesses to resources is as follows: If the client accesses resource j, 0≤j≤i, where t j is the sub-token for resource j assigned to the user, [t] K-1 As the current token, when accessing resource j, the following calculation is performed to determine the token [t] of resource j among the K+i resources accessing the server this time. K , and update the value of secret:

[0125] [t] K =sha(secret,t j ) (7)

[0126] secret = sha(secret + [t] K ,[t] K )

[0127] Optionally, the next time you access any resource, assuming the resource number is p, the token continues to iterate using the above formula, replacing t in the above formula with j Replace with tp , where t p is the sub-token assigned to resource p. The above algorithm is known to the server, so the token can be easily verified.

[0128] Furthermore, the above formula (7) is repeatedly executed until the number of executions reaches Q times, and a token corresponding to when the target client accesses multiple accessible resources is obtained.

[0129] It should be noted that when accessing multiple resources, the secret can be regarded as an agreed value that is secretly calculated and updated by the client and the server at all times. The agreed value summarizes the tokens corresponding to multiple resource subsets. Since the summary process is completely irreversible, it is impossible to deduce the individual tokens before the summary through the summary result. Therefore, the process uses the summary calculation of multiple tokens to protect the privacy of each token. In addition, the secret value that is always maintained can also be used as an agreed token to re-encrypt private data, such as passwords, terminal environment information, user information, etc. Since the secret is constantly changing, it is impossible for attackers to find a pattern. Therefore, it is relatively safe to use the secret value as the key for symmetric encryption to re-encrypt some private data.

[0130] Furthermore, after performing a salted hash calculation on the first secret value to obtain the second token, when the second token is consistent with the target token, the server determines that the target client's resource access request is a normal access request and allows the target client to access the server; when the second token is inconsistent with the target token, the server determines that the target client's resource access request is an illegal access request and prohibits the target client from accessing the server.

[0131] Optionally, the server determines whether to allow the target client to access the server's resources by identifying whether the second token is consistent with the target token. When the second token is consistent with the target token, the target client's resource access request is determined to be a normal access request, and access to the server's resources is allowed; when the second token is inconsistent with the target token, the target client's resource access request is determined to be an illegal access request, and access to the server's resources is not allowed.

[0132] Further, after determining that the resource access request of the target client is a normal access request, the target token in the server is updated, and the target application resource and / or confirmation information is sent to the target client, so that the target client updates the target token in the target client.

[0133] Optionally, after determining that the resource access request is a normal access request, the target application resource and / or confirmation information is sent to the target client, so that the target client updates the target token.

[0134] It should be noted that by sending the target application resources and / or confirmation information to the target client so that the target client updates the target token, attacks on the server can be prevented, thereby further improving the security of resource access.

[0135] From the above content, it can be seen that the present application iterates the token through hash operation. Since the hash algorithm has a small amount of operation, only a hash value of a fixed length is generated each time, which reduces the storage and operation burden of the client and server caused by the increase in the number of iterations; even if the attacker captures the key for multiple accesses, the next access key cannot be predicted. In addition, even if the attacker attempts to illegally access an application resource multiple times, it will not be cracked due to the obfuscation operation between the keys; and no timestamp is required, and replay attacks are prevented through key iteration; finally, the secret value secretly maintained in the key iteration algorithm is always changing, cannot be guessed, and will not be exposed to the Internet, and can also be used as a symmetric key to re-encrypt private data.

[0136] Example 2

[0137] According to an embodiment of the present invention, there is also provided an embodiment of a device for processing a resource access request, wherein: Figure 3 is a schematic diagram of an optional device for processing resource access requests according to an embodiment of the present invention, such as Figure 3 As shown, the device includes: a token determination module 301, an iterative calculation module 303, a request identification module 305 and a result identification module 307.

[0138] The token determination module 301 is used to determine an initial token when the target client connects to the server for the first time, wherein the initial token is determined by negotiation between the target client and the server based on a preset algorithm.

[0139] Optionally, in this embodiment, the token is usually expressed as a token in the technical implementation, wherein the user's identity security depends on the token, and the user needs to verify the token each time he accesses the server through the target client. In addition, in this embodiment, when the target client connects to the server for the first time, the initial token can be determined based on a preset algorithm through negotiation, for example, Figure 2 As shown, the initial token distribution can be completed based on the key exchange algorithm.

[0140] Optionally, before the initial token is distributed through the key exchange algorithm, it is also necessary to ensure the accuracy of the user's identity through multi-factor authentication, password authentication, etc.

[0141] It should be noted that the key exchange algorithm can ensure that both the server and the client generate agreed tokens, and the token itself will not be transmitted on the channel, thus ensuring security.

[0142] Optionally, in this embodiment, the key exchange algorithm is an ECDHE key exchange algorithm. The basic process of determining the initial token using the ECDHE key exchange algorithm is as follows:

[0143] (1) The target client randomly generates a first random value R a , the second random value is calculated by the following formula:

[0144] P a (x,y)=R a *Q(x,y)

[0145] Among them, Q(x,y) is the base point of a recognized elliptic curve algorithm, P a (x,y) is the second random value, and then the target client will P a (x,y) is sent to the server.

[0146] (2) The server randomly generates a third random value R b , the third random value is calculated by the following formula:

[0147] P b (x,y)=R b *Q(x,y)

[0148] Among them, P b (x, y) is a third random value, and the server sends the third random value to the target client.

[0149] (3) The target client calculates the fourth random value using the following formula:

[0150] S a (x,y)=R a *P b (x,y)

[0151] Among them, S a (x, y) is the fourth random value.

[0152] (4) The server calculates the fifth random value using the following formula:

[0153] S b (x,y)=R b *P a (x,y)

[0154] Among them, S b (x,y) is the fifth random value.

[0155] (5) The above algorithm ensures that S a (x,y)=S b(x,y)=S, where S is the target random value, and then the x vector of S is extracted as the initial token.

[0156] The iterative calculation module 303 is used to iterate the initial token N times to obtain the first access token of the server.

[0157] Optionally, the server iterates the initial token N times to obtain the server's first access token.

[0158] The request identification module 305 is used to identify the correctness of the first access token of the target client based on the first access token of the server to obtain an identification result, wherein the first access token of the target client is obtained by the target client iterating the initial token N times, and N is a positive integer greater than 1.

[0159] Optionally, the server obtains the identification result by identifying whether the first access token of the target client is consistent with the first access token of the server. Optionally, the first access token of the target client is obtained by the target client iterating the initial token N times, where N is a positive integer greater than 1.

[0160] The result identification module 307 is used to allow the target client to access resources in the server when the identification result indicates that the first access token of the target client is a correct token, wherein, when it is not the first time for the target client to access the server, the server iterates the last access token of the server to determine whether the access request of the target client is legal, and the last access token is obtained by iterating the first access token of the server K times, and K+1 is the number of times the target client accesses the server.

[0161] Optionally, when the identification result indicates that the first access token of the target client is a correct token, the target client is allowed to access resources in the server. For example, when the identification result indicates that the first access token of the target client is consistent with the first access token of the server, the target client is allowed to access resources in the server; when the identification result indicates that the first access token of the target client is inconsistent with the first access token of the server, the target client is prohibited from accessing resources in the server.

[0162] Furthermore, in this embodiment, the following two basic principles of the zero trust model (ZTNA model) are followed:

[0163] (1) Resource segmentation principle: Traditional networks expose direct access to all data assets, servers, and applications. The zero trust model divides these resources into subsets and eliminates the ability for users to directly access them without first passing through a strictly controlled gateway, i.e., “network isolation.” In the ZTNA model, network target resources are relatively independent, so even if a target resource is invaded, it will not threaten other target resources.

[0164] (2) Access control principles: Regardless of whether users are physically located in the office or working remotely, they should only be able to access information and resources that match their respective roles. Each part of the network should be authenticated and authorized to ensure that traffic is sent from trusted users, and the environment for access terminals needs to be restricted.

[0165] In the prior art, users authenticate on the AAA server, access the target network through VPN and other methods, and obtain access rights to the corresponding application resources by matching policies. The authentication process is only once, and each access is no longer subject to verification. In this embodiment, the user's identity security depends on the dynamic token, and each access needs to verify the dynamic token. The dynamic token needs to meet the following conditions:

[0166] (1) The token must be changed for each access and is not fixed.

[0167] (2) The token is generated by negotiation using an algorithm only during the initial distribution. The server does not need to distribute it every time. The token is automatically generated using an agreed algorithm in the future. That is, the client knows how to generate the token and use it to access. The server knows what kind of token the client will generate so that it can be verified when access comes.

[0168] (3) The parameters required for dynamic token generation will not be transmitted on the network, thus ensuring that the token cannot be calculated by humans.

[0169] (4) The token is not generated based on the token of the last or previous access. To an attacker, the token should look random, but the server can predict the token of the client's next access. If they do not match, the server will deny access.

[0170] Optionally, after the first access verification is passed, the server and client perform the following security verification process for each access:

[0171] (1) The target client calculates the access token and initiates access with the token.

[0172] (2) After receiving the access request, the server uses the same algorithm as the target client to iterate the access token. If the token provided by the target client is the same as the token provided by the server, the access is legal. Otherwise, the access is deemed illegal and denied.

[0173] (3) After the server responds to the client's access, it considers the access successful and updates the token based on the iterative procedure. The target client must use the token to access successfully next time. The target client receives the server's response and considers the access successful. It updates the token based on the iterative procedure and uses the token to access next time.

[0174] To meet the above requirements for tokens, the target client and server determine the token for each access through a specific iteration. For example, the token used for the kth access is the result of N+k-1 iterations of the original token.

[0175] Furthermore, the processing device for resource access requests also includes: a target iteration calculation module, which is used for the target client to iterate the initial token N times to obtain the first access token of the target client in the following manner: step 11, using the initial token as a salt value, performing a salted hash calculation on the initial token to obtain a first token; step 12, using the first token as a salt value, performing a salted hash calculation on the sum of the initial token and the first token to obtain a first secret value; step 13, using the initial token as a salt value, performing a salted hash calculation on the first secret value to obtain a second token; step 14, using the second token as a salt value, updating the first token based on the second token, performing a salted hash calculation on the sum of the initial token and the second token to obtain a second secret value; step 15, using the initial token as a salt value, performing a salted hash calculation on the second secret value to obtain a third token; step 16, repeating steps 14 to 15 until the number of executions reaches N times, and determining that the third token is the first access token of the target client.

[0176] Optionally, the target client iterates the initial token N times in the following manner to obtain the target client's first access token:

[0177] Step 11, using the initial token as a salt value, performing salted hash calculation on the initial token to obtain a first token;

[0178] Step 12, using the first token as a salt value, performing a salted hash calculation on the sum of the initial token and the first token to obtain a first secret value;

[0179] Step 13, using the initial token as a salt value, performing salted hash calculation on the first secret value to obtain a second token;

[0180] Step 14, using the second token as a salt value, updating the first token based on the second token, performing a salted hash calculation on the sum of the initial token and the second token to obtain a second secret value;

[0181] Step 15, using the initial token as a salt value, performing salted hash calculation on the second secret value to obtain a third token;

[0182] Step 16, repeating steps 14 to 15 until the number of executions reaches N times, and determining that the third token is the first access token of the target client.

[0183] In this embodiment, the hash algorithm used is SHA256, and t is the initial token. In order to hide the connection between the first access token and the initial token, when the target client first accesses the resource, its initial token is not used directly, but is hashed N times in a certain form.

[0184] In step 11, the first hash operation process of the initial token t is:

[0185] [t] 1 =sha(t,t) (1)

[0186] Where t is the initial token calculated by the key agreement algorithm. The salt value of the hash operation in the above formula uses the initial token itself. [t] 1 represents the first token, the superscript 1 represents the result of one hash operation on the initial token, and similarly, the use of square brackets plus the superscript k represents the result of k hash operations on the initial token.

[0187] In step 12, the sum of the initial token and the first token t+[t] 1 Perform salted hash calculation to obtain the first secret value. The calculation formula is as follows:

[0188] secret = sha(t+[t] 1 ,[t] 1 ) (2)

[0189] The result is base64 encoded, using the salt value of the first token [t] 1 , secret is the first secret value.

[0190] In step 13, the first secret value is hashed with salt to obtain a second token, and the calculation formula is as follows:

[0191] [t] 2 =sha(secret,t) (3)

[0192] The salt value used is the initial token, [t] 2 For the second token.

[0193] In step 14, the second token is used as the salt value, the first token is updated based on the second token, and the sum of the initial token and the second token is hashed with salt to obtain the second secret value. The calculation formula is as follows:

[0194] secret = sha(t+[t] 2 ,[t] 2 ) (4)

[0195] In step 15, the second secret value is hashed with the initial token as the salt value to obtain the third token. The calculation formula is as follows:

[0196] [t] 3 =sha(secret, t) (5)

[0197] In step 16, steps 14 to 15 are repeated until the number of executions reaches N times, and the third token is determined to be the first access token of the target client. The specific formula is as follows:

[0198] [t] N =sha(secret, t)

[0199] secret = sha(secret + [t] N ,[t] N ) (6)

[0200] It is easy to notice that by hiding the relationship between the first access token and the initial token, because the hash operation is irreversible, even if the attacker captures the first access token, he cannot guess the initial token, thereby improving the security of the client in the process of accessing server resources.

[0201] Optionally, the request identification module also includes: a request identification unit, which is used to perform a salted hash calculation on the initial token using the initial token as a salt value to obtain a first token through step 21; step 22, using the first token as a salt value, performing a salted hash calculation on the sum of the initial token and the first token to obtain a first secret value; step 23, using the initial token as a salt value, performing a salted hash calculation on the first secret value to obtain a second token; step 24, using the second token as a salt value, updating the first token based on the second token, performing a salted hash calculation on the sum of the initial token and the second token to obtain a second secret value; step 25, using the initial token as a salt value, performing a salted hash calculation on the second secret value to obtain a third token; step 26, identifying whether the third token is consistent with the first access token of the target client; if the third token is consistent with the first access token of the target client, determining that the third token is the first access token of the server; if the third token is inconsistent with the first access token of the target client, repeating steps 24 to 25 until the number of executions reaches N times, and rejecting the access request of the target client.

[0202] In another alternative, the correctness of the first access token of the target client is identified based on the first access token of the server through the following steps:

[0203] Step 21, using the initial token as a salt value, performing salted hash calculation on the initial token to obtain a first token;

[0204] Step 22, using the first token as a salt value, performing a salted hash calculation on the sum of the initial token and the first token to obtain a first secret value;

[0205] Step 23, using the initial token as a salt value, performing salted hash calculation on the first secret value to obtain a second token;

[0206] Step 24, using the second token as a salt value, updating the first token based on the second token, performing a salted hash calculation on the sum of the initial token and the second token to obtain a second secret value;

[0207] Step 25, using the initial token as a salt value, performing salted hash calculation on the second secret value to obtain a third token;

[0208] Step 26, identifying whether the third token is consistent with the first access token of the target client; if the third token is consistent with the first access token of the target client, determining that the third token is the first access token of the server; if the third token is inconsistent with the first access token of the target client, repeating steps 24 to 25 until the number of executions reaches N times, and rejecting the access request of the target client.

[0209] In this embodiment, the calculation formulas executed in steps 21-26 are as shown in the above formulas (1)-(6), which will not be repeated here. Optionally, the server does not know the number of iterations generated by the client, so the server can only repeat the iteration according to formula (6) until the integer N is found so that the token calculated by the server is consistent with that of the client. Alternatively, if the server calculates a maximum of N iterations and still fails to make the token it calculates consistent with that of the client, the access is illegal and the access request of the target client can be rejected.

[0210] It should be noted that since the secret value is stored confidentially on the target client and server and has never been transmitted on the network, it is relatively safe. The token for each access is different, and even if it is captured multiple times, the attacker cannot calculate the next token. In fact, the secret value can be seen as a summary of all previous historical tokens, but even if the attacker obtains all historical tokens, the secret value cannot be obtained because the original token is unknown to the attacker, and therefore the N value used for the first access is also unknown. Due to the iteration of each token, there is no need to use timestamps, random numbers, etc. to prevent replay attacks.

[0211] Furthermore, the processing device for resource access request also includes: a first access request receiving module, a first token determination module, a first iterative calculation module, a second iterative calculation module and a third iterative calculation module. The access request receiving module is used to receive a resource access request sent by a target client when the target client successfully accesses the server for the first time and the target client accesses a single resource in the server, wherein the resource access request includes at least a client identifier and a target token of the target client, and the target token is obtained by iterating the token of the last access to the server by the target client; the first token determination module is used to determine the last access token of the server based on the client identifier; the first iterative calculation module is used to use the last access token as a salt value to perform a salted hash calculation on the last access token of the server to obtain a first token; the second iterative calculation module is used to use the first token as a salt value to perform a salted hash calculation on the sum of the last access token and the first token to obtain a first secret value; the third iterative calculation module is used to use the last access token as a salt value to perform a salted hash calculation on the first secret value to obtain a second token.

[0212] Optionally, in this embodiment, the client identifier can be an IP address, physical address, etc. of the target client, and the server can identify the corresponding target client based on the client identifier. Optionally, the target token is a token generated based on the target client's last access to the server.

[0213] Optional, such as Figure 2 As shown, when the target client accesses a single resource in the server, the server iterates N times to calculate the first access token and verifies the legitimacy of the access. In each subsequent access, the token is iterated until the access ends. That is, the server can determine the client identifier of the target client and the target token through the access request of the target client, and the server can determine the server's last access token based on the client identifier of the target client. The second token can be calculated by the above formulas (1)-(3) respectively, and the single resource and reverse access to the server can be performed based on the second token.

[0214] It should be noted that determining the current token through the client identifier improves the accuracy of determining the current token based on the unique client identifier.

[0215] Furthermore, the processing device for resource access requests also includes: a second access request receiving module, a second token determination module, a fourth iterative calculation module, a fifth iterative calculation module and a repeated execution module. The second access request receiving module is used to receive a resource access request sent by a target client when the target client successfully accesses the server for the first time and when the target client accesses multiple resources in the server, wherein the resource access request includes at least a client identifier of the target client and a target token, and the target token is obtained by iterating the token of the last access to the server by the target client; the second token determination module is used to determine the K-1th access token of the server based on the client identifier, and the Q accessible resources corresponding to the target client, wherein each accessible resource has a corresponding sub-token, and Q is a positive integer greater than 1. ; The fourth iterative calculation module is used to use the K-1th access token as the salt value, and perform salted hash calculation on the sum of the K-1th access token of the server and the secret value corresponding to the K-1th access token to obtain the current secret value; the fifth iterative calculation module is used to use the sub-token of the K+ith accessible resource accessed by the target client this time as the salt value, and perform salted hash calculation on the current secret value to obtain the Kth access token, where 1≤i≤Q; the repeated execution module is used for step 5, and steps 3 to 4 are repeatedly executed until the number of executions reaches Q times, and the token corresponding to the target client accessing multiple accessible resources is obtained.

[0216] Optionally, in this embodiment, if Figure 2 As shown, when the target client accesses multiple resources in the server, that is, when the resource access type is a multi-resource access type, the server will issue another token for each accessed resource, and iterate N times to calculate the access token, while verifying the legitimacy of the access. Then, at each access, the server iterates the token according to the accessed resource until the access ends. That is, the server can greatly reduce the risk of leakage of each token by combining the various subsets of resources divided in the zero trust model and using the irreversibility of the hash algorithm to combine the token iterations of multi-resource access. For example, the accessible application resources are divided into several subsets, and the access rights of i resource subsets are obtained through a rigorous authentication process. It is usually possible to match the policies related to the terminal operating environment of the accessing user, the policies related to the user's organizational information, and other general policies, and then decide which resource subsets to authorize access rights for.

[0217] Optionally, the server determines the K-1th access token of the server and Q accessible resources corresponding to the target client based on the client identifier, where each accessible resource has a corresponding sub-token, Q is a positive integer greater than 1, and then allocates i sub-tokens to the target client, one sub-token for each resource, which are denoted as t1, t2, ..., t iSub-tokens can be distributed through a highly secure key exchange algorithm or directly transmitted in a secure channel. Sub-tokens are usually proof of user access to corresponding resources and can be distributed, revoked, etc. based on policy matching.

[0218] This embodiment stipulates that the first access is used to verify the legitimacy of the client's identity and does not actually access a specific resource. After the first access, the verification process for subsequent accesses to resources is as follows: If the client accesses resource j, 0≤j≤i, where t j is the sub-token for resource j assigned to the user, [t] K-1 As the current token, when accessing resource j, the following calculation is performed to determine the token [t] of resource j among the K+i resources accessing the server this time. K , and update the value of secret:

[0219] [t] K =sha(secret,t j ) (7)

[0220] secret = sha(secret + [t] K ,[t] K )

[0221] Optionally, the next time you access any resource, assuming the resource number is p, the token continues to iterate using the above formula, replacing t in the above formula with j Replace with t p , where t p is the sub-token assigned to resource p. The above algorithm is known to the server, so the token can be easily verified.

[0222] Furthermore, the above formula (7) is repeatedly executed until the number of executions reaches Q times, and a token corresponding to when the target client accesses multiple accessible resources is obtained.

[0223] It should be noted that when accessing multiple resources, the secret can be regarded as an agreed value that is secretly calculated and updated by the client and the server at all times. The agreed value summarizes the tokens corresponding to multiple resource subsets. Since the summary process is completely irreversible, it is impossible to deduce the individual tokens before the summary through the summary result. Therefore, the process uses the summary calculation of multiple tokens to protect the privacy of each token. In addition, the secret value that is always maintained can also be used as an agreed token to re-encrypt private data, such as passwords, terminal environment information, user information, etc. Since the secret is constantly changing, it is impossible for attackers to find a pattern. Therefore, it is relatively safe to use the secret value as the key for symmetric encryption to re-encrypt some private data.

[0224] Furthermore, the resource access request processing device also includes: an access request judgment module, which is used to determine that the resource access request of the target client is a normal access request when the second token is consistent with the target token, and allow the target client to access the server; when the second token is inconsistent with the target token, determine that the resource access request of the target client is an illegal access request, and prohibit the target client from accessing the server.

[0225] Optionally, the server determines whether to allow the target client to access the server's resources by identifying whether the second token is consistent with the target token. When the second token is consistent with the target token, the target client's resource access request is determined to be a normal access request, and access to the server's resources is allowed; when the second token is inconsistent with the target token, the target client's resource access request is determined to be an illegal access request, and access to the server's resources is not allowed.

[0226] Furthermore, the resource access request processing device also includes: a token update module, which is used to update the target token in the server and send the target application resource and / or confirmation information to the target client, so that the target client updates the target token in the target client.

[0227] Optionally, after determining that the resource access request is a normal access request, the target application resource and / or confirmation information is sent to the target client, so that the target client updates the target token.

[0228] It should be noted that by sending the target application resources and / or confirmation information to the target client so that the target client updates the target token, attacks on the server can be prevented, thereby further improving the security of resource access.

[0229] Example 3

[0230] According to another aspect of an embodiment of the present invention, a computer-readable storage medium is provided, in which a computer program is stored, wherein the computer program is configured to execute the above-mentioned method for processing resource access requests when running.

[0231] Example 4

[0232] According to another aspect of an embodiment of the present invention, there is also provided an electronic device, wherein: Figure 4 is a schematic diagram of an optional electronic device according to an embodiment of the present invention, such as Figure 4 As shown, the electronic device includes one or more processors; a memory for storing one or more programs, which, when the one or more programs are executed by the one or more processors, enables the one or more processors to run the programs, wherein the programs are configured to execute the above-mentioned resource access request processing method when running.

[0233] Example 5

[0234] According to another aspect of an embodiment of the present invention, a computer program product is provided, including a computer program / instruction, and when the computer program / instruction is executed by a processor, the method for processing a resource access request is implemented.

[0235] The serial numbers of the above embodiments of the present invention are only for description and do not represent the advantages or disadvantages of the embodiments.

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

[0237] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the units can be a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0238] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple units. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0239] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0240] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for a computer device (which can be a personal computer, a server or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, magnetic disk or optical disk and other media that can store program codes.

[0241] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principle of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. A method for processing a resource access request, characterized in that: include: When the target client connects to the server for the first time, determining an initial token, wherein the initial token is determined by negotiation between the target client and the server based on a preset algorithm; Iterate the initial token N times to obtain the first access token of the server; Identify the correctness of the first access token of the target client based on the first access token of the server to obtain an identification result, wherein the first access token of the target client is obtained by the target client iterating the initial token N times; Wherein, the target client iterates the initial token N times to obtain the first access token of the target client in the following manner: step 11, using the initial token as a salt value, performing salted hash calculation on the initial token to obtain a first token; step 12, using the first token as a salt value, performing salted hash calculation on the sum of the initial token and the first token to obtain a first secret value; step 13, using the initial token as a salt value, performing salted hash calculation on the first secret value to obtain a second token; step 14, using the second token as a salt value, updating the first token based on the second token, performing salted hash calculation on the sum of the initial token and the second token to obtain a second secret value; step 15, using the initial token as a salt value, performing salted hash calculation on the second secret value to obtain a third token; step 16, repeating steps 14 to 15 until the number of executions reaches N times, and determining that the third token is the first access token of the target client; In the case where the identification result indicates that the first access token of the target client is a correct token, the target client is allowed to access resources in the server, wherein, when it is not the first time for the target client to access the server, the server iterates the last access token of the server to determine whether the access request of the target client is legal, the last access token is obtained by iterating the first access token of the server K times, and K+1 is the number of times the target client accesses the server.

2. The method according to claim 1, characterized in that Identifying the correctness of the first access token of the target client based on the first access token of the server includes: Step 21, using the initial token as a salt value, performing salted hash calculation on the initial token to obtain a first token; Step 22, using the first token as a salt value, performing a salted hash calculation on the sum of the initial token and the first token to obtain a first secret value; Step 23, using the initial token as a salt value, performing salted hash calculation on the first secret value to obtain a second token; Step 24, using the second token as a salt value, updating the first token based on the second token, performing a salted hash calculation on the sum of the initial token and the second token to obtain a second secret value; Step 25, using the initial token as a salt value, performing salted hash calculation on the second secret value to obtain a third token; Step 26, identifying whether the third token is consistent with the first access token of the target client; if the third token is consistent with the first access token of the target client, determining that the third token is the first access token of the server; if the third token is inconsistent with the first access token of the target client, repeating steps 24 to 26 until the number of executions reaches N times, and rejecting the access request of the target client.

3. The method according to claim 1, characterized in that The method further comprises: Step 31, when the target client successfully accesses the server for the first time and the target client accesses a single resource in the server, receiving a resource access request sent by the target client, wherein the resource access request includes at least a client identifier of the target client and a target token, and the target token is obtained by iterating the token used by the target client to access the server last time; Step 32, determining the last access token of the server based on the client identifier; Step 33, using the last access token as a salt value, performing salted hash calculation on the last access token of the server to obtain a first token; Step 34, using the first token as a salt value, performing a salted hash calculation on the sum of the last access token and the first token to obtain a first secret value; Step 35, using the last access token as a salt value, performing salted hash calculation on the first secret value to obtain a second token.

4. The method according to claim 1, characterized in that: The method further comprises: Step 41, when the target client successfully accesses the server for the first time and the target client accesses multiple resources in the server, receiving a resource access request sent by the target client, wherein the resource access request at least includes a client identifier of the target client and a target token, and the target token is obtained by iterating the token used by the target client to access the server last time; Step 42, determining the K-1th access token of the server and Q accessible resources corresponding to the target client based on the client identifier, wherein each accessible resource has a corresponding sub-token; Step 43, using the sub-token of the K+ith accessible resource accessed by the target client as a salt value, performing salted hash calculation on the current secret value to obtain the Kth access token, wherein 1≤i≤Q, and the current secret value is determined by using the K-1th access token as a salt value and performing salted hash calculation on the sum of the secret values ​​corresponding to the K-1th access token of the server and the K-1th access token; Step 44, repeating step 43 until the number of executions reaches Q times, and obtaining a token corresponding to when the target client accesses multiple accessible resources.

5. The method according to claim 3, characterized in that: After performing salted hash calculation on the first secret value to obtain a second token, the method further includes: When the second token is consistent with the target token, determining that the resource access request of the target client is a normal access request, and allowing the target client to access the server; In the case that the second token is inconsistent with the target token, it is determined that the resource access request of the target client is an illegal access request, and the target client is prohibited from accessing the server.

6. The method according to claim 5, characterized in that After determining that the resource access request of the target client is a normal access request, the method further includes: The target token in the server is updated, and the target application resource and / or confirmation information is sent to the target client, so that the target client updates the target token in the target client.

7. A resource access request processing device, characterized in that: include: A token determination module, used to determine an initial token when a target client connects to a server for the first time, wherein the initial token is determined by negotiation between the target client and the server based on a preset algorithm; An iterative calculation module, used for iterating the initial token N times to obtain a first access token of the server; A request identification module, used to identify the correctness of the first access token of the target client based on the first access token of the server, and obtain an identification result, wherein the first access token of the target client is obtained by the target client iterating the initial token N times; The processing device for resource access request also includes: a target iteration calculation module, which is used for the target client to iterate the initial token N times to obtain the first access token of the target client in the following manner: step 11, using the initial token as a salt value, performing a salted hash calculation on the initial token to obtain a first token; step 12, using the first token as a salt value, performing a salted hash calculation on the sum of the initial token and the first token to obtain a first secret value; step 13, using the initial token as a salt value, performing a salted hash calculation on the first secret value to obtain a second token; step 14, using the second token as a salt value, updating the first token based on the second token, performing a salted hash calculation on the sum of the initial token and the second token to obtain a second secret value; step 15, using the initial token as a salt value, performing a salted hash calculation on the second secret value to obtain a third token; step 16, repeating steps 14 to 15 until the number of executions reaches N times, and determining that the third token is the first access token of the target client; A result identification module is used to allow the target client to access resources in the server if the identification result indicates that the first access token of the target client is a correct token, wherein, when the target client is not accessing the server for the first time, the server iterates the last access token of the server to determine whether the access request of the target client is legal, and the last access token is obtained by iterating the first access token of the server K times, and K+1 is the number of times the target client accesses the server.

8. A computer-readable storage medium, characterized in that: A computer program is stored in a computer-readable storage medium, wherein when the computer program is executed, the device where the computer-readable storage medium is located executes the method for processing resource access requests described in any one of claims 1 to 6.

9. An electronic device, characterized in that: The electronic device includes one or more processors; A memory for storing one or more programs, which, when executed by the one or more processors, enables the one or more processors to execute the method for processing resource access requests described in any one of claims 1 to 6.

Images