Two-way HOTP Authentication Method, System, Device and Medium

Abstract

The present invention provides a two-way HOTP authentication method, system, device and medium, which relates to the field of computer technology. It includes: completed by the synchronization mechanism between the cloud and the device side. At the beginning, the cloud and the device side need to negotiate a common key KEY. The key can be generated by the cloud and sent to the device side, or directly imported on the device side. Therefore, only specific devices holding the key can generate valid HOTP passwords. Before the client device and the cloud perform identity verification, the cloud initializes the value of the counter to N, and the device side initializes the value of the counter to M = N + 1. Each authentication request from the device side will generate a HOTP password and send it to the cloud for verification. At the same time, the cloud will also generate a HOTP password for verification by the device side after successful verification. Both the cloud and the device side will only modify the value of the counter after successfully verifying the HOTP password of the other party, avoiding the situation where the counter keeps incrementing due to verification failure.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular, to a two-way HOTP authentication method, system, device, and medium. Background Art

[0002] Today, with the booming development of the Internet, network security threats are also growing rapidly. The traditional method of static passwords based on usernames and passwords can no longer meet the needs of industries with higher security requirements. Two-factor authentication authenticates users through a combination of passwords and physical objects (such as SMS mobile phones, tokens, etc.), and has gradually been adopted by some enterprises with higher security requirements. However, traditional two-factor authentication requires an additional hardware or tool to ensure security, and is usually expensive, directly increasing the enterprise cost. As one of the simplest and most popular two-factor authentication methods for protecting network access rights, one-time passwords have gradually become the mainstream.

[0003] HOTP is a one-time password based on event synchronization. By using a specific event sequence (COUNTER) and the same seed value (KEY) as inputs, the HMAC algorithm is used to generate a one-time password, which is widely used for the authentication of device terminals or user behaviors. This authentication mechanism depends on having a common HMAC key on both the cloud and terminal nodes, and a counter that is synchronized on both nodes. That is, if the HMAC (HMAC_KEY, COUNTER_DEVICE) on the terminal is consistent with the HMAC (HMAC_KEY, COUNTER_SERVER) on the cloud, then the one-time passwords generated by the cloud and the device terminal will be consistent, and the authentication can pass.

[0004] However, in actual use, the increase of the counters on the two nodes is not necessarily synchronized. Generally speaking, each time an authentication attempt is made, the counter on the terminal will increment by 1; after each successful authentication, the counter on the cloud will increment by 1. In extreme cases, if the authentication fails continuously, the HOTP counter on the terminal will exceed the HOTP counter on the cloud.

[0005] Existing methods generally avoid the problem of out-of-synchronization by trying several more counter values. For example, when the cloud performs HOTP comparison, if the result calculated by the current counter does not match, then the results obtained by additionally testing the current counter + 1, counter + 2, and counter + M will be checked for matching.

[0006] The problem is that in order to prevent the server from continuously detecting the HOTP value, the value of M is fixed and within a reasonable range. Once configured, there is still a possibility of not being able to adapt to the target scenario.

[0007] The present invention proposes a two-way authentication mechanism to avoid the problem of out-of-sync counters between the cloud and the device side, that is, the cloud and the device side achieve synchronization of the HOTP counters at both ends by respectively authenticating the HOTP calculation results of each other. Summary of the Invention

[0008] In view of the defects in the prior art, the present invention provides a two-way HOTP authentication method, system, device and medium.

[0009] According to the two-way HOTP authentication method, system, device and medium provided by the present invention, the solution is as follows:

[0010] In a first aspect, a two-way HOTP authentication method is provided, and the method includes:

[0011] Step S1: When the client device requests HOTP verification, read the key and counter from the device memory, calculate the HOTP password, and send it to the cloud;

[0012] Step S2: The cloud receives the HOTP password sent by the device side, and reads the cloud counter as N from the cloud memory; the cloud calculates the HOTP password according to the key saved in the cloud and the value of the cloud counter N + 1, and compares and verifies it with the password sent by the device side;

[0013] Step S3: After adding 1 to the value of the successfully verified counter in step S2, save it in the cloud memory, and the specific saved value is N + 2; the cloud recalculates the HOTP password according to the value of N + 2, and returns the new HOTP password to the device side;

[0014] Step S4: The device side receives the HOTP password returned by the cloud, recalculates the HOTP password according to the device side counter M + 1 and the key, and compares it with the HOTP password sent by the cloud; the value of the counter on the device side is incremented by 2 and saved, and at this time the counter value on the device side is M + 2, until the next HOTP verification request.

[0015] Preferably, the comparison and verification in step S2 includes:

[0016] 1) If the HOTP calculation results of the cloud and the device side are the same, jump to step S3;

[0017] 2) If the HOTP calculation results of the cloud and the device side are different, calculate the HOTP password according to the cloud key and the value of the counter N - 1, and compare it with the password sent by the device side; if the two are the same, update N to N–2, and jump to step S3; if the two are still different, it is considered that the keys of the device side and the cloud are different, and the authentication fails and is interrupted.

[0018] Preferably, if the HOTP calculation results on the cloud and the device are inconsistent, a fallback and retry mechanism for the cloud HOTP verification is included. If the cloud HOTP password for verification has not arrived due to network or other unpredictable reasons, resulting in authentication failure, the cloud will roll back the counter value and re-verify the HOTP password in the next verification request of the device.

[0019] Preferably, in step S4, the device side calculates the HOTP password and compares it with the HOTP password sent by the cloud. If the two are inconsistent, the verification fails; if the two are consistent, it means that the HOTP verification request of the device side is passed.

[0020] In a second aspect, a two-way HOTP authentication system is provided, the system comprising:

[0021] Module M1: When the client device requests HOTP authentication, it reads the key and counter from the device memory, calculates the HOTP password, and sends it to the cloud;

[0022] Module M2: The cloud receives the HOTP password from the device and reads the cloud counter N from the cloud storage. The cloud calculates the HOTP password based on the cloud-stored key and the value of the cloud counter N+1, and compares it with the password sent by the device for verification.

[0023] Module M3: adds 1 to the counter value of the successful verification in module M2 and saves it in the cloud storage, saving the specific value as N+2; the cloud recalculates the HOTP password based on the value of N+2 and returns the new HOTP password to the device;

[0024] Module M4: The device receives the HOTP password returned by the cloud, recalculates the HOTP password based on the device-side counter M+1 and the key, and compares it with the HOTP password sent by the cloud. The value of the counter on the device is incremented by 2 and saved. The counter value on the device is now M+2 until the next HOTP verification request.

[0025] Preferably, the comparison and verification of module M2 includes:

[0026] 1) If the HOTP calculation results on the cloud and the device are consistent, jump to module M3;

[0027] 2) If the HOTP calculation results on the cloud and device are inconsistent, the HOTP password is calculated based on the cloud key and the value of counter N-1 and compared with the password sent by the device. If the two are consistent, N is updated to N-2 and the process jumps to module M3. If the two are still inconsistent, the device and cloud keys are considered different, authentication fails, and is terminated.

[0028] Preferably, if the HOTP calculation results of the cloud and the device side are inconsistent, it includes a fallback retry mechanism for HOTP verification on the cloud side. If the HOTP password on the cloud side fails to be authenticated due to network or other unpredictable reasons, for the next verification request of the device, the cloud will roll back the value of the counter and re-verify the HOTP password.

[0029] Preferably, in module M4, the device side calculates the HOTP password and compares it with the HOTP password sent from the cloud. If the two are inconsistent, the verification fails; if the two are consistent, it means that the HOTP verification request of the device side this time passes.

[0030] In a third aspect, a computer-readable storage medium storing a computer program is provided. When the computer program is executed by a processor, the steps of the two-way HOTP authentication method are implemented.

[0031] In a fourth aspect, an electronic device is provided, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the computer program is executed by the processor, the steps of the two-way HOTP authentication method are implemented.

[0032] Compared with the prior art, the present invention has the following beneficial effects:

[0033] 1. By adopting the method of two-way HOTP mutual authentication, the present invention synchronizes the HOTP counters of the cloud and the device side, avoiding the out-of-sync of the counters between the cloud and the device side and solving the problem that HOTP cannot be adapted in certain scenarios.

[0034] 2. Through the fallback retry mechanism for HOTP verification on the cloud side, one two-way verification includes two verifications between the device side and the cloud side. If the second verification fails due to network or other unpredictable reasons, for the next verification request of the device, the cloud will roll back the value of the counter and re-verify the HOTP password, avoiding verification failure caused by the independent increment of the cloud counter.

[0035] Other beneficial effects of the present invention will be elaborated in the specific implementation manner through the introduction of specific technical features and technical solutions. Those skilled in the art should be able to understand the beneficial technical effects brought by the technical features and technical solutions through these introductions. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] By reading the detailed description of the non-restrictive embodiments with reference to the following drawings, other features, objectives, and advantages of the present invention will become more obvious:

[0037] Figure 1 It is a schematic flow chart of the present invention;

[0038] Figure 2 It is the flow chart of the HOTP algorithm. Specific implementation mode

[0039] The present invention will be described in detail below in conjunction with specific embodiments. The following embodiments will help those skilled in the art to further understand the present invention, but do not limit the present invention in any form. It should be noted that those of ordinary skill in the art can make several changes and improvements without departing from the concept of the present invention. These all belong to the protection scope of the present invention.

[0040] An embodiment of the present invention provides a two-way HOTP authentication method. Referring to Figure 1 as shown, the method includes:

[0041] Step S1: When the client device requests HOTP verification, read the key and counter from the device memory, calculate the HOTP password, and send it to the cloud. Initially, the value of the cloud counter N is 0, and the value of the device-side counter M is 1.

[0042] Step S2: The cloud receives the HOTP password sent by the device side and reads the cloud counter as N from the cloud memory. The cloud calculates the HOTP password according to the key saved in the cloud and the value of the cloud counter +1 (i.e., N + 1), and compares it with the password sent by the device side.

[0043] 1. If the HOTP calculation results of the cloud and the device side are the same, jump to step S3.

[0044] 2. If the HOTP calculation results of the cloud and the device side are different, calculate the HOTP password according to the cloud key and the value of the counter -2 + 1 (i.e., N - 1), and compare it with the password sent by the device side. If the two are the same, update N to N–2 and jump to step S3; if the two are still different, it is considered that the keys of the device side and the cloud are different, and the authentication fails and is interrupted.

[0045] Step S3: Then save the value of the successfully verified counter +1 in step S2 in the cloud memory (the specific saved value is N + 2). The cloud recalculates the HOTP password according to the value of N + 2 and returns the new HOTP password to the device side.

[0046] Step S4: The device side receives the HOTP password returned by the cloud, recalculates the HOTP password according to the device-side counter M + 1 and the key, and compares it with the HOTP password sent by the cloud; if the two are different, the verification fails; if the two are the same, it means that the HOTP verification request of the device side this time passes. The value of the counter on the device side increases by 2 and is saved. At this time, the counter value on the device side is M + 2 until the next HOTP verification request.

[0047] After a successful HOTP authentication request between the cloud and the device, the value of the device counter is updated to M + 2, and the value of the cloud counter is updated to N + 2. That is, the values of the device counter and the cloud counter are kept in sync, and the device counter only increments after a successful HOTP authentication request, avoiding the problem that in traditional HOTP authentication, the value of the device counter is much larger than that of the cloud due to failed authentication, which leads to the inapplicability of HOTP authentication to this scenario.

[0048] In the fallback retry mechanism for cloud HOTP authentication in the present invention, one two-way authentication includes two verifications between the device and the cloud. If the second verification fails because it has not reached due to network or other unpredictable reasons, for the next verification request of the device, the cloud will roll back the value of the counter and re-verify the HOTP password, avoiding verification failure caused by the separate increment of the cloud counter.

[0049] Specifically, HOTP in the present invention is a one-time password based on the HMAC algorithm.

[0050] The main inputs of the HOTP algorithm include two elements. One is the shared key, and the other is the counter, which are respectively called K and C hereinafter. The number of digits of the password finally generated by the HOTP algorithm is called Digit, and the minimum number of digits of Digit cannot be less than 6.

[0051] K: This key is required to be unique for each HOTP generator, and only the server side and the device side know it, and it is generally bound to the device.

[0052] C: An 8-byte value, which needs to be kept in sync between the server and the client.

[0053] The main process of the HOTP algorithm is as Figure 2 shown.

[0054] The first step: Use the HMAC-SHA-1 algorithm to generate a 20-byte hexadecimal string HS based on K and C, that is, HS = HMAC-SHA-1(K, C).

[0055] The second step: Take the lower 4 bits of the last byte of these 20 bytes of HS and convert them to decimal, and use this value as the offset Offset. As Figure 2 shown, the last byte is 3a, the lower four bits are a, and hexadecimal 0xa is converted to decimal 10, that is, the value of the offset Offset is 10.

[0056] The third step: According to the offset Offset, take 4 bytes starting from the Offset-th byte in HS as the main data for generating HOTP, called Sbits. For Figure 2In the example, 4 bytes of data are taken from the 10th byte as Sbits, and the value of Sbits is "0x512a5a21".

[0057] Step 4: Convert the value of Sbits to decimal, and then use the decimal number to perform a modulo operation on the power of 10 to obtain a final digit HOTP password. Figure 2 In the example, "0x512a5a21" is converted to decimal as "1361730081", and the modulo operation of 10 to the power of 6 is performed, and the final result is "730081". "730081" is the final generated HOTP password.

[0058] This invention is typically implemented using a network-enabled hardware terminal and a cloud-based authentication service. Even when the hardware lacks network connectivity, the HOTP password generated by the hardware terminal can be manually entered into the hardware terminal for secondary authentication, further expanding the scope of HOTP authentication. Furthermore, since both the device-side counter and the cloud-based counter increment only after verifying each other's HOTP password, synchronization issues caused by network or other unpredictable factors can be avoided.

[0059] The present invention also provides a bidirectional HOTP authentication system. The bidirectional HOTP authentication system can be implemented by executing the process steps of the bidirectional HOTP authentication method. That is, those skilled in the art can understand the bidirectional HOTP authentication method as a preferred embodiment of the bidirectional HOTP authentication system. The system specifically includes the following:

[0060] Module M1: When the client device requests HOTP authentication, it reads the key and counter from the device memory, calculates the HOTP password, and sends it to the cloud. Initially, the cloud counter N is 0 and the device counter M is 1.

[0061] Module M2: The cloud receives the HOTP password from the device and reads the cloud counter from the cloud storage to N. The cloud calculates the HOTP password based on the cloud-stored key and the cloud counter + 1 (i.e., N + 1), and compares it with the password sent by the device.

[0062] 1. If the HOTP calculation results on the cloud and the device are consistent, jump to module M3.

[0063] 2. If the HOTP calculation results of the cloud and the device side are inconsistent, calculate the HOTP password based on the cloud key and the value of the counter -2 + 1 (i.e., N - 1), and compare it with the password sent by the device side. If the two are consistent, update N to N – 2 and jump to module M3; if the two are still inconsistent, it is considered that the keys of the device side and the cloud are different, and the authentication fails and is interrupted.

[0064] Module M3: Add 1 to the value of the successfully verified counter in module M2 and save it in the memory of the cloud (the specific value saved is N + 2). The cloud recalculates the HOTP password based on the value of N + 2 and returns the new HOTP password to the device side.

[0065] Module M4: The device side receives the HOTP password returned by the cloud, recalculates the HOTP password based on the device side counter M + 1 and the key, and compares it with the HOTP password sent by the cloud; if the two are inconsistent, the verification fails; if the two are consistent, it means that the HOTP verification request of the device side this time passes. The value of the counter on the device side is incremented by 2 and saved. At this time, the counter value on the device side is M + 2 until the next HOTP verification request.

[0066] After a successful HOTP verification request between the cloud and the device side, the value of the device side counter is updated to M + 2, and the value of the cloud counter is updated to N + 2, that is, the values of the device side and cloud counters are synchronized, and the device side counter only increments after a successful HOTP verification request, avoiding the problem that the traditional HOTP authentication cannot adapt to this scenario due to the value of the device side counter being much larger than that of the cloud when the verification fails.

[0067] The embodiment of the present invention provides a two-way HOTP authentication method, system, device and medium, which is mainly completed by the synchronization mechanism between the cloud and the device side. At the beginning, the cloud and the device side need to negotiate a common key KEY. The key can be generated by the cloud and sent to the device side, or directly imported on the device side. Therefore, only specific devices holding the key can generate valid HOTP passwords. Before the client device and the cloud perform identity verification, the cloud initializes the value of the counter to N, and the device side initializes the value of the counter to M (M = N + 1). An authentication request from the device side will generate a HOTP password and send it to the cloud for verification. At the same time, the cloud will also generate a HOTP password for the device side to verify after the verification passes. Both the cloud and the device side will only modify the value of the counter after successfully verifying the HOTP password of the other party, avoiding the situation where the counter keeps accumulating due to verification failure.

[0068] Those skilled in the art know that in addition to implementing the system and its various devices, modules, and units provided by the present invention in the form of pure computer-readable program code, the method steps can be logically programmed to enable the system and its various devices, modules, and units provided by the present invention to be implemented in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc. to achieve the same functions. Therefore, the system and its various devices, modules, and units provided by the present invention can be considered as a kind of hardware component, and the devices, modules, and units included therein for implementing various functions can also be regarded as the structures within the hardware component; the devices, modules, and units for implementing various functions can also be regarded as either software modules for implementing the method or structures within the hardware component.

[0069] The specific embodiments of the present invention have been described above. It should be understood that the present invention is not limited to the above specific embodiments, and those skilled in the art can make various changes or modifications within the scope of the claims, which do not affect the essence of the present invention. Without conflict, the embodiments of the present application and the features in the embodiments can be combined with each other arbitrarily.

Claims

1. A two-way HOTP authentication method, characterized in that, Including: Step S1: When the client device requests HOTP authentication, read the key and counter from the device memory, calculate the HOTP password, and send it to the cloud. Step S2: The cloud receives the HOTP password sent by the device end and reads the cloud counter as N from the cloud memory. The cloud calculates the HOTP password based on the key saved in the cloud and the value of the cloud counter N+1, and compares it with the password sent by the device end for verification; if the HOTP calculation results of the cloud and the device end are the same, jump to Step S3. If the HOTP calculation results of the cloud and the device end are different, calculate the HOTP password based on the cloud key and the value of the counter N-1, and compare it with the password sent by the device end. If the two are the same, update N to N–2 and jump to Step S3; if the two are still different, it is considered that the keys of the device end and the cloud are different, and the authentication fails and is interrupted. Step S3: After adding 1 to the value of the successfully verified counter in Step S2, save it in the cloud memory, and the specific saved value is N+2; the cloud recalculates the HOTP password based on the value of N+2 and returns the new HOTP password to the device end. Step S4: The device end receives the HOTP password returned by the cloud, recalculates the HOTP password based on the device end counter M+1 and the key, and compares it with the HOTP password sent by the cloud. If the two are different, the verification fails; if the two are the same, it means that the HOTP authentication request of the device end this time passes, the value of the counter on the device end increases by 2 and is saved, and the value of the counter on the device end at this time is M+2 until the next HOTP authentication request.

2. The two-way HOTP authentication method according to claim 1, characterized in that The situation where the HOTP calculation results of the cloud and the device end are different includes the fallback retry mechanism for cloud HOTP verification. If the verification of the cloud HOTP password fails due to network or other unpredictable reasons and the authentication fails, for the next verification request of the device, the cloud will fallback the value of the counter and re-verify the HOTP password.

3. A two-way HOTP authentication system, characterized in that, Including: Module M1: When the client device requests HOTP authentication, read the key and counter from the device memory, calculate the HOTP password, and send it to the cloud. Module M2: The cloud receives the HOTP password sent by the device end and reads the cloud counter as N from the cloud memory. The cloud calculates the HOTP password based on the key saved in the cloud and the value of the cloud counter N+1, and compares it with the password sent by the device end for verification; if the HOTP calculation results of the cloud and the device end are the same, jump to Module M3. If the HOTP calculation results of the cloud and the device end are different, calculate the HOTP password based on the cloud key and the value of the counter N-1, and compare it with the password sent by the device end. If the two are the same, update N to N–2 and jump to Module M3; if the two are still different, it is considered that the keys of the device end and the cloud are different, and the authentication fails and is interrupted. Module M3: After adding 1 to the value of the successfully verified counter in Module M2, save it in the cloud memory, and the specific saved value is N+2; the cloud recalculates the HOTP password based on the value of N+2 and returns the new HOTP password to the device end. Module M4: The device receives the HOTP password returned by the cloud, recalculates the HOTP password based on the device counter M+1 and the key, and compares it with the HOTP password sent by the cloud; If the two do not match, the verification fails; if they match, it means that the HOTP verification request of the device this time passes, the value of the counter on the device is incremented by 2 and saved. At this time, the value of the counter on the device is M+2 until the next HOTP verification request.

4. The two-way HOTP authentication system according to claim 3, wherein If the HOTP calculation results of the cloud and the device do not match, including the fallback retry mechanism for HOTP verification in the cloud. If the verification fails because the HOTP password of the cloud has not arrived due to network or other unpredictable reasons, for the next verification request of the device, the cloud will fallback the value of the counter and re-verify the HOTP password.

5. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the two-way HOTP authentication method described in any one of claims 1 to 2.

6. An electronic device, comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein, When the computer program is executed by a processor, it implements the steps of the two-way HOTP authentication method described in any one of claims 1 to 2.

Images