Password authentication method and device, electronic equipment and storage medium

Abstract

The invention discloses a password authentication method and device, electronic equipment and a storage medium. The method comprises the following steps: determining a first hash value, and generating a second hash value according to the first hash value and first information; comparing the second hash value with the third hash value to obtain a first result; and generating a first session token according to the first result, and performing service processing according to the first session token. According to the method, the second hash value is generated according to the first hash value and the first information, the first session token is generated according to the comparison result of the second hash value and the third hash value, and service processing is carried out, so that an authentication mechanism with high security, high performance and easy deployment is realized.

Description

Technical Field

[0001] This invention relates to the field of cryptography, and in particular to a cryptographic authentication method, apparatus, electronic device, and storage medium. Background Technology

[0002] The Hadoop Distributed File System (HDFS) Remote Procedure Call (RPC) framework natively supports two authentication mechanisms: SIMPLE and KERBEROS. SIMPLE authentication relies solely on username declarations, lacking password verification. This makes it vulnerable to forgery attacks and unauthorized access, resulting in extremely low security, and it's only suitable for testing environments. KERBEROS authentication achieves strong authentication through a Key Distribution Center (KDC), but its deployment is complex, requiring KDC and key table configuration, leading to high maintenance costs. Furthermore, ticket verification increases RPC latency, impacting performance in high-concurrency scenarios. Summary of the Invention

[0003] This invention provides a cryptographic authentication method, apparatus, electronic device, and storage medium to solve the problems of low security and complex authentication in distributed file systems.

[0004] According to one aspect of the present invention, a cryptographic authentication method is provided, comprising:

[0005] A first hash value is determined, and a second hash value is generated based on the first hash value and the first information; the first hash value is a string generated by the client based on the password information and the first string; the first string is a string of first preset bytes generated according to preset requirements; the first information is the encoded first string and the password information;

[0006] The second hash value is compared with the third hash value to obtain a first result; the third hash value is a string generated based on the password information and the first string; the third hash value is generated in a different way than the first hash value.

[0007] A first session token is generated based on the first result, and business processing is performed based on the first session token.

[0008] According to another aspect of the present invention, a cryptographic authentication device is provided, comprising:

[0009] The second hash value determination module is used to determine the first hash value and generate the second hash value based on the first hash value and the first information; the first hash value is a string generated by the client based on the password information and the first string; the first string is a string of the first preset bytes generated according to preset requirements; the first information is the encoded first string and the password information;

[0010] The first result determination module is used to compare the second hash value with the third hash value to obtain a first result; the third hash value is a string generated based on the password information and the first string; the third hash value is generated in a different way than the first hash value.

[0011] The business processing module is used to generate a first session token based on the first result and to perform business processing based on the first session token.

[0012] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:

[0013] At least one processor; and

[0014] A memory communicatively connected to the at least one processor; wherein,

[0015] The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the cryptographic authentication method according to any embodiment of the present invention.

[0016] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the cryptographic authentication method of any embodiment of the present invention.

[0017] The technical solution of this invention involves determining a first hash value and generating a second hash value based on the first hash value and first information. The first hash value is a string generated by the client based on password information and a first string. The first string is a string of first preset bytes generated according to preset requirements. The first information consists of the encoded first string and password information. Determining the first hash value ensures that plaintext is not transmitted, guaranteeing the security of plaintext passwords. The determination of the second hash value, combined with the first information, utilizes pre-hashing and static salt values ​​for multi-round Argon2 verification, preventing brute-force attacks and replay attacks. The second hash value is compared with a third hash value to obtain a first result. A first session token is generated based on the first result, and business processing is performed based on the first session token. After successful verification, a short-lifespan first session token is issued, and business processing is performed based on the first session token, reducing the resource consumption of re-authentication. This method generates a second hash value based on the first hash value and first information, generates a first session token based on the comparison result of the second hash value and the third hash value, and performs business processing, achieving a highly secure, high-performance, and easily deployable authentication mechanism.

[0018] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 A flowchart of a cryptographic authentication method provided in an embodiment of the present invention;

[0021] Figure 2 A flowchart of a third hash value generation method provided in an embodiment of the present invention;

[0022] Figure 3 A diagram illustrating the process of establishing a connection between a client and a server, provided in an embodiment of the present invention;

[0023] Figure 4 A flowchart of a first session token verification process provided in an embodiment of the present invention;

[0024] Figure 5 This is a schematic diagram of the structure of a cryptographic authentication device provided in an embodiment of the present invention;

[0025] Figure 6 A schematic diagram of the structure of an electronic device for implementing the cryptographic authentication method of this invention. Detailed Implementation

[0026] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0027] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0028] Figure 1 This is a flowchart illustrating a password authentication method provided in an embodiment of the present invention. This embodiment is applicable to situations involving the removal of offline IoT devices. The method can be executed by a password authentication device, which can be implemented in hardware and / or software. This password authentication device can be configured in any electronic device with network communication capabilities. Figure 1 As shown, the method includes:

[0029] S110. Determine the first hash value, and generate a second hash value based on the first hash value and the first information; the first hash value is a string generated by the client based on the password information and the first string; the first string is a string of the first preset bytes generated according to preset requirements; the first information is the encoded first string and the password information.

[0030] The first preset byte is 64 bytes.

[0031] The first string, denoted as `static_salt`, is a 64-byte random static salt value generated using SecureRandom. SecureRandom is the core tool for generating random password numbers; unlike ordinary random number generators, its random numbers are unpredictable and irregular.

[0032] Specifically, the client sends an authentication RPC request to the server, carrying {client name, first hash value}. Upon receiving the RPC request, the server retrieves the client name and the first hash value. Based on the client name, the server retrieves the first information from the H2 database, decodes it to obtain the first string, and then generates a second hash value based on the first string, the third string, and the first hash value.

[0033] Furthermore, the second hash value can be represented as: Second hash value (computedHash) = Argon2id(preHash + static_salt + dynamic_salt). Where the first string is static_salt; dynamic_salt is the third string; and preHash is the first hash value.

[0034] Furthermore, the third string consists of timestamp information and the second string, which can be represented as: dynamic_salt = current millisecond timestamp + second string. Here, the second string is a randomly generated second preset byte.

[0035] Furthermore, the first hash value is generated by the client. The method for determining the first hash value is as follows: the client obtains the client name from the operating system, obtains the password information and the first string from the client configuration file hdfs-site.xml, and uses the SHA-256 algorithm to generate the first hash value based on the password information and the first string.

[0036] Furthermore, the first hash value preHash = SHA256(plainPassword + static_salt).

[0037] Furthermore, after generating the first hash value, the client destroys the password information from memory.

[0038] S120. Compare the second hash value with the third hash value to obtain the first result; the third hash value is a string generated based on the password information and the first string; the third hash value and the first hash value are generated in different ways.

[0039] Specifically, the second hash value is compared with the third hash value. If they are the same, the first result is a successful verification. If they are different, the verification fails, the failure count is incremented, a new second hash value is generated, and the newly generated hash value is compared with the third hash value. If they are the same, the first result is a successful verification; otherwise, the verification fails, and the failure count is incremented. When the number of failures exceeds a preset limit, the first result is a failed verification, and the client is locked for a preset time.

[0040] Furthermore, the process of generating the third hash value, such as Figure 2As shown, the server first generates the client name (username) and password information (password_hash). The server then uses SecureRandom to generate a 64-byte random static salt value, i.e., the first string `static_salt`. Argon2id is used to calculate the third hash value. After obtaining the third hash value, the server writes the username, password_hash, and static_salt into the embedded H2 database and immediately destroys the password information in memory. The Base64 encoded static_salt and password information are then sent to the client and saved in the client's configuration file `hdfs-site.xml`.

[0041] The third hash value, password_hash, is set to Argon2id (iterations = 3, memory = 128MiB, parallelism = 1, input = plainPassword + static_salt).

[0042] Furthermore, such as Figure 3 As shown, the process for determining the first result is as follows: First, the client obtains the client name from the operating system. Based on the obtained client name, it retrieves the password information and the first string from the configuration file. Then, it calculates the first hash value based on the obtained password information and the first string. When processing business logic, the client includes the first hash value in the connection request and sends it to the server. After receiving the first hash value, the server matches the password information and the first string from the H2 database based on the client name. It then generates a second hash value based on the obtained password information, the first string, and the first hash value. The second hash value is compared with the third hash value. If they match, the verification passes, a first session token is generated, and a connection between the client and the server is established. If they do not match, the failure count is incremented by 1, a new second hash value is generated, and compared with the third hash value. If the comparison results are the same, a first session token is generated, and a connection between the client and the server is established. If they do not match, the failure count is incremented again. If the failure count exceeds 3 times, the verification fails, the connection is rejected, and the client is locked for 30 minutes.

[0043] Furthermore, Figure 3 The process also includes an authentication RPC handling flow: socket establishment and authentication. The socket connection establishment follows the TCP protocol's "three-way handshake" and consists of two main stages: client initiation and server listening or response. This is a prerequisite for all upper-layer authentication and RPC processing. Authentication then directs the request to the authentication module to authenticate the RPC request.

[0044] S130. Generate a first session token based on the first result, and perform business processing based on the first session token.

[0045] Specifically, if the first result is successful verification, a first session token is generated; if the first result is unsuccessful verification, the response is rejected. The server scans client request information in real time. When a request is detected, the server retrieves the request information and the first session token from it. First, the format of the first session token is verified. If the format meets the requirements, the signature of the first session token is verified using a key. If the verification passes, the first time is retrieved from the second part of the first session token, and a second result is generated based on the verification result. If the second result is successful verification and the first time is within the valid time period, the third result is that the first session token is valid; if the second result is unsuccessful verification and the first time is not within the valid time period, the third result is that the first session token is invalid. If the third result is that the first session token is valid, a second session token is generated and returned to the client. Upon receiving the second session token, the client replaces the first session token. If the third result is that the first session token is invalid, it indicates that the first session token has expired or has an incorrect signature. The server then rejects the client's login or business services and forces the client to re-verify and log in.

[0046] For example, such as Figure 4 The diagram illustrates the steps for business processing based on the first session token: The client initiates a business RPC and checks the first session token. If the first session token has less than 1 minute of remaining validity, it proactively initiates a refresh request, carrying the first session token. The server-side Namenode receives the refresh request, parses the first session token, and verifies the HS512 signature. If the first session token has not expired and the signature is correct, it uses the HS512 algorithm to generate a second session token, valid for 5 minutes. The second session token is returned to the client, which replaces the first session token. If the first session token has expired or the signature is incorrect, a denial-of-service response is returned, forcing the client to log in again.

[0047] Optionally, a second hash value is generated based on the first hash value and the first information, including steps A1-A2:

[0048] Step A1: Generate a third string based on the timestamp information and the second string; the second string is a random number of the second preset bytes.

[0049] The second preset byte is 32 bytes.

[0050] The timestamp information is the current time in milliseconds.

[0051] Specifically, a second preset byte of random number is generated, and the current time information is obtained as a timestamp. The timestamp information is then combined with the second string to generate the third string.

[0052] The third string can be represented as: dynamic_salt = current millisecond timestamp + second string.

[0053] Step A2: Generate a second hash value based on the third string, the first hash value, and the first information.

[0054] Specifically, the first information is decoded to obtain the first string. The third string, the first hash value, and the first string are concatenated and calculated using a preset hash calculation method to obtain the second hash value.

[0055] The preset hash calculation method can be Argon2id. Argon2id is suitable for scenarios such as password information storage and sensitive information hashing.

[0056] Furthermore, the second hash value can be represented as: Second hash value (computedHash) = Argon2id(preHash + static_salt + dynamic_salt). Where the first string is static_salt; dynamic_salt is the third string; and preHash is the first hash value.

[0057] Optionally, the second hash value is compared with the third hash value to obtain the first result, including steps B1-B3:

[0058] Step B1: If the second hash value is the same as the third hash value, then the first result is that the verification is successful.

[0059] Specifically, the second hash value is compared with the third hash value. If the second hash value is the same as the third hash value, the first result is that the verification is successful, indicating that the client has completed the registration and is qualified to access business data.

[0060] Step B2: If the second hash value is different from the third hash value, then the failure count is incremented by one.

[0061] Specifically, if the second hash value is different from the third hash value, the verification fails, the failure count is incremented by 1, the second hash value is regenerated, and the newly generated second hash value is compared with the third hash value. If they are the same, the first result is that the verification passes; if they are different, the verification fails, and the failure count is incremented by 1.

[0062] Step B3: If the number of failures exceeds the preset number of failures, the first result is verification failure, and the client is locked.

[0063] Specifically, if the number of failed attempts exceeds the preset number of failures, the first result is verification failure, and the client is locked for a preset time.

[0064] The preset time is 30 minutes. The preset number of failures is 3.

[0065] Optionally, a first session token is generated based on the first result, including steps C1-C4:

[0066] Step C1: If the first result is successful verification, then define the first part and the second part; the first part is used to declare the algorithm and type for generating the first session token; the second part is used to declare the validity period of the first session token.

[0067] The first part, denoted as Header, is used to declare the algorithm and the type of the first session token. It has a fixed JSON structure: {"alg": "...", "typ": "..."}.

[0068] The second part, denoted as Payload, stores information including: token expiration time (exp); token issuance time (iat); and first identifier (sub). The first identifier uniquely identifies the client.

[0069] Specifically, if the first result is successful verification, it indicates that the currently logged-in client has completed registration and is qualified to call business data. Then, define the first part and declare the key algorithm type and the type of the first session token in it; define the second part, which contains the token information of the first session token, namely the token expiration time, the token issuance time and the client identifier.

[0070] Step C2: Encode the first and second parts and concatenate them to obtain the fourth string.

[0071] Specifically, the first and second parts are encoded separately, and then concatenated with "." to obtain the fourth string.

[0072] Furthermore, the fourth string can be represented as: data=Base64URL(Header).Base64URL(Payload).

[0073] The encoding uses Base64URL. Base64URL is a lightweight modified version of Base64, which replaces special characters and removes padding characters to make it fully compatible with the transmission rules of URL / URI, cookies, HTTP headers, and other scenarios. Furthermore, it is the standard encoding method for the first session token.

[0074] Step C3: Generate a binary signature based on the preset key and the fourth string, and define it as the third part.

[0075] The preset key is a key generated and held by the server.

[0076] Specifically, an HMAC-SHA512 hash calculation is performed on the fourth string, i.e., the preset key, to obtain a binary signature. This signature is then used as the third part of the first session token.

[0077] Furthermore, the binary signature can be represented as: HMAC-SHA512(Base64URL(Header)+"."+Base64URL(Payload), key).

[0078] Step C4: Encode the third part and concatenate it with the fourth string to obtain the first session token.

[0079] Specifically, the third part is encoded using the same encoding method as the first part, and then concatenated with the fourth string to obtain the first session token.

[0080] Optionally, business processing is performed based on the first session token, including steps D1-D4:

[0081] Step D1: Determine the request information and obtain the first session token based on the request information.

[0082] Specifically, the server scans the client's request information in real time. When a request is detected, the server retrieves the request information and obtains the first session token from it.

[0083] Furthermore, the request information is generated by the client's HDFS during each business RPC. The specific steps are as follows: Before each business RPC, the client's HDFS first checks the first session token stored locally. If the remaining validity period of the first session token is less than a preset validity period, it proactively initiates a refresh request, generates request information, and includes the first session token in the request information. If the remaining validity period of the first session token is greater than or equal to the preset validity period, the business RPC is performed directly.

[0084] The preset effective time can be set to 1 minute.

[0085] Among them, business RPC allows clients to retrieve business-related data from the server.

[0086] Step D2: Parse the first session token to obtain the first time and the second result; the first time is the validity period of the first session token.

[0087] Specifically, the format of the first session token is first verified. If the format meets the requirements, the signature of the first session token is verified using the key. If the verification is successful, the first time is obtained from the second part of the first session token, and the second result is generated based on the verification result.

[0088] Furthermore, the format meets the requirements as follows: the first session token consists of three parts. That is, whether the first session token contains a Header, a Payload, and a Signature. These three parts correspond to the first, second, and third parts of the first session token, respectively.

[0089] Further, the specific steps for verifying the signature of the first session token using the key are as follows: The first session token is split into three encoded parts: a first part, a second part, and a third part. The first part is decoded to obtain the algorithm and type of the first session token. It is determined whether the algorithm of the first session token is the same as the preset algorithm. If they are the same, the first and second encoded parts are concatenated. The concatenated characters and the server's current key are hashed using HMAC-SHA512 to obtain the verification binary signature. The obtained binary signature is encoded and compared with the encoded third part. If they match, the verification passes, and the second part is parsed. If they do not match, the server switches to a historical key for verification until all historical keys have been verified. If a historical key verification passes, the second part is parsed; if no historical key verification passes, the verification fails, and a verification failure warning is issued.

[0090] The default algorithm is HS512. The HS512 algorithm is a symmetric signature algorithm that combines HMAC with the SHA-512 hash algorithm. It is a mainstream, highly secure algorithm for session token signing and is primarily suitable for scenarios where the server independently issues / verifies tokens.

[0091] Step D3: Determine the third result based on the second result and the first time.

[0092] Specifically, if the second result is that the verification is successful and the first time is within the valid time period, then the third result is that the first session token is valid; if the second result is that the verification is unsuccessful and the first time is not within the valid time period, then the third result is that the first session token is invalid.

[0093] Step D4: Log in based on the third result.

[0094] Specifically, if the third result indicates that the first session token is valid, a second session token is generated and returned to the client. Upon receiving the second session token, the client replaces the first session token. If the third result indicates that the first session token is invalid, it means that the first session token has expired or has an incorrect signature. In this case, the client's login service or business service is rejected, and the client is forced to re-authenticate and log in.

[0095] Optionally, login can be performed based on the third result, including steps E1-E2:

[0096] Step E1: If the third result indicates that the first session token is valid, then generate the second session token and transmit the obtained second session token to the client.

[0097] Specifically, if the third result indicates that the first session token is valid, a second session token is generated and returned to the client. Upon receiving the second session token, the client replaces the first session token.

[0098] Furthermore, the generation method of the second session token is similar to that of the first session token, and will not be repeated here.

[0099] Step E2: If the third result indicates that the first session token is invalid, then the client's login is rejected.

[0100] Specifically, if the third result indicates that the first session token is invalid, it means that the first session token has expired or the signature is incorrect. Therefore, the client's login service or business service will be rejected, and the client will be forced to re-verify and log in.

[0101] The technical solution of this embodiment determines a first hash value, and generates a second hash value based on the first hash value and first information. The first hash value is a string generated by the client based on password information and a first string. The first string is a string of first preset bytes generated according to preset requirements. The first information is the encoded first string and password information. Determining the first hash value ensures that plaintext is not transmitted, guaranteeing the security of plaintext passwords. The determination of the second hash value, combined with the first information, uses multi-round Argon2 verification based on pre-hashing and static salt values ​​to prevent brute-force attacks and replay attacks. The second hash value is compared with a third hash value to obtain a first result. A first session token is generated based on the first result, and business processing is performed based on the first session token. After successful verification, a short-lifetime first session token is issued, and business processing is performed based on the first session token, reducing the resource consumption of re-authentication. This method generates a second hash value based on the first hash value and first information, generates a first session token based on the comparison result of the second hash value and the third hash value, and performs business processing, achieving a highly secure, high-performance, and easily deployable authentication mechanism.

[0102] Figure 5 This is a schematic diagram of a password authentication device provided in an embodiment of the present invention. This embodiment is applicable to situations involving the removal of offline IoT devices. The password authentication device can be implemented in hardware and / or software, and can be configured in any electronic device with network communication capabilities. Figure 5 As shown, the device includes: a second hash value determination module 210, a first result determination module 220, and a business processing module 230, wherein:

[0103] Second hash value determination module 210: used to determine the first hash value and generate the second hash value based on the first hash value and the first information; the first hash value is a string generated by the client based on the password information and the first string; the first string is a string of the first preset bytes generated according to preset requirements; the first information is the encoded first string and the password information;

[0104] First result determination module 220: used to compare the second hash value with the third hash value to obtain the first result; the third hash value is a string generated based on the password information and the first string; the third hash value and the first hash value are generated in different ways;

[0105] Business processing module 230: Used to generate a first session token based on the first result, and to perform business processing based on the first session token.

[0106] Optionally, the second hash value determination module 210 includes:

[0107] The third string generation unit is used to generate a third string based on the timestamp information and the second string; the second string is a random number of the second preset bytes;

[0108] The third hash value generation unit is used to generate a second hash value based on the third string, the first hash value, and the first information.

[0109] Optionally, the first result determination module 220 includes:

[0110] If the second hash value is the same as the third hash value, then the first result is that the verification is successful;

[0111] If the second hash value is different from the third hash value, the failure count is incremented by one;

[0112] If the number of failures exceeds the preset number of failures, the first result will be verification failure, and the client will be locked.

[0113] Optional, business processing modules include:

[0114] Definition Unit: Used to define the first part and the second part if the first result is successful verification; the first part is used to declare the algorithm and type for generating the first session token; the second part is used to declare the validity period of the first session token;

[0115] The fourth string determination unit is used to encode the first and second parts and concatenate them to obtain the fourth string.

[0116] Binary signature determination unit: used to generate a binary signature based on a preset key and a fourth string, and defined as the third part;

[0117] First Session Token Determination Unit: Used to encode the third part and concatenate it with the fourth string to obtain the first session token.

[0118] Optional, business processing modules include:

[0119] The first session token acquisition unit is used to determine the request information and acquire the first session token based on the request information.

[0120] The first time determination unit is used to parse the first session token to obtain the first time and the second result; the first time is the validity period of the first session token;

[0121] The second result determination unit is used to determine the third result based on the second result and the first time.

[0122] The login unit is used to log in based on a third result.

[0123] Optional, login units include:

[0124] Second Session Token Generation Subunit: If the third result indicates that the first session token is valid, then generate the second session token and transmit the obtained second session token to the client;

[0125] The "Reject Login" subunit is used to reject the client's login if the third result indicates that the first session token is invalid.

[0126] The cryptographic authentication device provided in the embodiments of the present invention can execute the cryptographic authentication method provided in any of the embodiments of the present invention, and has the corresponding functions and beneficial effects of executing the cryptographic authentication method. For details, please refer to the relevant operations of the cryptographic authentication method in the foregoing embodiments.

[0127] Figure 6 This is a schematic diagram of the structure of an electronic device for implementing the cryptographic authentication method of an embodiment of the present invention. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (such as helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0128] like Figure 6As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded into the RAM 13 from storage unit 18. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

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

[0130] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as cryptographic authentication methods.

[0131] In some embodiments, the cryptographic authentication method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the cryptographic authentication method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the cryptographic authentication method by any other suitable means (e.g., by means of firmware).

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

[0133] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0134] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

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

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

[0137] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0138] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

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

Claims

1. A cryptographic authentication method, characterized in that, include: Determine a first hash value, and generate a second hash value based on the first hash value and the first information; The first hash value is a string generated by the client based on the password information and the first string; The first string is a string of the first preset bytes generated according to preset requirements; the first information is the encoded first string and password information; The second hash value is compared with the third hash value to obtain the first result; The third hash value is a string generated based on the password information and the first string; The third hash value is generated in a different way than the first hash value; A first session token is generated based on the first result, and business processing is performed based on the first session token.

2. The method according to claim 1, characterized in that, The step of generating a second hash value based on the first hash value and the first information includes: A third string is generated based on the timestamp information and the second string; the second string is a random number of the second preset bytes; A second hash value is generated based on the third string, the first hash value, and the first information.

3. The method according to claim 1, characterized in that, The step of comparing the second hash value with the third hash value to obtain a first result includes: If the second hash value is the same as the third hash value, then the first result is that the verification is successful; If the second hash value is different from the third hash value, the failure count is incremented by one; If the number of failures exceeds the preset number of failures, the first result is verification failure, and the client is locked.

4. The method according to claim 1, characterized in that, The step of generating the first session token based on the first result includes: If the first result is successful verification, then define the first part and the second part; the first part is used to declare the algorithm and type for generating the first session token; the second part is used to declare the validity period of the first session token; The first and second parts are encoded and then concatenated to obtain the fourth string; A binary signature is generated based on the preset key and the fourth string, and defined as the third part; The third part is encoded and then concatenated with the fourth string to obtain the first session token.

5. The method according to claim 1, characterized in that, The process of performing business processing based on the first session token includes: Determine the request information and obtain the first session token based on the request information; The first session token is parsed to obtain a first time and a second result; the first time is the validity period of the first session token. The third result is determined based on the second result and the first time. Log in based on the third result.

6. The method according to claim 5, characterized in that, The login process based on the third result includes: If the third result indicates that the first session token is valid, then a second session token is generated and transmitted to the client. If the third result indicates that the first session token is invalid, then the client's login is rejected.

7. A business processing device, characterized in that, include: The second hash value determination module is used to determine the first hash value and generate the second hash value based on the first hash value and the first information. The first hash value is a string generated by the client based on the password information and the first string; The first string is a string of the first preset bytes generated according to preset requirements; the first information is the encoded first string and password information; The first result determination module is used to compare the second hash value with the third hash value to obtain the first result; The third hash value is a string generated based on the password information and the first string; The third hash value is generated in a different way than the first hash value; The business processing module is used to generate a first session token based on the first result and to perform business processing based on the first session token.

8. The apparatus according to claim 7, characterized in that, The business processing module includes: The first session token acquisition unit is used to determine the request information and acquire the first session token according to the request information; The first time determination unit is used to parse the first session token to obtain a first time and a second result; the first time is the validity period of the first session token. The second result determination unit is used to determine a third result based on the second result and the first time. The login unit is used to log in based on the third result.

9. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the cryptographic authentication method according to any one of claims 1-6.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the cryptographic authentication method according to any one of claims 1-6.

Images