Access Authentication Method, Device, Electronic Device, and Storage Medium

Abstract

The present application relates to an access authentication method, apparatus, electronic device, and storage medium, which are applied to the field of data processing technology. The method includes: obtaining an access request sent by a client; sending a verification factor to the client, so that the client calculates a proof-of-work parameter based on the verification factor and sends the verification factor and the proof-of-work parameter to the server; obtaining the verification factor and the proof-of-work parameter sent by the client; verifying the verification factor and the proof-of-work parameter, and if the verification passes, accepting the access request. This is to solve the problems in the prior art that in the case of malicious calls to interfaces, by adopting mechanisms such as traffic limiting or blocking access lists, malicious users can carry out distributed attacks, resulting in the inability to completely prevent such situations from occurring; at the same time, adopting the traffic limiting method may also cause inconvenience to the access of normal users.

Description

Technical Field

[0001] This application relates to the technical field of data processing, and in particular, to an access authentication method, apparatus, electronic device, and storage medium. Background Art

[0002] In existing authentication methods for various information systems, generally the account password method is adopted. After obtaining the authentication token, the user can access various information systems smoothly. When all users have no malicious intentions, the information system will provide services normally to the outside world. However, among malicious users, it may cause damage to the system. For example, maliciously making repeated high-speed calls to the same interface, consuming the precious bandwidth and computing resources of the information system.

[0003] In the related art, in the face of the situation where an interface is maliciously called, often only the mechanisms of flow limiting or blocking the access list are adopted. However, in this way, malicious users can carry out distributed attacks, resulting in the inability to completely prevent this situation from occurring; at the same time, adopting the flow limiting method may also bring inconvenience to the access of normal users. Summary of the Invention

[0004] This application provides an access authentication method, apparatus, electronic device, and storage medium to solve the problem in the prior art that in the face of the situation where an interface is maliciously called, often only the mechanisms of flow limiting or blocking the access list are adopted. However, in this way, malicious users can carry out distributed attacks, resulting in the inability to completely prevent this situation from occurring; at the same time, adopting the flow limiting method may also bring inconvenience to the access of normal users.

[0005] In a first aspect, an embodiment of this application provides an access authentication method, including:

[0006] Obtain an access request sent by a client;

[0007] Send a verification factor to the client, so that the client calculates a proof-of-work parameter based on the verification factor, and sends the verification factor and the proof-of-work parameter to the server;

[0008] Obtain the verification factor and the proof-of-work parameter sent by the client;

[0009] Verify the verification factor and the proof-of-work parameter. If the verification passes, accept the access request.

[0010] Optionally, the verification of the verification factor and the proof-of-work parameter includes:

[0011] Determine whether the verification factor exists locally;

[0012] If it exists, determine whether the verification factor and the proof-of-work parameter are correct;

[0013] If correct, determine that the verification factor and the proof-of-work parameter pass the verification.

[0014] Optionally, before sending the verification factor to the client, it further includes:

[0015] Generate the verification factor, or obtain the pre-generated verification factor.

[0016] Optionally, generating the verification factor includes:

[0017] Obtain the workload difficulty coefficient and the working parameters of the server;

[0018] Generate a proof-of-work parameter based on the workload difficulty coefficient and the working parameters;

[0019] Calculate the verification factor based on the proof-of-work parameter, the workload difficulty coefficient, and the working parameters.

[0020] Optionally, the method further includes:

[0021] Determine a first access frequency based on the obtained access request;

[0022] When it is monitored that the first access frequency exceeds a preset frequency threshold, increase the workload difficulty coefficient and regenerate the verification factor.

[0023] Optionally, it further includes:

[0024] Determine a second access frequency for each client based on the access request of each client;

[0025] When it is detected that the second access frequency of the target client is higher than the access frequencies of other clients, increase the workload difficulty coefficient and generate a verification factor to be sent to the target client based on the increased workload difficulty coefficient.

[0026] Optionally, the server is a blockchain server, and the method further includes:

[0027] Clean up the stored blocks at every preset time interval so that the number of blocks does not exceed a preset block threshold.

[0028] In a second aspect, an access authentication method provided by an embodiment of the present application is applied to a client and includes:

[0029] Send an access request to the server so that the server sends a verification factor to the client;

[0030] Calculate the proof-of-work parameter based on the verification factor;

[0031] Send the verification factor and the proof-of-work parameter to the server, so that the server verifies the verification factor and the proof-of-work parameter, and accepts the access request after the verification passes.

[0032] Optionally, the server is a blockchain server. Before sending an access request to the server, it further includes:

[0033] Send transaction information to the blockchain, so that the blockchain generates a transaction hash and sends it to the client;

[0034] The sending of the access request to the server includes:

[0035] Add the transaction hash to the access request and then send it to the server, so that the server verifies whether the transaction hash exists.

[0036] In a third aspect, an embodiment of the present application provides an access authentication system, including: a client and a server;

[0037] The client is used to send an access request to the server;

[0038] The server is used to obtain the access request sent by the client; send a verification factor to the client;

[0039] The client is further used to calculate a proof-of-work parameter based on the verification factor; send the verification factor and the proof-of-work parameter to the server;

[0040] The server is further used to obtain the verification factor and the proof-of-work parameter sent by the client; verify the verification factor and the proof-of-work parameter, and if the verification passes, accept the access request.

[0041] In a fourth aspect, an embodiment of the present application provides an access authentication device, including:

[0042] A first acquisition module, configured to acquire an access request sent by a client;

[0043] A first sending module, configured to send a verification factor to the client, so that the client calculates a proof-of-work parameter based on the verification factor, and sends the verification factor and the proof-of-work parameter to the server;

[0044] A second acquisition module, configured to acquire the verification factor and the proof-of-work parameter sent by the client;

[0045] A verification module, configured to verify the verification factor and the proof-of-work parameter, and if the verification is passed, accept the access request.

[0046] In a fifth aspect, an embodiment of the present application provides an access authentication device, including:

[0047] A second sending module, configured to send an access request to a server, so that the server sends a verification factor to the client;

[0048] A calculation module, configured to calculate a proof-of-work parameter based on the verification factor;

[0049] A third sending module, configured to send the verification factor and the proof-of-work parameter to the server, so that the server verifies the verification factor and the proof-of-work parameter, and if the verification is passed, accepts the access request.

[0050] In a sixth aspect, an embodiment of the present application provides an electronic device, including: a processor, a communication interface, a memory, and a communication bus, where the processor, the communication interface, and the memory complete communication with each other through the communication bus;

[0051] The memory is configured to store a computer program;

[0052] The processor is configured to execute the program stored in the memory to implement the access authentication method described in the first aspect or the second aspect.

[0053] In a seventh aspect, an embodiment of the present application provides a computer-readable storage medium, storing a computer program, where the computer program, when executed by a processor, implements the access authentication method described in the first aspect or the second aspect.

[0054] The above technical solutions provided by the embodiments of the present application have the following advantages compared with the prior art: In the method provided by the embodiments of the present application, by obtaining an access request sent by a client; sending a verification factor to the client, so that the client calculates a proof-of-work parameter based on the verification factor, and sends the verification factor and the proof-of-work parameter to the server; obtaining the verification factor and the proof-of-work parameter sent by the client; verifying the verification factor and the proof-of-work parameter, and if the verification is passed, accepting the access request. In this way, after the client initiates an access request, the client can be authenticated based on the verification factor. By calculating the verification factor by the client and accepting its access request after the calculation result is verified. On the one hand, the calculation amount of the verification factor is not large and has little impact on the access of ordinary clients. On the other hand, when the client makes high-speed and repeated malicious accesses, the access cost of the client is increased through the calculation amount. Description of the Drawings

[0055] The accompanying drawings herein are incorporated into the specification and form a part of the specification, showing embodiments consistent with the present invention and used together with the specification to explain the principles of the present invention.

[0056] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the accompanying drawings required for the description of the embodiments or the prior art. Obviously, for those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0057] Figure 1 The structural diagram of an access authentication system provided by an embodiment of the present application;

[0058] Figure 2 The flowchart of an access authentication method provided by an embodiment of the present application;

[0059] Figure 3 The flowchart of an access authentication method provided by another embodiment of the present application;

[0060] Figure 4 The structural diagram of an access authentication device provided by an embodiment of the present application;

[0061] Figure 5 The structural diagram of an access authentication device provided by another embodiment of the present application;

[0062] Figure 6 The structural diagram of an electronic device provided by an embodiment of the present application. Detailed Embodiments

[0063] To make the objectives, technical solutions, and advantages of the embodiments of the present application clearer, the following will clearly and completely describe the technical solutions in the embodiments of the present application with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are some, but not all, of the embodiments of the present application. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present application without creative efforts fall within the scope of protection of the present application.

[0064] According to an embodiment of the present application, an access authentication system is provided. Optionally, in the embodiment of the present application, the above access authentication system can be applied to a hardware environment composed of a client 101 and a server 102 as shown in Figure 1 the figure. As shown in Figure 1As shown, the server is connected to the client through a network and can be used to provide services to the client (such as video services, application services, etc.). A database can be set up on the server to provide data storage services for the server. The above network includes but is not limited to: wide area network, metropolitan area network or local area network. The client is not limited to PCs, mobile phones, tablets, etc.

[0065] Among them, the client is used to send an access request to the server.

[0066] The server is used to obtain the access request sent by the client; and send a verification factor to the client.

[0067] The client is further used to calculate a proof-of-work parameter based on the verification factor; and send the verification factor and the proof-of-work parameter to the server.

[0068] The server is further used to obtain the verification factor and the proof-of-work parameter sent by the client; verify the verification factor and the proof-of-work parameter, and if the verification passes, accept the access request.

[0069] An embodiment of the present application also provides an access authentication method. This method can be executed by the server or by the client.

[0070] Taking the server executing the access authentication method of the embodiment of the present application as an example, Figure 2 is a schematic flowchart of an optional access authentication method according to an embodiment of the present application, as Figure 2 shown, the process of this method can include the following steps:

[0071] Step 201, obtain the access request sent by the client.

[0072] In some embodiments, the access request sent by the client can be an access request for a certain interface, a certain video, or a certain information system, etc.

[0073] Step 202, send a verification factor to the client, so that the client calculates a proof-of-work parameter based on the verification factor and sends the verification factor and the proof-of-work parameter to the server.

[0074] In some embodiments, the verification factor can be pre-generated and stored in the database, or can be generated after the server receives the access request. Among them, the verification factor can be generated according to a preset generation rule, so that after being sent to the client, the client can perform an inverse operation based on this generation rule to obtain the proof-of-work parameter.

[0075] Generally, after generating the verification factor on the server side, at least one backup verification factor will be generated based on the above method. If the number of backup verification factors exceeds the preset threshold, no more will be generated. In this way, the inflation rate of the verification factors can be restricted, and excessive occupation of storage space can be avoided.

[0076] In an alternative embodiment, the generating of the verification factor includes:

[0077] Obtain the workload difficulty coefficient and the working parameters of the server side; generate the proof-of-work parameter based on the workload difficulty coefficient and the working parameters; calculate the verification factor based on the proof-of-work parameter, the workload difficulty coefficient, and the working parameters.

[0078] In some embodiments, the workload difficulty coefficient is used to characterize the difficulty level of the calculation process of the proof-of-work parameter. The larger the workload difficulty coefficient, the more difficult the calculation process of the proof-of-work parameter. Among them, the workload difficulty coefficient can be set with an initial value, which can be increased subsequently according to the access behavior of the client. This initial value can be set to 1, but is not limited thereto. Further, a maximum value can also be set for the workload difficulty coefficient to avoid excessive calculation difficulty for ordinary clients.

[0079] Among them, there are various working parameters of the server side. In this embodiment, taking the server side as a blockchain server side as an example, the working parameter can be the transaction duration of any block Block i in the blockchain, including the longest transaction duration and the shortest transaction duration.

[0080] Exemplarily, taking the proof-of-work parameter as z, the workload difficulty coefficient as P, and the working parameter as the longest transaction duration R i and the shortest transaction duration L i as an example, the generated verification factor can be that first, a string J is generated based on the above parameters, J = z + Str + L i + R i + P, that is, this string J is obtained by splicing the above parameters.

[0081] Among them, Str is a random character generated by the server side, i is the block number in the blockchain, and z is a random number within the integer range [L i × P, R i × P].

[0082] Further, after performing a hash operation on this string J, the verification factor H is generated together with the above parameters, H = hash(J) + Str + L i + R i + P.

[0083] Among them, the hash function can be any one of the hash functions, such as md5, etc.

[0084] Correspondingly, after sending the verification factor to the client, the client performs an inverse operation on the verification factor. Based on the above related embodiments, the verification factor H = hash(J) + Str + L i + R i + P. When performing the operation, the verification factor is decomposed according to the number of characters occupied by each parameter to obtain hash(J), Str, Li, Ri, and P. The user side enumerates z in the interval [L i × P, R i × P] to determine the finally obtained z, that is, the proof-of-work parameter. By enumerating z, substitute z into the calculation formula of J for hash operation, and compare the obtained hash result with hash(J). When the two are consistent, determine the corresponding z as the proof-of-work parameter calculated by the client. It can be seen that P plays a role in controlling the difficulty in the process. The larger P is, the longer it takes for the client to enumerate z.

[0085] It can be understood that in the above expressions of J and H, the order of each character can be set based on the actual situation, or new characters can be set based on the actual situation. After setting the expressions of J and H, store the positional relationship of their characters so that the corresponding characters can be parsed based on this positional relationship during subsequent operations.

[0086] Step 203, obtain the verification factor and the proof-of-work parameter sent by the client.

[0087] In some embodiments, after the client calculates the proof-of-work parameter, both the proof-of-work parameter and the verification factor are sent to the server for the server to verify the two.

[0088] Step 204, verify the verification factor and the proof-of-work parameter. If the verification passes, accept the access request.

[0089] In some embodiments, by verifying the verification factor and the proof-of-work parameter, the security of the authentication process can be improved, and the situation where the client can also achieve access by randomly generating the verification factor and the proof-of-work parameter can be avoided. After the verification passes, it means that the client can access the server, and then the access request is accepted. If the verification fails, the server sends the verification factor to the client again, and can also send a prompt message to the client to give an alarm to the client.

[0090] In an alternative embodiment, the verification of the verification factor and the proof-of-work parameter includes:

[0091] Determine whether the verification factor exists locally; if it exists, determine whether the verification factor and the proof-of-work parameter are correct; if they are correct, determine that the verification factor and the proof-of-work parameter pass the verification.

[0092] In some embodiments, it is possible but not limited to use a Bloom filter to determine whether the verification factor sent by the client exists in the server. The Bloom filter has the characteristics of high space efficiency and short query time. Based on the Bloom filter, the existence of the verification factor can be quickly determined, avoiding a large amount of calculations in the system.

[0093] When the verification factor exists in the server, the correctness of the verification factor and the proof-of-work parameter can be further verified. Determine whether the proof-of-work parameter corresponding to the verification factor sent by the client is consistent with the verification factor and the proof-of-work parameter stored in the server. When the two are consistent, determine that the verification passes.

[0094] In an alternative embodiment, the parameters for generating the verification factor include a work difficulty coefficient. The access authentication method of the present application further includes:

[0095] Determine a first access frequency based on the obtained access request; when it is monitored that the first access frequency exceeds a preset frequency threshold, increase the work difficulty coefficient and regenerate the verification factor.

[0096] When it is detected that the access frequency is relatively fast, it indicates that the access volume of the current server access interface is relatively large. By increasing the work difficulty coefficient and regenerating the verification factor, the calculation amount of the user side for calculating the proof-of-work parameter based on the verification factor is increased, so as to achieve the purpose of increasing the attacker's cost.

[0097] In an alternative embodiment, the parameters for generating the verification factor include a work difficulty coefficient. The access authentication method of the present application further includes:

[0098] Determine a second access frequency for each client based on the access request of each client; when it is detected that the second access frequency of the target client is higher than the access frequencies of other clients, increase the work difficulty coefficient and generate a verification factor sent to the target client based on the increased work difficulty coefficient.

[0099] In some embodiments, when it is monitored that the access frequency of a certain client is relatively high, the calculation amount of the client can be increased by increasing the work difficulty coefficient of the client, so as to isolate suspicious attackers, set a specific work difficulty coefficient for them, and increase their attack cost.

[0100] In an alternative embodiment, the server is a blockchain server, and the method further includes:

[0101] Clean the stored blocks at preset time intervals so that the number of the blocks does not exceed a preset block threshold.

[0102] In some embodiments, a lot of transactions are generated in the blockchain server. By cleaning the stored blocks, the storage pressure of the blockchain can be reduced, and at the same time, the randomness of the information on the blockchain can be improved to prevent the information from being predicted.

[0103] The access authentication method of the present application provides a new method based on the proof of work of the blockchain. By increasing the computing cost of attackers or malicious users, the malicious access that the information system bears is greatly alleviated, and at the same time, normal users are hardly affected. And based on the blockchain system, traces of visitors can be left for easy tracking. The access difficulty can be adjusted automatically or manually, and the difficulty can be flexibly controlled, improving the convenience of the authentication process. The calculation of the hash greatly increases the attack cost of distributed attackers, making it impossible to attack.

[0104] Based on the same concept, another access authentication method is provided in the embodiments of the present application. Taking the client executing the access authentication method of the embodiments of the present application as an example, the specific implementation of this method can be seen in the description of the method embodiments, and the repeated parts will not be elaborated. As Figure 3 shown, this method mainly includes:

[0105] Step 301, send an access request to the server so that the server sends a verification factor to the client.

[0106] Step 302, calculate the proof-of-work parameter based on the verification factor.

[0107] Step 303, send the verification factor and the proof-of-work parameter to the server so that the server verifies the verification factor and the proof-of-work parameter, and after the verification passes, accepts the access request.

[0108] In an optional embodiment, the server is a blockchain server. Before sending the access request to the server, it further includes:

[0109] Send transaction information to the blockchain so that the blockchain generates a transaction hash and sends it to the client;

[0110] The sending of the access request to the server includes:

[0111] Add the transaction hash to the access request and then send it to the server so that the server verifies whether the transaction hash exists.

[0112] In some embodiments, before the client accesses the server, it needs to send an ordinary transaction on the blockchain. The content of the transaction can be random and arbitrary. After obtaining the transaction hash, each time an access request is initiated, the transaction hash needs to be attached. In this way, random information can be provided for the blockchain. Further, the server verifies the existence of the transaction hash to improve the security of the authentication process.

[0113] Based on the same concept, an access authentication device is provided in an embodiment of the present application. For the specific implementation of this device, reference can be made to the description in the method embodiment section, and repeated parts will not be elaborated again. As Figure 4 shown, this device mainly includes:

[0114] A first acquisition module 401, configured to acquire an access request sent by the client;

[0115] A first sending module 402, configured to send a verification factor to the client, so that the client calculates a proof-of-work parameter based on the verification factor, and sends the verification factor and the proof-of-work parameter to the server;

[0116] A second acquisition module 403, configured to acquire the verification factor and the proof-of-work parameter sent by the client;

[0117] A verification module 404, configured to verify the verification factor and the proof-of-work parameter. If the verification is passed, the access request is accepted.

[0118] Based on the same concept, an access authentication device is provided in an embodiment of the present application. For the specific implementation of this device, reference can be made to the description in the method embodiment section, and repeated parts will not be elaborated again. As Figure 5 shown, this device mainly includes:

[0119] A second sending module 501, configured to send an access request to the server, so that the server sends a verification factor to the client;

[0120] A calculation module 502, configured to calculate a proof-of-work parameter based on the verification factor;

[0121] A third sending module 503, configured to send the verification factor and the proof-of-work parameter to the server, so that the server verifies the verification factor and the proof-of-work parameter, and accepts the access request after the verification is passed.

[0122] Based on the same concept, an electronic device is also provided in an embodiment of the present application. As Figure 6As shown in the figure, the electronic device mainly includes: a processor 601, a memory 602, and a communication bus 603. Among them, the processor 601 and the memory 602 communicate with each other through the communication bus 603. Among them, a program executable by the processor 601 is stored in the memory 602, and the processor 601 executes the program stored in the memory 602 to implement the following steps:

[0123] Obtain an access request sent by the client;

[0124] Send a verification factor to the client, so that the client calculates a proof-of-work parameter based on the verification factor, and sends the verification factor and the proof-of-work parameter to the server;

[0125] Obtain the verification factor and the proof-of-work parameter sent by the client;

[0126] Verify the verification factor and the proof-of-work parameter. If the verification passes, accept the access request. Or,

[0127] Send an access request to the server, so that the server sends a verification factor to the client;

[0128] Calculate a proof-of-work parameter based on the verification factor;

[0129] Send the verification factor and the proof-of-work parameter to the server, so that the server verifies the verification factor and the proof-of-work parameter, and accepts the access request after the verification passes.

[0130] The communication bus 603 mentioned in the above electronic device may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The communication bus 603 can be divided into an address bus, a data bus, a control bus, etc. For the sake of convenience of representation, Figure 6 only a thick line is used to represent it in the figure, but it does not mean that there is only one bus or one type of bus.

[0131] The memory 602 may include a Random Access Memory (RAM), or may include a non-volatile memory, such as at least one disk memory. Optionally, the memory may also be at least one storage device located far from the aforementioned processor 601.

[0132] The above-mentioned processor 601 may be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc., or may also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0133] In another embodiment of the present application, a computer-readable storage medium is further provided. A computer program is stored in the computer-readable storage medium. When the computer program runs on a computer, the computer is enabled to execute the access authentication method described in the above embodiment.

[0134] In the above embodiment, it can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, the processes or functions described in the embodiments of the present application are generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions are transmitted from one website, computer, server, or data center to another website, computer, server, or data center by wire (such as coaxial cable, optical fiber, Digital Subscriber Line (DSL)) or wireless (such as infrared, microwave, etc.). The computer-readable storage medium may be any available medium that can be accessed by a computer, or a data storage device such as a server or data center that includes one or more integrated available media. The available medium may be a magnetic medium (such as a floppy disk, hard disk, magnetic tape, etc.), an optical medium (such as a DVD), or a semiconductor medium (such as a solid-state drive), etc.

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

[0136] The above are only specific embodiments of the present invention, enabling those skilled in the art to understand or implement the present invention. Various modifications to these embodiments will be obvious to those skilled in the art, and the general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention will not be limited to these embodiments shown herein, but rather to the broadest scope consistent with the principles and novel features claimed herein.

Claims

1. An access authentication method, characterized in that, A server applied to a blockchain, including: Obtaining an access request sent by a client; Sending a verification factor to the client, so that the client calculates a proof-of-work parameter based on the verification factor, and sends the verification factor and the proof-of-work parameter to the server; Obtaining the verification factor and the proof-of-work parameter sent by the client; Verifying the verification factor and the proof-of-work parameter. If the verification passes, accepting the access request; calculating the verification factor according to the following formula 1 and formula 2: J = z + Str + L i + R i + P(1) H = hash(J) + Str + L i + R i + P(2) Among them, z is the proof-of-work parameter, and its value is a random number within the integer interval [L i ×P, R i ×P], P is the proof-of-work difficulty coefficient, R i is the longest transaction duration in the work parameters, L i is the shortest transaction duration in the work parameters, and Str is the random character generated by the server; The client performs an inverse operation on the verification factor, decomposes the verification factor according to the number of characters occupied by each parameter, and obtains hash(J), Str, and L i , R i and P. By enumerating z in hash(J) within the range of [L i ×P, R i ×P], z is calculated 2. The access authentication method according to claim 1, wherein The verifying the verification factor and the proof-of-work parameter includes: Judging whether the verification factor exists locally; If it exists, judging whether the verification factor and the proof-of-work parameter are correct; If it is correct, determining that the verification factor and the proof-of-work parameter pass the verification.

3. The access authentication method according to claim 1, characterized in that, Before sending the verification factor to the client, it further includes: Generating the verification factor, or obtaining the pre-generated verification factor.

4. The access authentication method according to claim 3, wherein The generating the verification factor includes: Obtaining a workload difficulty coefficient and working parameters of the server; Generating a proof-of-work parameter based on the workload difficulty coefficient and the working parameters; Calculating the verification factor based on the proof-of-work parameter, the workload difficulty coefficient and the working parameters.

5. The access authentication method according to claim 4, wherein The method further includes: Determining a first access frequency based on the obtained access request; When it is monitored that the first access frequency exceeds a preset frequency threshold, increasing the workload difficulty coefficient and regenerating the verification factor.

6. The access authentication method according to claim 4, wherein It further includes: Determining a second access frequency of each client based on the access request of each client; When it is detected that the second access frequency of the target client is higher than the access frequencies of other clients, increasing the workload difficulty coefficient and generating a verification factor sent to the target client based on the increased workload difficulty coefficient.

7. The access authentication method according to claim 1, wherein The server is a blockchain server, and the method further includes: Cleaning the stored blocks at intervals of a preset duration, so that the number of blocks does not exceed a preset block threshold.

8. An access authentication method, characterized in that, Applied to a client, including: Sending an access request to a server of a blockchain, so that the server sends a verification factor to the client; Calculating a proof-of-work parameter based on the verification factor; Sending the verification factor and the proof-of-work parameter to the server, so that the server verifies the verification factor and the proof-of-work parameter, and accepts the access request after the verification passes; Wherein, the server calculates the verification factor according to the following formula 1 and formula 2: J = z + Str + L i + R i + P(1) H = hash(J) + Str + L i + R i + P(2) Among them, z is the proof-of-work parameter, and its value is a random number within the integer interval [L i ×P, R i ×P], P is the proof-of-work difficulty coefficient, R i is the longest transaction duration in the work parameters, L i is the shortest transaction duration in the work parameters, and Str is the random character generated by the server; The client performs an inverse operation on the verification factor, decomposes the verification factor according to the number of characters occupied by each parameter, and obtains hash(J), Str, and L i , R i and P. By enumerating z in the range of [L i ×P, R i ×P] in hash(J), z is calculated and obtained.

9. The access authentication method according to claim 8, wherein The server is a blockchain server. Before sending the access request to the server, it further includes: Sending transaction information to the blockchain, so that the blockchain generates a transaction hash and sends it to the client; The sending the access request to the server includes: Adding the transaction hash to the access request and then sending it to the server, so that the server verifies whether the transaction hash exists.

10. An access authentication device, characterized in that, A server applied to a blockchain, including: A first obtaining module, configured to obtain an access request sent by a client; A first sending module, configured to send a verification factor to the client, so that the client calculates a proof-of-work parameter based on the verification factor and sends the verification factor and the proof-of-work parameter to the server; A second obtaining module, configured to obtain the verification factor and the proof-of-work parameter sent by the client; A verification module, configured to verify the verification factor and the proof-of-work parameter, and if the verification is passed, accept the access request; Wherein, the server calculates the verification factor according to the following formula 1 and formula 2: J = z + Str + L i + R i + P(1) H = hash(J)+Str+L i +R i +P(2) Among them, z is the proof-of-work parameter, and its value is a random number within the integer interval [L i ×P, R i ×P], P is the proof-of-work difficulty coefficient, R i is the longest transaction duration in the work parameters, L i is the shortest transaction duration in the work parameters, and Str is the random character generated by the server; The client performs an inverse operation on the verification factor, decomposes the verification factor according to the number of characters occupied by each parameter, and obtains hash(J), Str, and L i , R i and P. By enumerating z in the range of [L i ×P, R i ×P] in hash(J), z is calculated and obtained.

11. An electronic device, characterized in that, Including: A processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory complete mutual communication through the communication bus; The memory is configured to store a computer program; The processor is configured to execute the program stored in the memory to implement the access authentication method according to any one of claims 1-7 or any one of claims 8-9.

12. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the access authentication method according to any one of claims 1-7 or any one of claims 8-9.

Images