Login method and device, electronic equipment and storage medium

Abstract

The present disclosure provides a login method and device, electronic equipment and storage medium, belonging to the technical field of computers. The method comprises: receiving a first request from a client, the first request being used to perform an i-th step operation in a login process based on a first signature carried, i being an integer greater than 1; determining a second signature based on the name of the i-th step operation and a preset key from a cache space; verifying the first signature based on the second signature to obtain a verification result, the first signature being determined based on the name of the i-th step operation and the preset key when the server performs an i-1-th step operation; and in the case where the verification result indicates that the verification is passed, sending a result corresponding to the first request to the client. The signature establishes a relationship between adjacent steps in the login process, can identify cross-step attacks, avoid illegal login, and improve the security of the account.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a login method, apparatus, electronic device, and storage medium. Background Technology

[0002] With the rapid development of the internet, login based on encoded images (such as QR codes) has become a convenient cross-platform login method. Users scan the encoded image displayed on a webpage in the client application using their mobile devices, and after successful scanning, confirm the login on their mobile devices, thus quickly completing the login process without entering a username and password. However, this login process involves multiple requests between the client and the server. If the security mechanism is not robust, attackers may skip certain steps in the login process (such as scanning and confirmation) to complete unauthorized login, seriously affecting account security. Summary of the Invention

[0003] This disclosure provides a login method, apparatus, electronic device, and storage medium capable of identifying cross-step attacks, preventing unauthorized logins, and improving account security. The technical solution of this disclosure is as follows.

[0004] According to one aspect of the embodiments of this disclosure, a login method is provided, the method comprising: Receive a first request from the client, the first request being used to perform the i-th step of the login process based on the first signature carried, where i is an integer greater than 1; Based on the name of the i-th step operation and the preset key from the cache space, determine the second signature; Based on the second signature, the first signature is verified to obtain a verification result. The first signature is determined based on the name of the i-1th step operation and the preset key when the server performs the i-1th step operation. If the verification result indicates that the verification has passed, the result corresponding to the first request is sent to the client.

[0005] According to another aspect of the embodiments of this disclosure, a login device is provided, the device comprising: The receiving unit is configured to receive a first request from the client, the first request being used to perform the i-th step of the login process based on a first signature carried, where i is an integer greater than 1; The determining unit is configured to perform a second signature based on the name and a preset key from the cache space, according to the i-th step operation. The verification unit is configured to perform verification of the first signature based on the second signature to obtain a verification result. The first signature is determined based on the name of the i-th step operation and the preset key when the server performs the i-1 step operation. The sending unit is configured to send the result corresponding to the first request to the client if the verification result indicates that the verification has passed.

[0006] In some embodiments, the first request carries a token used to identify the session of the current login process; The verification unit is configured to perform the following: if the second signature is the same as the first signature, query the cache space for a completion marker based on the token and the name of the i-th step operation, wherein the completion marker indicates that the signature verification based on the name of the i-th step operation has been completed during the current login process; if the completion marker is found, output a first verification result, wherein the first verification result indicates that the verification failed; if the completion marker is not found, output a second verification result, wherein the second verification result indicates that the verification passed.

[0007] In some embodiments, the verification unit is further configured to perform the following: if the completion token is not found, generate the completion token based on the token and the name of the i-th step operation, and store the completion token in the cache space.

[0008] In some embodiments, the verification unit is configured to perform: if the second signature is different from the first signature, output a first verification result indicating that the verification failed; if the second signature is the same as the first signature, output a second verification result indicating that the verification passed.

[0009] In some embodiments, the apparatus further includes: The generation unit is configured to perform a third signature based on the name and the preset key of the operation in step i+1. The third signature is used by the client to generate a second request, and the second request is used to perform the operation in step i+1 of the login process based on the carried third signature.

[0010] In some embodiments, if the i-th step is a scanning operation, the sending unit is configured to perform: if the coded pattern in the client has been successfully scanned and the verification result indicates that the verification has passed, send the scanning result and the third signature to the client, wherein the scanning result indicates that the coded pattern has been successfully scanned.

[0011] In some embodiments, if the i-th step is a confirmation operation, the sending unit is configured to perform the following: if login has been confirmed and the verification result indicates that the verification has passed, send a confirmation result and login credentials to the client, wherein the confirmation result indicates that login has been confirmed.

[0012] In some embodiments, if the (i-1)th step is a generation operation, the apparatus further includes: The receiving unit is further configured to receive a third request from the client during the execution of the (i-1)th step, the third request being for requesting an encoded graphic; The generation unit is configured to generate the encoded graphic based on the third request; The generation unit is further configured to determine the first signature based on the name and the preset key of the i-th step operation; The sending unit is also configured to send the encoded graphic and the first signature to the client.

[0013] In some embodiments, the apparatus further includes: The generation unit is also configured to generate a token based on the third request, the token being used to identify the session of the current login process; The sending unit is also configured to send the token to the client.

[0014] In some embodiments, the determining unit is further configured to perform any of the following: determining the second signature based on the token carried in the first request, the name of the i-th step operation, and the preset key; determining the second signature based on the source information of the first request, the name of the i-th step operation, and the preset key; determining the second signature based on the token carried in the first request, the source information of the first request, the name of the i-th step operation, and the preset key; wherein the token is used to identify the session of the current login process, and the source information of the first request includes at least one of the source address and source device identifier of the second request.

[0015] According to another aspect of the embodiments of this disclosure, an electronic device is provided, the electronic device comprising: One or more processors; Memory used to store the executable program code of the processor; The processor is configured to execute the program code to implement the login method described above.

[0016] According to another aspect of the present disclosure, a computer-readable storage medium is provided that, when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, enables the electronic device to perform the above-described login method.

[0017] According to another aspect of the present disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the above-described login method.

[0018] This disclosure provides a login method that establishes relationships between adjacent steps in the login process through signatures. When performing step i-1, a first signature is generated based on the name of step i and a locally cached preset key, specifying the next step. When performing step i, a second signature is recalculated based on the name of this step and the preset key, and compared with the first signature in the request uploaded by the client, thereby verifying whether a cross-step request exists. If an attacker skips step i-1 and directly initiates a request targeting step i, they cannot obtain the compliant first signature generated during the execution of step i-1. Furthermore, since the preset key is stored only in a server-specific cache, the attacker cannot steal it. Therefore, even if the step name is known, a valid first signature cannot be forged. This ensures that a lack of a legitimate signature or a forged signature will result in failure to pass verification. In this way, cross-step attacks can be identified, unauthorized logins are avoided, and account security is improved.

[0019] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0020] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure, and are not intended to unduly limit this disclosure.

[0021] Figure 1 This is a schematic diagram illustrating the implementation environment of a login method according to an exemplary embodiment; Figure 2 This is a flowchart illustrating a login method according to an exemplary embodiment; Figure 3 This is a schematic diagram illustrating an overall system architecture according to an exemplary embodiment; Figure 4 This is a flowchart illustrating another login method according to an exemplary embodiment; Figure 5 This is a schematic diagram illustrating a signature generation process according to an exemplary embodiment; Figure 6 This is a schematic diagram illustrating a signature verification process according to an exemplary embodiment; Figure 7 This is a schematic diagram illustrating a multi-step signature flow according to an exemplary embodiment; Figure 8 This is a block diagram illustrating a login device according to an exemplary embodiment; Figure 9This is a block diagram illustrating an electronic device according to an exemplary embodiment. Detailed Implementation

[0022] To enable those skilled in the art to better understand the technical solutions of this disclosure, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings.

[0023] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure 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 this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0024] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.), and signals involved in this disclosure are all authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, the first request, the second request, and the preset key involved in this disclosure were obtained under full authorization.

[0025] For ease of understanding, the terms used in the embodiments of this disclosure are explained below.

[0026] HMAC (Hash-based Message Authentication Code) is a message authentication code generated through a special calculation method, using a cryptographic hash function (such as MD5, SHA-1, SHA-256) combined with an encryption key. For example, in this embodiment, the HMAC-MD5 algorithm is used to generate the signature, ensuring that the signature cannot be forged or tampered with. HMAC combines a key and a hash function, ensuring that only the party holding the key can generate and verify a valid signature.

[0027] MD5 (Message Digest Algorithm 5): A message digest algorithm, it is a widely used cryptographic hash function that produces a 128-bit (16-byte) hash value to ensure the integrity and consistency of transmitted information. In this embodiment, the algorithm is used for signature calculation rather than encryption, applying the avalanche effect of MD5 (i.e., a small change in input leads to a completely different output). Although MD5 has a collision problem, in HMAC scenarios, the collision problem does not affect security.

[0028] Deferred Result: This is an asynchronous response mechanism provided by the Spring framework, allowing the server to temporarily delay its response and wait for an asynchronous event to trigger before returning the result. In this embodiment, it is used to implement a long-connection waiting mechanism. After the client (specifically, the browser in the client) makes a request, the server maintains the connection and waits for the mobile device (specifically, the APP in the mobile device) to scan the code or confirm before returning the result via Redis PubSub notification.

[0029] Redis PubSub is a publish-subscribe messaging mechanism provided by Redis caching. Publishers send messages to channels, and subscribers receive messages in real time. In this embodiment, it is used to implement real-time push notifications to the web browser after the APP (application) scans a QR code, replacing the polling mechanism, improving response speed and reducing server load.

[0030] Token: This refers to a temporary credential, also known as a token, used to identify a single QR code login session. It contains information such as generation time, type, and unique ID. For example, a Base64 encoded token can be used as a session identifier, with an expiration time of 180 seconds, after which it automatically expires.

[0031] Salt: refers to a predefined fixed key (i.e., a preset key) used for HMAC calculation to enhance signature security. In this embodiment, the salt is privately stored on the server side. In a distributed architecture, all servers use the same salt to ensure consistent signature results. The client cannot obtain the salt and therefore cannot forge the signature.

[0032] Replay attack: An attacker intercepts and repeatedly sends network requests from legitimate users in an attempt to bypass authentication.

[0033] Figure 1 This is a schematic diagram illustrating an implementation environment for a login method according to an exemplary embodiment. See also... Figure 1The implementation environment specifically includes: server 101, first terminal 102, and second terminal 103. Server 101, first terminal 102, and second terminal 103 can be connected via wireless network or wired network, and this embodiment of the disclosure does not impose any limitations.

[0034] Both the first terminal 102 and the second terminal 103 can be at least one of the following devices: smartphone, smartwatch, desktop computer, laptop, and foldable computer. The first terminal 102 has a web-based client installed and running, which provides a webpage for account login. The second terminal 103 has an app installed, used to scan and confirm coded images on the webpage to log in to the account. Exemplarily, the types of business applications that the client and app can implement include, but are not limited to, short videos, audio / video, social media, shopping, and live streaming, etc., without further restriction.

[0035] The first terminal 102 and the second terminal 103 mentioned above can refer to one of a plurality of terminals. Those skilled in the art will understand that the number of terminals can be more or less. For example, there can be several terminals, or dozens or hundreds of terminals, or even more. This disclosure does not limit the number of terminals or the type of devices.

[0036] Server 101 can be at least one of a single server, multiple servers, a cloud computing platform, and a virtualization center. Optionally, the number of servers may be more or fewer, and this disclosure does not limit this. Of course, server 101 may also include other functional servers to provide more comprehensive and diversified services. In some embodiments, server 101 undertakes the main computing work, and each terminal undertakes secondary computing work; or, server 101 undertakes secondary computing work, and each terminal undertakes the main computing work; or, server 101 and each terminal use a distributed computing architecture for collaborative computing.

[0037] Currently, based on server 101, first terminal 102, and second terminal 103, quick cross-terminal QR code login can be achieved. In the login process, after opening the web login page on the first terminal 102, a request to generate an encoded graphic is sent to the server 101. The server 101 creates a unique session identifier (i.e., a token) and generates the corresponding encoded graphic, which is then sent to the first terminal 102 and displayed on its webpage. In the scanning step, the first terminal 102 sends a scan result request to the server 101. The user scans the encoded graphic using the APP on the second terminal 103. The second terminal 103 uploads the session identifier carried by the encoded graphic to the server 101. The server 101 identifies the session and returns a successful scan result to the first terminal 102. In the confirmation step, the first terminal 102 sends a confirmation result request to the server 101. The server pushes a login confirmation pop-up window to the second terminal 103. After the user completes the login authorization confirmation using the APP on the second terminal 103, the authorization command is sent back to the server 101. The server 101 returns a confirmed login result to the webpage on the first terminal 102. The first terminal 102 refreshes the page to complete the account login.

[0038] In simple terms, users scan the encoded image displayed on the webpage in the client of the first terminal 102 using the app on the second terminal 103. After a successful scan, they confirm the login on the second terminal 103, thus quickly completing the login process without needing to enter a username and password. However, this login process involves multiple requests between various terminals (especially the first terminal 102) and the server 101. If the security mechanism is inadequate, attackers may skip certain steps in the login process (such as scanning and confirmation) to complete an unauthorized login, seriously affecting account security.

[0039] Based on this, this disclosure proposes a login method that can identify cross-step attacks, prevent unauthorized logins, and improve account security. In the embodiments of this disclosure, there are still generation, scanning, and confirmation steps, but the specific implementation process of each step differs, which will be further described below.

[0040] The above implementation environment is merely an example. The method provided in this embodiment can also be executed in other implementation environments, and this embodiment does not limit this.

[0041] Figure 2 This is a flowchart illustrating a login method according to an exemplary embodiment, such as... Figure 2 As shown, this method is executed by the server and includes the following steps.

[0042] In step 201, the server receives a first request from the client, which is used to perform the i-th step of the login process based on the first signature carried, where i is an integer greater than 1.

[0043] In this embodiment, the client provides a webpage and displays an encoded graphic on the webpage for another terminal to scan and confirm, thereby enabling account login on the webpage. The encoded graphic can be a QR code, a one-dimensional barcode, a matrix two-dimensional barcode, etc. This embodiment uses a QR code as an example for illustration.

[0044] The first request informs the server to perform the i-th step of the login process. The i-th step refers to a segment of the complete login process, with each step having a unique name. For ease of description, the i-th step can also be called the i-th step. Here, i > 1, indicating a step other than the first step. For example, the login process is divided into three steps: generation, scanning, and confirmation. Based on this, the i-th step can be a scanning operation, with the first request being a scan result request, used to request the scanning results of the encoded graphics in the client's webpage; the i-th step can also be a confirmation operation, with the first request being a confirmation result request, used to request the login confirmation result.

[0045] The first signature refers to the verification credential generated by the server in the previous step (i.e., step i-1), combining the name of step i with the server's private preset key for encryption. This credential is then sent to the client in step i-1. The client needs this first signature to legitimately request step i; if the server fails to verify the first signature, it will reject the request. This first signature is used to bind adjacent steps in the login process, such as the generation and scanning steps, or the scanning and confirmation steps, to prevent forgery across steps.

[0046] The above description uses the example of a first signature generated from an operation name and a preset key, but this is not intended to be limiting. Besides the operation name and preset key, the first signature can also be generated based on at least one of a token (the session identifier for this login process) and request source information, which includes at least one of a source address and a source device identifier. This disclosure does not impose limitations. It is important to emphasize that since the first signature is generated in step i-1, the request source information used in the first signature refers to the source information of the request received in step i-1. Recording the source address and source device identifier, etc., in the first signature provides a basis for verification in this step.

[0047] In step 202, the server determines the second signature based on the name of the operation in step i and the preset key from the cache space.

[0048] In this embodiment of the disclosure, the cache space refers to the local storage area of ​​the server, where the preset key stored can only be read by the server and cannot be stolen by external attackers. It is the core guarantee for signature security and prevents attackers from forging signatures. For example, in a scenario with a distributed architecture of multiple servers, multiple servers share the cache space, where the preset key stored is the same. This ensures that no matter which server receives the request, it can generate the expected signature (i.e., the second signature) based on the same preset key, and then compare it with the received actual signature (i.e., the first signature) to complete the verification.

[0049] The second signature refers to the verification string that the server recalculates using the same parameters as when generating the first signature (such as the name and preset key in step i) after receiving the first request for the i-th step operation. This string serves as a comparison benchmark to verify whether the first signature uploaded by the client is valid.

[0050] In step 203, the server verifies the first signature based on the second signature and obtains the verification result. The first signature is determined by the name and preset key of the i-1th step operation when the server performs the i-1th step operation.

[0051] In this embodiment, the (i-1)th step refers to the preceding adjacent step of the current (i)th step. A legitimate login requires completing this step sequentially. The server only generates a first signature matching the i-th step when the (i-1)th step is executed; skipping it results in no legitimate signature. The verification result refers to the judgment conclusion output by the server after comparing the second signature with the first signature. It is divided into verification passed and verification failed. Verification failed indicates that there may be signature forgery, skipping of preceding steps, etc., and accordingly, the request is intercepted.

[0052] In step 204, if the verification result indicates that the verification is successful, the server sends the result corresponding to the first request to the client.

[0053] In this embodiment of the disclosure, the result corresponding to the first request refers to the data returned to the client by the server after completing the business logic of the i-th step operation, such as the result of successfully scanning the coded image or the result of confirming login. The business result will only be issued after the signature is verified and security is guaranteed.

[0054] This disclosure provides a login method that establishes relationships between adjacent steps in the login process through signatures. When performing step i-1, a first signature is generated based on the name of step i and a locally cached preset key, specifying the next step. When performing step i, a second signature is recalculated based on the name of this step and the preset key, and compared with the first signature in the request uploaded by the client, thereby verifying whether a cross-step request exists. If an attacker skips step i-1 and directly initiates a request targeting step i, they cannot obtain the compliant first signature generated during the execution of step i-1. Furthermore, since the preset key is stored only in a server-specific cache, the attacker cannot steal it. Therefore, even if the step name is known, a valid first signature cannot be forged. This ensures that a lack of a legitimate signature or a forged signature will result in failure to pass verification. In this way, cross-step attacks can be identified, unauthorized logins are avoided, and account security is improved.

[0055] In some embodiments, the first request carries a token that identifies the session for this login process; Based on the second signature, the first signature is verified to obtain the verification result, including: If the second signature is the same as the first signature, based on the token and the name of the i-th step operation, query the completion flag in the cache space. The completion flag indicates that the signature verification based on the name of the i-th step operation has been completed during this login process. If a completion marker is found, output the first verification result, which indicates that the verification failed. If no completion marker is found, output the second verification result, which indicates that the verification was successful.

[0056] In this embodiment, tokens are used to differentiate single login processes. Verification logic based on completion markers is set for the same session and the same login step, thereby preventing replay attacks. If a completion marker for the step already exists in the cache, it indicates a duplicate submission of the current step, and verification fails. Only when no marker is found is verification successful. This can accurately intercept malicious behavior of repeatedly submitting the same step request under the same login session, preventing repeated scans, repeated confirmations, and other duplicate operation attacks, further improving the verification logic of the login process and ensuring security.

[0057] In some embodiments, the method further includes: If no completion token is found, generate a completion token based on the token and the name of the i-th step operation, and store the completion token in the cache space.

[0058] In this embodiment, the completion marker is bound to a single login session and the corresponding operation step, recording that the step has been legally completed. When the same session subsequently initiates another request for the same step, duplicate operations can be quickly identified, preventing attacks involving repeated operations and improving verification efficiency and security.

[0059] In some embodiments, the first signature is verified based on the second signature to obtain a verification result, including: If the second signature is different from the first signature, the first verification result is output, indicating that the verification failed. If the second signature is the same as the first signature, output the second verification result, which indicates that the verification is successful.

[0060] In this embodiment, verification is deemed successful only when the second signature currently calculated by the server matches the first signature uploaded by the client; otherwise, verification fails. This is more efficient and suitable for lightweight login scenarios without replay attack protection requirements. It can quickly identify illegal requests with forged or tampered signatures, thus improving login efficiency.

[0061] In some embodiments, the method further includes: Based on the name and preset key of the i+1th step operation, a third signature is determined. The third signature is used by the client to generate a second request. The second request is used to perform the i+1th step operation in the login process based on the carried third signature.

[0062] In this embodiment, the server generates a third signature and sends it to the client as a legitimate credential for the client to initiate the next step request. This achieves a chain-like transfer of signatures across all steps in the login process. Each step generates a legitimate signature for the next step in advance, and the next step uses the signature returned from the previous step. This not only provides legitimate credentials but also maintains the signature binding relationship between preceding and subsequent steps, forming a continuous and reliable signature chain throughout the login process and creating a mandatory sequential dependency. Attackers cannot independently generate legitimate signatures for subsequent steps, preventing not only cross-step attacks (such as attackers being unable to skip scanning and directly confirm) but also signature prediction (i.e., attackers cannot pre-calculate signatures for future steps), ensuring the orderly execution of all steps in the login process.

[0063] In some embodiments, if the i-th step is a scanning operation, and the verification result indicates that the verification has passed, the result corresponding to the first request is sent to the client, including: If the coded graphic in the client has been successfully scanned and the verification result indicates that the verification has passed, the scan result and a third signature are sent to the client. The scan result indicates that the coded graphic has been successfully scanned.

[0064] In this embodiment, after successful QR code scanning and signature verification, the server returns the scanning result and the third signature required for the next confirmation operation to the client for verification. This ensures that the client can only initiate a login confirmation request with a valid signature, binding the QR code scanning and confirmation steps together. If an attacker skips the QR code scanning step and directly requests confirmation, they will fail verification due to the lack of a third signature. This protects against cross-step attacks that skip the QR code scanning step and directly confirm during the login process, thus improving the security of QR code login.

[0065] In some embodiments, if the i-th step is a confirmation operation, and the verification result indicates that the verification passed, the result corresponding to the first request is sent to the client, including: Once login is confirmed and the verification result indicates successful verification, a confirmation result and login credentials are sent to the client, with the confirmation result indicating that login has been confirmed.

[0066] In this embodiment, after login is confirmed and the signature is verified, the server returns a confirmation result and login credentials to the client to indicate that login is complete. Confirmation, as the final step in the login process, relies on the valid signature transmitted in the previous QR code scanning operation to complete the verification. This prevents attackers from bypassing the QR code scanning step to call the confirmation interface and obtain login credentials, ensuring that login credentials are issued only after the complete pre-process is finished, thus guaranteeing login security.

[0067] In some embodiments, if the (i-1)th step is a generation operation, the method further includes: During the execution of step i-1, a third request is received from the client, which is used to request the encoded graphic; Generate an encoded graphic based on the third request; Determine the first signature based on the name and preset key of the i-th step operation; Send the encoded image and first signature to the client.

[0068] In this embodiment, when a client requests an encoded graphic, the server generates the encoded graphic and generates a first signature based on the name of the next scanning operation and a preset key, which is then sent out. Subsequent scanning requests from the client must carry this signature, thus binding the encoded graphic generation and scanning steps together. Attackers cannot forge the signature themselves, ensuring the security of QR code login.

[0069] In some embodiments, the method further includes: Based on the third request, a token is generated, which is used to identify the session of this login process; Send a token to the client.

[0070] In this embodiment, a session token bound to the current login is created synchronously during the generation of the encoded graphic and sent to the client. The token serves as a unique identifier for each login session and is used throughout the entire login process, including scanning and confirmation. This allows the server to distinguish different login sessions based on the token, ensuring that signature verification and result feedback are confined to independent sessions. This isolates multi-session login data and improves the accuracy and security of verification in scenarios with concurrent logins by multiple users.

[0071] In some embodiments, the second signature is determined based on the name of the i-th step operation and a preset key from the cache space, including any of the following: The second signature is determined based on the token carried in the first request, the name of the operation in step i, and the preset key; Based on the source information of the first request, the name of the operation in step i, and the preset key, determine the second signature; The second signature is determined based on the token carried in the first request, the source information of the first request, the name of the operation in step i, and the preset key; The token is used to identify the session of this login process, and the source information of the first request includes at least one of the source address and source device identifier of the second request.

[0072] In this embodiment, in addition to the operation name and preset key, session tokens, request source addresses, and source device identifiers are also supported in the signature calculation, increasing signature complexity and further preventing request hijacking, man-in-the-middle attacks, etc. Even if an attacker steals the step name and key, a valid signature cannot be replicated without the session, device, and address information of the real client. The signature generation rules can be flexibly selected according to the business security level, adapting to login services with different security requirements and improving flexibility.

[0073] The above Figure 2 This document provides a brief introduction to the login method offered in this publication. The following section elaborates on this method. For ease of description, an overall architecture is provided. See [link to documentation]. Figure 3 As shown, Figure 3 This is a schematic diagram illustrating an overall system architecture according to an exemplary embodiment, showing the interaction relationships and data flow between various parts of the system.

[0074] In this system, the server is configured in the aforementioned server 101, the browser is configured in the aforementioned first terminal 102, the mobile terminal is configured in the aforementioned second terminal 103, and the storage layer is the storage space associated with server 101.

[0075] The browser-side (i.e., web-based client) includes two modules: a web page and an encoded graphic display. As the login initiator, it displays the login page and encoded graphic to the user and maintains a persistent connection to await scanning and confirmation results. The server-side includes a signature generator, a signature verifier, a token manager, and state machine control. The signature generator is a core component of the server, used to perform signature calculations for each step of the login process using the HMAC-MD5 algorithm. It generates valid signatures for each step, for example, calculating a unique signature based on qrToken (the token), IP address (the source address of the request), device ID (the identifier of the source device), operation name, and salt value (the preset key). The signature verifier is another core component of the server, used to verify the validity of the signature uploaded by the client, recalculate the expected signature (the second signature), compare it with the submitted actual signature (the first signature), and check the completion marker. The token manager manages the entire lifecycle and state of tokens, including token generation, expiration checks, and state transition control. The state machine control manages the state transitions during the login process, with the state sequence being NEW (new), SCANNED (scanned), and ACCEPTED (login confirmed). The mobile app includes a QR code scanning module, where users scan the encoded image displayed in the browser and submit confirmation for login. The caching layer includes the Redis caching (i.e., cache space) service, which serves as an independent cache space for the server. It stores token status, completion markers, PubSub message notifications, etc., and provides data support for signature verification, status verification, etc. It can ensure the consistency of the status of the data obtained by each server in a distributed deployment scenario.

[0076] The diagram illustrates a 10-step interaction process to implement the login method provided in this disclosure, in the following order: 1. The web page sends a request to the signature generator on the server to generate a token for the current login session and a signature for the corresponding step; 2. The token manager creates a unique login session token; 3. The Redis cache initializes the session state and stores the newly created (NEW) session state; 4. The signature generator calculates the signature using a preset key and operation name, and the server returns the token, signature, and encoded graphic to the browser for rendering and display by the encoded graphic display module; 5. The user scans the encoded graphic displayed on the browser using the mobile app; 6. The mobile app extracts the token carried within the encoded graphic. 7. The signature verifier reads the data from the Redis cache and simultaneously verifies the signature validity and session state. 8. The state machine controls the update of the session state corresponding to the token in the Redis cache (from NEW to SCANNED). 9. The server generates a state change message through the PubSub mechanism and stores it in the Redis cache. 10. The Redis cache pushes the session state change notification to the browser in real time, and the browser's web page refreshes to display the current login progress. If the user completes login confirmation on the mobile device, a confirmation request will be initiated again. The server repeats the signature verification logic, the state machine is updated to ACCEPTED, and finally the login credentials are issued to the browser.

[0077] In simple terms, the above steps can be summarized as follows: the browser obtains the Token and Signature 1 (i.e., the first signature generated in the generation step) through the signature generator; the APP scans the code and notifies the server; the Redis cache sends a PubSub message; the signature verifier verifies Signature 1 and generates Signature 2 (i.e., the third signature generated in the scanning step); the browser uses Signature 2 to request confirmation; the signature verifier verifies Signature 2 and returns a login success message.

[0078] Based on the overall architecture described above, this disclosure further explains the login method proposed, mainly focusing on how to generate a signature (i.e., the role of the signature generator) and how to verify the signature (i.e., the role of the signature verifier). See [link to documentation]. Figure 4 , Figure 4 This is a flowchart illustrating another login method according to an exemplary embodiment, the method being performed by a server (i.e., the one described above). Figure 3 The process is executed on the server side (in the context of the process), including the following steps.

[0079] In step 401, the server receives a first request from the client. The first request is used to perform the i-th step of the login process based on the first signature carried. The first signature is determined by the name of the i-th step and the preset key when the server performs the (i-1)-th step, where i is an integer greater than 1.

[0080] In this embodiment of the disclosure, the principle of this step is the same as that of step 201, and will not be repeated here.

[0081] In step 402, the server determines the second signature based on the name of the operation in step i and the preset key from the cache space.

[0082] In this embodiment of the disclosure, the principle of this step is the same as that of step 202, and will not be repeated here.

[0083] The above description uses the example of a signature generated based on the operation name and a preset key, but it does not constitute a limitation. Signatures can also be generated by combining other factors, such as tokens, the source address of the request (i.e., IP address), the source device identifier of the request (i.e., device ID, etc.), as long as the expected signature currently calculated (i.e., the second signature) and the actual signature received from the client (i.e., the first signature) use the same dimensions of factors and the same calculation method.

[0084] For example, the signature generation process is implemented as follows: the server determines a second signature based on the token carried in the first request, the name of the operation in step i, and a preset key; correspondingly, the first signature is generated based on the token, the name of the operation in step i, and the preset key when the server performs the (i-1)th step operation; the server determines a second signature based on the source information of the first request, the name of the operation in step i, and the preset key; correspondingly, the first signature is generated based on the source information of the request received in step i-1, the name of the operation in step i, and the preset key when the server performs the (i-1)th step operation; the server determines a second signature based on the token carried in the first request, the source information of the first request, the name of the operation in step i, and the preset key; correspondingly, the first signature is generated based on the token, the source information of the request received in step i, the name of the operation in step i, and the preset key when the server performs the (i-1)th step operation. Wherein, the token is used to identify the session of this login process, and the source information of the first request includes at least one of the source address of the second request and the source device identifier.

[0085] It should be noted that the first signature is used to provide a basis for the legitimacy of subsequent steps, while the second signature is used to verify the legitimacy of newly received requests. Therefore, it is easy to see that in the generation step, signature 1 (belonging to the first signature) is generated to provide a basis for subsequent steps; in the scanning step, signature 1 is received, and signature 3 (belonging to the second signature) is generated for legitimacy verification. After successful verification, signature 2 (belonging to the first signature) is generated to provide a basis for subsequent steps; in the confirmation step, signature 2 is received, and signature 4 (belonging to the second signature) is generated. Since there are no subsequent steps, further first signature generation is unnecessary, and the process can be terminated at this point. The above content has clearly defined the various signature generation rules, i.e., what kind of signature is generated. The specific information on which each signature is generated in each step (i.e., generation, scanning, and confirmation) will not be elaborated here but will be explained later.

[0086] In this approach, in addition to the operation name and preset key, session tokens, source addresses, and source device identifiers are also supported in the signature calculation, increasing signature complexity and further preventing request hijacking, man-in-the-middle attacks, etc. Even if an attacker steals the step name and key, a valid signature cannot be replicated without the session, device, and address information of the real client. Signature generation rules can be flexibly selected according to the business security level, adapting to login services with different security requirements and improving flexibility.

[0087] The following example illustrates how the HMAC signature algorithm combines four factors—IP address, device ID, token, and operation name—to generate a unique signature, thus achieving multi-layered security protection. (See also...) Figure 5 As shown, Figure 5 This is a schematic diagram illustrating a signature generation process according to an exemplary embodiment, implemented by a signature generator in a server.

[0088] The signature factors include qrToken, ip, deviceId, nextAction, and salt. qrToken is a Base64 encoded string containing a timestamp, type, and UUID. If the current step is a generation step, this token is generated by the server in this step; if the current step is a scanning step, this token is carried in the first request received from the client in this step. ip refers to the source address of the request received from the client in this step, obtained from the HTTP request header (supporting IPv4 and IPv6), binding the request source to prevent cross-IP hijacking. If the current step is a generation step, this source address is the source address of the encoded image generation request (also known as the third request) received in this step; if the current step is a scanning step, this source address is the source address of the QR code result request (i.e., the first request) received in this step. deviceId is the identifier of the source device of the request, obtained from a cookie. If the current step is a generation step, then this source address is the source address of the encoded image generation request (also known as the second request) received in this step; if the current step is a scanning step, then this source address is the source address of the scan result request (belonging to the first request) received in this step. `nextAction` refers to the name of the next operation, such as "scanResult", "acceptResult", or "succ", binding the signature to a specific step to prevent cross-step usage. `Salt` refers to the predefined salt value (i.e., the preset key) on the server side, in byte array format, shared by all servers in a distributed architecture.

[0089] As shown in the diagram, after determining each signature factor, the signature content is concatenated, combining the four factors according to a fixed format to form a single string. Spaces are used as separators, and the trim operation ensures no extra whitespace characters. An HMAC key is prepared, and the salt value is hexadecimal encoded, converting the byte array format salt value into a hexadecimal string to ensure all servers use a consistent key format. An HMAC-MD5 signature is calculated, using the key and content to calculate the message authentication code, thus generating an unforgeable signature. The HMAC algorithm ensures that only the party holding the key (i.e., the server) can generate a valid signature; even a slight change in the content will result in a completely different signature (i.e., the avalanche effect). The signature is converted to a hexadecimal string, transforming the binary signature into a transmittable string format suitable for HTTP transmission. The hexadecimal signature string is output, with a length of 32 characters (128-bit MD5 hexadecimal representation). For example, this signature string is a3f2e8d1c4b5f6a7b8c9d0e1f2a3b4c5.

[0090] Compared to traditional methods that rely solely on token verification, this disclosure combines multiple factors such as IP address, Device ID, token, and Action for HMAC signatures, achieving multi-factor binding. Any change in any of these factors results in a signature mismatch, significantly enhancing security. Furthermore, the irreversibility and avalanche effect of the HMAC algorithm ensure that the signature cannot be forged or predicted.

[0091] The above content describes how signatures are generated in each step. However, in some steps, the server needs to generate not only the signature but also other data requested by the client. Therefore, the data generated by the server during the generation process will be described in detail below. For ease of description, we will take the generation of a signature based on the operation name and a preset key as an example. The same principle applies when generating signatures by combining other factors, and will not be elaborated further.

[0092] In some embodiments, during the generation operation, the server receives a third request from the client, which requests an encoded graphic; based on the third request, the server generates the encoded graphic; based on the name of the i-th step operation and a preset key, the server determines a first signature; and the server sends the encoded graphic, the first signature, and the name of the i-th step operation to the client. By generating the encoded graphic when the client requests it, and generating and sending the first signature based on the name of the next scanning operation and the preset key, the server ensures that subsequent scanning requests from the client must carry this signature. This binds the encoded graphic generation and scanning steps together, preventing attackers from forging the signature and ensuring the security of QR code login.

[0093] In other embodiments, during the generation process, the server generates a token based on the third request. This token identifies the session for the current login process and is sent to the client. By synchronously creating and issuing a session token bound to the current login during the generation phase of the encoded graphic, the token serves as a unique identifier for each login throughout the entire login process, including scanning and confirmation. This allows the server to distinguish different login sessions based on the token, confining signature verification and result feedback to independent sessions, isolating multi-session login data, and improving the accuracy and security of verification in multi-user concurrent login scenarios.

[0094] For example, during the generation operation, the server can also send the name of the next operation (i.e., the name of the scan operation) to the client to indicate the subsequent steps.

[0095] In step 403, if the second signature is different from the first signature, the server outputs a first verification result, which indicates that the verification failed.

[0096] In this embodiment, if the second signature is identical to the first signature, the server outputs a second verification result, indicating that the verification has passed. Verification is initially determined to be successful only when the second signature currently calculated by the server matches the first signature uploaded by the client; otherwise, verification fails. This approach is more efficient and suitable for lightweight login scenarios without replay attack protection requirements. It can quickly identify illegal requests with forged or tampered signatures, thus improving login efficiency.

[0097] Step 403 above is an exemplary method of verifying the first signature based on the second signature to obtain the verification result, but it does not constitute a limitation. When the first signature and the second signature are the same, replay attacks can also be excluded based on the completion flag, as shown in steps 404 to 406 below.

[0098] In step 404, if the second signature is the same as the first signature, the server queries the cache space for a completion flag based on the token and the name of the i-th step operation. The completion flag indicates that the signature verification based on the name of the i-th step operation has been completed during this login process.

[0099] In this embodiment, this step occurs when the signatures are determined to be identical during the scanning or confirmation step. Since the token and the step name can determine which login session and step the signature corresponds to, using this combination as a unique retrieval key to query the completion marker in the cache accurately distinguishes verification records for different login sessions and different operation steps, avoiding confusion between completion markers from different sessions and steps. For example, the Redis key for the completion marker is `cacheKey`, in the format "qr:scan:{token}:{action}", ensuring the uniqueness of the combination of Token and Action.

[0100] In step 405, if a completion marker is found, the server outputs the first verification result, which indicates that the verification failed.

[0101] In this embodiment of the disclosure, if a corresponding completion marker is found, it means that the step has been legally verified under the current login session, and it is a duplicate submission request, so it is determined that the verification fails.

[0102] In step 406, if no completion marker is found, the server outputs a second verification result, which indicates that the verification has passed.

[0103] In this embodiment of the disclosure, if no corresponding completion marker is found, it indicates that this is the first valid request for this step under the current login session, and the verification is deemed successful. For example, the second verification result is true, and the first verification result is false.

[0104] In some embodiments, if no completion marker is found, a completion marker is generated based on the token and the name of the i-th step operation, and this marker is stored in the cache. This records that the step has been legally completed. When the same login session subsequently requests this step again, duplicate operations can be quickly identified, preventing attacks involving repeated operations and improving verification efficiency and security.

[0105] Steps 404 to 406 above are another exemplary method for verifying the first signature based on the second signature to obtain the verification result, but they do not constitute a limitation. In this method, a token is used to distinguish a single login process, and the operation name is used to distinguish different steps. Verification logic based on completion markers is set for the same session and the same step, thereby avoiding replay attacks. If a completion marker corresponding to the step already exists in the cache, it means that the current step has been submitted repeatedly, and the verification fails; only if there is no marker is the verification considered successful. This can accurately intercept malicious behavior of repeatedly submitting the same step request under the same login session, preventing repeated scanning, repeated confirmation, and other repeated operation attacks, further improving the verification logic of the login process and ensuring security.

[0106] In some embodiments, in addition to the above-described judgment logic, the server can also make a judgment based on the token's validity period. Accordingly, if the time interval between the current timestamp and the timestamp carried in the token exceeds the preset validity period corresponding to the token, a first verification result is output, indicating that the verification failed. In other embodiments, a preset timeout period is also set; after the preset timeout period expires, the request is automatically cleaned up to avoid memory leaks. For example, the preset timeout period is set to 180 seconds, consistent with the preset validity period of the token.

[0107] The following explanation will continue using the example of a signature generated using the HMAC signature algorithm based on four factors: IP address, device ID, token, and operation name. See also... Figure 6 As shown, Figure 6 This is a schematic diagram illustrating a signature verification process according to an exemplary embodiment, implemented by a signature verifier in a server.

[0108] The request received in this step (i.e., the first request) carries requestSign (a signature string submitted by the client) and qrToken (a token submitted by the client). Furthermore, the factors that can be extracted from this request include IP (the source address of the current request, obtained in real time from the HTTP request header), deviceId (the source device identifier of the current request, obtained in real time from the cookie), and action (the operation type of the current API, determined by the server based on the request path, such as / scanResult corresponding to "scanResult"). In addition, the salt (i.e., the salt value, also known as the preset key) can be obtained from the server's local cache space.

[0109] As shown in the diagram, upon receiving a request from the client, verification factors are extracted. All parameters required for verification are obtained from the request context, thus collecting all the necessary information to ensure consistency with the parameters used when generating the signature. The expected signature is recalculated using the same algorithm as during generation, thus regenerating the signature on the server side. Due to the deterministic nature of the HMAC algorithm, the same input produces the same output. The signatures are compared; an exact string match verifies the legitimacy of the request. A signature mismatch indicates that the request has been tampered with or has an illegitimate source. After a signature match, a completion flag is checked by querying the Redis cache to prevent replay attacks. Even if an attacker obtains a legitimate signature, it can only be used once. If there is no completion flag in the cache, a completion flag is set (for first-time use) and recorded in Redis, marking that the Token+Action combination has been used and preventing subsequent reuse. If a completion flag exists in the cache, it is considered a replay attack, and the request is rejected. In the case of a signature mismatch, verification fails, and the request is rejected. The above verification failures and replay attacks both fall under the category of verification failure. Additionally, it can check configuration switches, supporting differentiated configurations for different environments, thus enabling gradual deployment and troubleshooting. If verification passes, it returns true, allowing continued processing of business logic; if verification fails, it returns false, sends an exception rejection request, and logs detailed information.

[0110] Compared to traditional solutions that only check token validity, this disclosed embodiment combines signature verification and replay protection mechanisms. Signature verification ensures the request originates legitimately (IP and deviceId match), while replay protection ensures the request is not reused. This protects against replay attacks, where attackers intercept and repeatedly send legitimate user network requests in an attempt to bypass authentication. These two layers of protection are complementary; even if one fails, the other still protects system security. Furthermore, IP binding is employed, as the signature is associated with a specific IP address (i.e., the source address). Only this specific IP address can verify the token, preventing it from being used on other IPs after hijacking. Attackers who hijack tokens will also fail verification on different IPs, preventing cross-device hijacking and enhancing anti-hijacking capabilities.

[0111] In step 407, if the verification result indicates that the verification is successful, the server sends the result corresponding to the first request to the client.

[0112] In this embodiment of the disclosure, if the first request corresponds to a scanning operation, the result corresponding to the first request indicates that the scan has been successful; if the first request corresponds to a confirmation operation, the result corresponding to the first request indicates that the login has been confirmed.

[0113] In some embodiments, to form a signature chain, after the above steps, the server determines a third signature based on the name and preset key of the operation in step i+1. This third signature is used by the client to generate a second request, which is then used to execute the operation in step i+1 of the login process based on the carried third signature, such as a confirmation request. In this approach, the server generates a third signature and sends it to the client as a legitimate credential for the client to initiate the next step request. This achieves a chain-like transfer of signatures across all steps in the login process. Each step generates a legitimate signature for the next step in advance, and the next step uses the signature returned from the previous step. This not only provides legitimate credentials but also maintains the signature binding relationship between preceding and subsequent steps, forming a continuous and reliable signature chain throughout the login process and creating a mandatory sequential dependency. Attackers cannot independently generate legitimate signatures for subsequent steps, preventing not only cross-step attacks (e.g., attackers cannot skip scanning and directly confirm) but also signature prediction (i.e., attackers cannot pre-calculate signatures for future steps), ensuring the orderly execution of all steps in the login process.

[0114] Having described the content generated in each step above, the following details the data returned to the client in each step.

[0115] Accordingly, if the i-th step is a scanning operation, and the coded pattern in the client has been successfully scanned and the verification result indicates successful verification, the scan result and a third signature are sent to the client. The scan result indicates that the coded pattern has been successfully scanned. For example, the name of the (i+1)-th step can also be sent simultaneously. This ensures that the client can only initiate a login confirmation request after obtaining a valid signature, binding the scanning and confirmation steps together. If an attacker skips the scanning operation and directly requests confirmation, they will fail verification due to the lack of a third signature. This protects against cross-step attacks that skip the scanning step and directly confirm during the login process, improving the security of QR code login.

[0116] Accordingly, if the i-th step is a confirmation operation, and the login has been confirmed and the verification result indicates successful verification, a confirmation result and login credentials are sent to the client. The confirmation result indicates that the login has been confirmed. As the final step in the login process, confirmation relies on the valid signature transmitted in the previous QR code scanning operation to complete the verification. This prevents attackers from bypassing the QR code scanning step to call the confirmation interface and obtain login credentials, ensuring that login credentials are issued only after the complete pre-process is finished, thus guaranteeing login security.

[0117] This disclosure provides a login method that establishes relationships between adjacent steps in the login process through signatures. When performing step i-1, a first signature is generated based on the name of step i and a locally cached preset key, specifying the next step. When performing step i, a second signature is recalculated based on the name of this step and the preset key, and compared with the first signature in the request uploaded by the client, thereby verifying whether a cross-step request exists. If an attacker skips step i-1 and directly initiates a request targeting step i, they cannot obtain the compliant first signature generated during the execution of step i-1. Furthermore, since the preset key is stored only in a server-specific cache, the attacker cannot steal it. Therefore, even if the step name is known, a valid first signature cannot be forged. This ensures that a lack of a legitimate signature or a forged signature will result in failure to pass verification. In this way, cross-step attacks can be identified, unauthorized logins are avoided, and account security is improved.

[0118] Below, we will go a step further and explain in detail how to form a dynamically flowing signature chain. See [link / reference] Figure 7 , Figure 7 This is a schematic diagram illustrating a multi-step signature flow according to an exemplary embodiment, executed by a server, including steps one to three, in which different signatures are generated in each step, forming a signature chain.

[0119] Step 1: Generation step, used to generate coded graphics.

[0120] In this step, the browser sends a request to the server to generate an encoded graphic (belonging to the third request mentioned above). This request carries parameters such as type, qrType, and kpn. Based on this request, the server generates a token and an encoded graphic. The server calculates signature 1 (belonging to the first signature) and binds it to the next operation "scanResult". The server sends the data from this step (including the token, encoded graphic, signature 1, etc.) to the browser.

[0121] The code for the server to generate the token is as follows: “token = Base64 encoded({ qrLoginType: "web-login", issueTime: Current timestamp expireTime: 180 seconds, uuid: Random UUID })”.

[0122] The code for the server to generate signature 1 is as follows: "sign1 = genSign(token, ip, deviceId, "scanResult", salt)" The code for the server to return data to the browser is as follows: { "qrLoginToken": token, "qrLoginSignature": sign1, "next": "scanResult", / / Prompt for the next step "imageData": "A base64 encoded QR code image" }".

[0123] Step 2: Scanning step, used to wait for the scan results.

[0124] In this step, the browser makes a long-connection request for the scan results, carrying the token and sign1; the server verifies signature 1; the server checks for replay protection; the server keeps the connection open (DeferredResult) and waits for the APP to scan the code; after the APP scans the code, the server updates the status, calculates signature 2 (which belongs to the third signature), and binds it to the next operation "acceptResult"; the server wakes up the long-connection through Redis PubSub and sends the data from this step (including the scan results, signature 2, etc.) to the browser.

[0125] The server verifies signature 1 using the following code: "checkSign(sign1, token, ip, deviceId, "scanResult", salt) / / Verification passed, indicating the request originated from the browser that generated the QR code. The server-side code for checking replay protection is as follows: "if (Redis.exists("qr:scan:" + token + ":scanResult")) { Denied: Duplicate Request } Redis.set("qr:scan:" + token + ":scanResult", "1", 180 seconds)".

[0126] The server's code for calculating signature 2 is as follows: "sign2 = genSign(token, ip, deviceId, "acceptResult", salt)" The code for the server to return data to the browser is as follows: { "status": "SCANNED", "qrLoginSignature": sign2, / / New signature for the next step "next": "acceptResult" }".

[0127] Step 3: Confirmation step, used to wait for confirmation results.

[0128] In this step, the browser makes a long connection request to confirm the result, carrying the token and sign2; the server verifies signature2; the server checks for replay protection; the server holds the connection and waits for the APP to confirm; after the APP confirms the login, the server generates login credentials; the server sends the data of this step (including confirmation result, login credentials, etc.) to the browser.

[0129] The server verifies signature 2 using the following code: "checkSign(sign2, token, ip, deviceId, "acceptResult", salt) / / Verification passed, indicating that the request has undergone the scanning process.

[0130] The server-side code for checking replay protection is as follows: "if (Redis.exists("qr:scan:" + token + ":acceptResult")) { Denied: Duplicate Request } Redis.set("qr:scan:" + token + ":acceptResult", "1", 180 seconds)".

[0131] The code for the server to generate login credentials is as follows: "authToken = createAuthToken(userId, "kuaishou.qr.login", deviceId,300 seconds)" The code for the server to return data to the browser is as follows: { "status": "ACCEPTED", "qrToken": Base64 encoded (authToken) / / Login success credential }".

[0132] After completing steps one through three above, the browser obtains the login credential authToken and completes the login process.

[0133] The above Figure 7 This is a sequence diagram of the multi-step signature flow, showing the complete three-step process from the generation of the encoded image to successful login, including: Step 1: Generating a QR code (generating sign1); Step 2: Waiting for scanning (verifying sign1, generating sign2); Step 3: Waiting for confirmation (verifying sign2, returning authToken). The generation, verification, and transmission processes of each signature are highlighted, as well as the formation of the signature chain.

[0134] The entire login process involves three signature verifications, each with a different signature. Sign1 can only be used in step two (scanResult) and bound to the action parameter; sign2 can only be used in step three (acceptResult) and bound to the action parameter. The signature transmission forms a chain: without sign1, sign2 cannot be obtained, and without sign2, authToken cannot be obtained. Each step has a replay protection check, and signatures cannot be reused.

[0135] Compared to traditional solutions that use fixed signatures or no signatures at all, this disclosure presents a dynamically flowing signature chain mechanism. Each step generates a different signature, and the next step uses the signature returned from the previous step. Intermediate steps cannot be skipped; sign1→sign2→authToken form a mandatory sequential dependency. This design effectively prevents cross-step attacks (attackers cannot skip the scan and directly confirm) and signature prediction (attackers cannot pre-calculate signatures for future steps). Furthermore, each signature step is bound to a specific operation, so even if an attacker obtains a signature from a certain step, they cannot use it in other steps.

[0136] For ease of understanding, an exemplary description of the overall process is provided below. The scenario is that a user accesses the target application's website through a PC browser and logs in by scanning a QR code using the target application's app. The input data is: User IP address = 192.168.1.100; Browser DeviceID = ANDROID_25a00f3fc1876302; Salt value = a predefined fixed value on the server; Login type = WEB_LIVE. The execution process is described in steps 1 to 3 below.

[0137] Step 1: The browser requests and generates the encoded image, as shown in the following code: "Request: GET / rest / c / infra / ks / new / qr / start?type=WEB_LIVE Source IP: 192.168.1.100 DeviceID:ANDROID_25a00f3fc1876302".

[0138] In detail, the server generates a token: token123456789 → calculates signature 1: sign1 = HMAC-MD5(Hex(salt), "192.168.1.100 ANDROID_25a00f3fc1876302 token123456789scanResult") = a3f2e8d1c4b5... → returns: {"qrLoginToken": "token123456789", "qrLoginSignature": "a3f2e8d1c4b5...", "next": "scanResult", "imageData":"..."}.

[0139] Step 2: The browser maintains a persistent connection and waits for the scan, using the sign1 returned in Step 1, as shown in the following code: "ask: GET / rest / c / infra / ks / new / qr / scanResult?qrLoginToken=token123456789&qrLoginSignature=a3f2e8d1c4b5... Source IP: 192.168.1.100 (same as step 1)".

[0140] In detail, the server recalculates the expected signature: expectedSign = HMAC-MD5(...) = a3f2e8d1c4b5... → compares the signature: expectedSign == a3f2e8d1c4b5... Verification passed → Check Redis: qr:scan:token123456789:scanResult does not exist. → Set the anti-replay flag (i.e., completion flag): Redis.set("qr:scan:token123456789:scanResult", "1", 180 seconds) → DeferredResult Holds the connection and waits for the APP to scan the code.

[0141] After the user scans the coded image using the APP, the APP sends a scan notification: POST / qr / scanned?qrLoginToken=token123456789 → The server updates the Redis status to SCANNED and sends a PubSub message → The server calculates signature 2: sign2 = HMAC-MD5(Hex(salt), "192.168.1.100 ANDROID_25a00f3fc1876302 token123456789 acceptResult") = e7d9f3a2b6c1... → Returns to the browser: {"status": "SCANNED", "qrLoginSignature": "e7d9f3a2b6c1...", "next": "acceptResult"}.

[0142] Step 3: The browser waits for confirmation via a persistent connection, using the sign2 returned in Step 2, as shown in the following code: "ask: GET / rest / c / infra / ks / new / qr / acceptResult?qrLoginToken=token123456789&qrLoginSignature=e7d9f3a2b6c1... Source IP: 192.168.1.100 (same as step 2)".

[0143] In detail, the server recalculates the expected signature: expectedSign = HMAC - MD5(...) = e7d9f3a2b6c1... → compares the signature: expectedSign == e7d9f3a2b6c1... Verification passed → Check Redis: qr:scan:token123456789:acceptResult does not exist. → Set the anti-replay flag (i.e., completion flag): Redis.set("qr:scan:token123456789:acceptResult", "1", 180 seconds) → DeferredResult Holds the connection and waits for the APP to confirm.

[0144] After the user confirms login on the app, the app sends a confirmation notification: POST / qr / accept?qrLoginToken=token123456789 → The server updates the Redis status to ACCEPTED and sends a PubSub message → The server generates login credentials: authToken = createAuthToken(userId=10086, ...) → Returns to the browser: {"status": "ACCEPTED", "qrToken": "base64(authToken)"}.

[0145] After steps 1 to 3 above, the final output is: the browser obtains the authToken and logs in successfully. The entire process takes about 2-3 seconds, with the signature verification delay being <1ms.

[0146] To facilitate understanding, several scenarios for identifying attackers using this method are given below, see scenarios A to C below.

[0147] Scenario A: An attacker hijacks a token from another IP address. The verification process is as follows: "Attacker's IP: 10.0.0.50 (different from the original IP 192.168.1.100)" Attacker request: / scanResult?qrLoginToken=token123456789&qrLoginSignature=a3f2e8d1c4b5... The server calculates the expected signature: expectedSign = HMAC-MD5(Hex(salt), "10.0.0.50 ANDROID_25a00f3fc1876302 token123456789 scanResult") = "b5c3d2a4e1f9..." / / Different from the original signature a3f2e8d1c4b5... Result: Signature verification failed, request rejected.

[0148] Scenario B: An attacker attempts to skip the scan and directly confirm the verification process, which is as follows: "The attacker requests: / acceptResult, using sign1 (instead of sign2)." Server verification: The action is set to "acceptResult", but the action bound to sign1 is "scanResult". When recalculating the expected signature using "acceptResult", the result does not match sign1. Result: Signature verification failed, request rejected.

[0149] Scenario C: An attacker repeatedly sends legitimate requests. The verification process is as follows: Attacker's first request: / scanResult (success) Redis setting: qr:scan:token123456789:scanResult = "1" Attacker's second request: / scanResult (same parameters) Redis check: qr:scan:token123456789:scanResult exists Result: The replay protection mechanism rejected the request.

[0150] This disclosure provides a login method that binds multiple security factors through HMAC signature to form a dynamically flowing signature chain, achieving a balance between security and performance. It can prevent token hijacking, cross-step attacks and replay attacks, with a hijacking success rate of >99.9%. Its core design is described in (1)-(4) below.

[0151] (1) Multi-factor signature: The four factors of IP address, device ID, token and operation action are combined and the HMAC-MD5 algorithm is used to generate a signature. Any change in any factor will result in a signature mismatch. Traditional solutions cannot strongly bind the token to the request source IP, which means that the token can be used by any IP after being leaked. This disclosure embeds the IP address in the signature. When the server verifies, it compares the request source IP. Even if the token is leaked, attackers cannot generate a valid signature on different IPs, thus achieving strong binding of IP addresses. Any request with an inconsistent IP is rejected.

[0152] (2) Adopting a dynamic signature flow design: Each operation step (generate, scan, confirm) generates a different signature, and the next step uses the new signature returned by the previous step to form a signature chain, preventing cross-step attacks. Traditional schemes do not strictly control the order of operation steps, and attackers may skip intermediate steps. This disclosure generates different signatures for different operation steps to prevent cross-step attacks.

[0153] (3) Adopt a dual anti-replay mechanism: Combining signature uniqueness and Redis cache tagging, dual anti-replay protection is achieved, and each token state is only allowed to flow in one direction. Traditional solutions lack effective protection against replay attacks. After an attacker intercepts a legitimate request, it can be sent repeatedly. This disclosure generates a unique signature for each operation step and limits the number of times each token can be used.

[0154] (4) Scalable design is adopted: To adapt to the horizontal scaling required for large-scale applications, a deterministic signature algorithm is adopted, so that all servers using the same key and algorithm can obtain consistent results without relying on state synchronization between servers. In addition, efficient signature verification is adopted without adding significant latency (latency must be less than 1 millisecond); a user-friendly prompt is given when verification fails, without affecting the use of normal users.

[0155] This provides a highly secure, high-performance, and easy-to-implement QR code login anti-hijacking solution, achieving an anti-hijacking success rate of >99.9%, verification latency of <1ms, and supporting millions of QPS. The following comparison with traditional solutions further illustrates its effectiveness, see (1)-(4) below.

[0156] (1) Significantly improved security: the success rate of anti-hijacking increased from about 60% in the existing scheme to >99.9%, an increase of 39.9 percentage points; the success rate of anti-replay attack increased from about 50% to >99.9%, an increase of 49.9 percentage points.

[0157] (2) Excellent performance: Signature verification latency <1ms, which is more than 50% lower than the traditional solution (about 2ms to query the database); single-machine QPS is increased from hundreds of thousands to millions, and the performance is improved several times; pure memory computing, does not rely on database query, and supports horizontal scaling.

[0158] (3) Easy to implement: The core code is less than 100 lines, reducing implementation costs by about 30%; based on the standard HMAC algorithm, no dedicated hardware or additional components are required; supports progressive deployment, and the verification rigor can be controlled by configuration switches.

[0159] (4) High maintainability: Detailed logging (records all parameters when signatures do not match), which facilitates troubleshooting; clear error messages (user-friendly + developer debugging), which reduces operation and maintenance costs; flexible configuration (supports configuration based on environment differences), which can adapt to different deployment scenarios.

[0160] See Table 1 below for a comparison of the effects of the traditional solution and the solution disclosed herein.

[0161]

[0162] All of the above-mentioned optional technical solutions can be combined in any way to form optional embodiments of this disclosure, and will not be described in detail here.

[0163] Figure 8 This is a block diagram illustrating a login device according to an exemplary embodiment. Figure 8 As shown, the device includes: a receiving unit 801, a determining unit 802, a verifying unit 803, and a sending unit 804.

[0164] The receiving unit 801 is configured to receive a first request from the client, the first request being used to perform the i-th step of the login process based on the first signature carried, where i is an integer greater than 1; The determining unit 802 is configured to perform a second signature based on the name of the i-th step operation and a preset key from the cache space; Verification unit 803 is configured to perform verification of the first signature based on the second signature and obtain a verification result. The first signature is determined by the name of the i-1th step operation and the preset key when the server performs the i-1th step operation. Sending unit 804 is configured to send the result corresponding to the first request to the client if the verification result indicates that the verification has passed.

[0165] In some embodiments, the first request carries a token that identifies the session for this login process; Verification unit 803 is configured to perform the following: if the second signature is the same as the first signature, query the cache space for a completion flag based on the token and the name of the i-th step operation. The completion flag indicates that the signature verification based on the name of the i-th step operation has been completed during this login process. If the completion flag is found, output the first verification result, which indicates that the verification failed. If the completion flag is not found, output the second verification result, which indicates that the verification passed.

[0166] In some embodiments, the verification unit 803 is further configured to perform the following: if no completion token is found, generate a completion token based on the token and the name of the i-th step operation, and store the completion token in the cache space.

[0167] In some embodiments, the verification unit 803 is configured to perform the following: if the second signature is different from the first signature, output a first verification result indicating that the verification failed; if the second signature is the same as the first signature, output a second verification result indicating that the verification passed.

[0168] In some embodiments, the apparatus further includes: The generation unit is configured to perform the operation based on the name and preset key of the (i+1)th step, determine the third signature, the third signature is used by the client to generate a second request, and the second request is used to perform the (i+1)th step of the login process based on the carried third signature.

[0169] In some embodiments, if the i-th step is a scanning operation, the sending unit 804 is configured to perform: if the coded graphic in the client has been successfully scanned and the verification result indicates that the verification has been passed, send the scanning result and the third signature to the client, wherein the scanning result indicates that the coded graphic has been successfully scanned.

[0170] In some embodiments, if the i-th step is a confirmation operation, the sending unit 804 is configured to perform the following: if the login has been confirmed and the verification result indicates that the verification has passed, send a confirmation result and login credentials to the client, wherein the confirmation result indicates that the login has been confirmed.

[0171] In some embodiments, if the (i-1)th step is a generation operation, the apparatus further includes: The receiving unit 801 is also configured to receive a third request from the client during the execution of the (i-1)th step operation, the third request being for requesting an encoded graphic; The generation unit is configured to generate encoded graphics based on a third request; The generation unit is also configured to determine the first signature based on the name and preset key of the i-th step operation; The sending unit 804 is also configured to send the encoded graphic and the first signature to the client.

[0172] In some embodiments, the apparatus further includes: The generation unit is also configured to generate a token based on a third request, the token being used to identify the session for this login process; The sending unit 804 is also configured to send a token to the client.

[0173] In some embodiments, the determining unit 802 is further configured to perform any of the following: determining a second signature based on the token carried in the first request, the name of the i-th step operation, and a preset key; determining a second signature based on the source information of the first request, the name of the i-th step operation, and a preset key; determining a second signature based on the token carried in the first request, the source information of the first request, the name of the i-th step operation, and a preset key; wherein the token is used to identify the session of the current login process, and the source information of the first request includes at least one of the source address of the second request and the source device identifier.

[0174] This disclosure provides a login device that establishes relationships between adjacent steps in the login process through signatures. When performing step i-1, a first signature is generated based on the name of step i and a locally cached preset key, specifying the next step. When performing step i, a second signature is recalculated based on the name of this step and the preset key, and compared with the first signature in the request uploaded by the client to verify whether a cross-step request exists. If an attacker skips step i-1 and directly initiates a request targeting step i, they cannot obtain the compliant first signature generated during the execution of step i-1. Furthermore, since the preset key is stored only in a server-specific cache, attackers cannot steal it. Therefore, even if an attacker knows the step name, they cannot forge a valid first signature. This ensures that a lack of a legitimate signature or a forged signature will result in failure to pass verification. In this way, cross-step attacks can be identified, unauthorized logins are avoided, and account security is improved.

[0175] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure.

[0176] It should be noted that the login device provided in the above embodiments is only an example of the division of the above functional units. In actual applications, the above functions can be assigned to different functional units as needed, that is, the internal structure of the device can be divided into different functional units to complete all or part of the functions described above. In addition, the login device and login method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0177] Figure 9 This is a block diagram illustrating an electronic device according to an exemplary embodiment. Typically, the electronic device 900 includes a processor 901 and a memory 902. This electronic device can be implemented as the aforementioned server.

[0178] Processor 901 may include one or more processing cores, such as a quad-core processor, a nine-core processor, etc. Processor 901 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). Processor 901 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, processor 901 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, processor 901 may also include an AI processor for handling computational operations related to machine learning.

[0179] The memory 902 may include one or more computer-readable storage media, which may be non-transitory. The memory 902 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage media in the memory 902 are used to store at least one program code, which is executed by the processor 901 to implement the login method provided in the method embodiments of this disclosure.

[0180] In some embodiments, the electronic device 900 may optionally include a peripheral device interface 903 and at least one peripheral device. The processor 901, memory 902, and peripheral device interface 903 can be connected via a bus or signal line. Each peripheral device can be connected to the peripheral device interface 903 via a bus, signal line, or circuit board. Specifically, the peripheral device includes at least one of the following: a radio frequency circuit 904, a display screen 905, a camera assembly 906, an audio circuit 907, and a power supply 908.

[0181] Peripheral device interface 903 can be used to connect at least one I / O (Input / Output) related peripheral device to processor 901 and memory 902. In some embodiments, processor 901, memory 902 and peripheral device interface 903 are integrated on the same chip or circuit board; in some other embodiments, any one or two of processor 901, memory 902 and peripheral device interface 903 can be implemented on separate chips or circuit boards, which is not limited in this embodiment.

[0182] The radio frequency (RF) circuit 904 is used to receive and transmit RF (Radio Frequency) signals, also known as electromagnetic signals. The RF circuit 904 communicates with communication networks and other communication devices via electromagnetic signals. The RF circuit 904 converts electrical signals into electromagnetic signals for transmission, or converts received electromagnetic signals back into electrical signals. Optionally, the RF circuit 904 includes: an antenna system, an RF transceiver, one or more amplifiers, a tuner, an oscillator, a digital signal processor, a codec chipset, a user identity module card, etc. The RF circuit 904 can communicate with other electronic devices through at least one wireless communication protocol. This wireless communication protocol includes, but is not limited to: metropolitan area networks (MANs), various generations of mobile communication networks (2G, 3G, 4G, and 5G), wireless local area networks (WLANs), and / or WiFi (Wireless Fidelity) networks. In some embodiments, the RF circuit 904 may also include circuitry related to NFC (Near Field Communication), which is not limited in this disclosure.

[0183] Display screen 905 is used to display a UI (User Interface). This UI may include graphics, text, icons, videos, and any combination thereof. When display screen 905 is a touch display screen, it also has the ability to collect touch signals on or above its surface. These touch signals can be input as control signals to processor 901 for processing. In this case, display screen 905 can also be used to provide virtual buttons and / or a virtual keyboard, also known as soft buttons and / or a soft keyboard. In some embodiments, there may be one display screen 905, which serves as the front panel of electronic device 900; in other embodiments, there may be at least two display screens 905, respectively disposed on different surfaces of electronic device 900 or in a folded design; in still other embodiments, display screen 905 may be a flexible display screen, disposed on a curved or folded surface of electronic device 900. Furthermore, display screen 905 may be configured as a non-rectangular irregular shape, i.e., a non-rectangular screen. Display screen 905 may be made of materials such as LCD (Liquid Crystal Display) or OLED (Organic Light-Emitting Diode).

[0184] The camera assembly 906 is used to acquire images or videos. Optionally, the camera assembly 906 includes a front-facing camera and a rear-facing camera. Typically, the front-facing camera is located on the front panel of the electronic device, and the rear-facing camera is located on the back of the electronic device. In some embodiments, there are at least two rear-facing cameras, which are any one of a main camera, a depth-sensing camera, a wide-angle camera, and a telephoto camera, to achieve background blurring by fusion of the main camera and the depth-sensing camera, panoramic shooting by fusion of the main camera and the wide-angle camera, VR (Virtual Reality) shooting, or other fusion shooting functions. In some embodiments, the camera assembly 906 may also include a flash. The flash can be a single-color temperature flash or a dual-color temperature flash. A dual-color temperature flash refers to a combination of a warm light flash and a cool light flash, which can be used for light compensation at different color temperatures.

[0185] The audio circuit 907 may include a microphone and a speaker. The microphone is used to collect sound waves from the user and the environment, converting the sound waves into electrical signals that are input to the processor 901 for processing, or input to the radio frequency circuit 904 for voice communication. For stereo sound acquisition or noise reduction purposes, multiple microphones may be used, each located in a different part of the electronic device 900. The microphone may also be an array microphone or an omnidirectional microphone. The speaker is used to convert the electrical signals from the processor 901 or the radio frequency circuit 904 into sound waves. The speaker may be a conventional diaphragm speaker or a piezoelectric ceramic speaker. When the speaker is a piezoelectric ceramic speaker, it can convert electrical signals not only into audible sound waves but also into inaudible sound waves for purposes such as distance measurement. In some embodiments, the audio circuit 907 may also include a headphone jack.

[0186] Power supply 908 is used to supply power to the various components in electronic device 900. Power supply 908 can be AC ​​power, DC power, a disposable battery, or a rechargeable battery. When power supply 908 includes a rechargeable battery, the rechargeable battery can support wired or wireless charging. The rechargeable battery can also be used to support fast charging technology.

[0187] Those skilled in the art will understand that Figure 9 The structure shown does not constitute a limitation on the electronic device 900, and may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0188] In an exemplary embodiment, a computer-readable storage medium including instructions is also provided, such as a memory 902 including instructions, which can be executed by a processor 901 of an electronic device 900 to complete the above-described login method. Optionally, the computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0189] In an exemplary embodiment, a computer program product is also provided, including a computer program that, when executed by a processor, implements the above-described login method.

[0190] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the following claims.

[0191] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A login method, characterized in that, Applied to a server, the method includes: Receive a first request from the client, the first request being used to perform the i-th step of the login process based on the first signature carried, where i is an integer greater than 1; Based on the name of the i-th step operation and the preset key from the cache space, determine the second signature; Based on the second signature, the first signature is verified to obtain a verification result. The first signature is determined based on the name of the i-1th step operation and the preset key when the server performs the i-1th step operation. If the verification result indicates that the verification has passed, the result corresponding to the first request is sent to the client.

2. The method according to claim 1, characterized in that, The first request carries a token, which is used to identify the session of this login process; The step of verifying the first signature based on the second signature to obtain a verification result includes: If the second signature is the same as the first signature, based on the token and the name of the i-th step operation, query the cache space for a completion flag, which indicates that the signature verification based on the name of the i-th step operation has been completed during this login process; If the completion marker is found, output the first verification result, which indicates that the verification failed. If the completion marker is not found, a second verification result is output, indicating that the verification has passed.

3. The method according to claim 2, characterized in that, The method further includes: If the completion token is not found, the completion token is generated based on the token and the name of the i-th step operation, and the completion token is stored in the cache space.

4. The method according to claim 1, characterized in that, The step of verifying the first signature based on the second signature to obtain a verification result includes: If the second signature is different from the first signature, a first verification result is output, indicating that the verification failed. If the second signature is the same as the first signature, a second verification result is output, indicating that the verification has passed.

5. The method according to claim 1, characterized in that, The method further includes: Based on the name of the (i+1)th step operation and the preset key, a third signature is determined. The third signature is used by the client to generate a second request. The second request is used to perform the (i+1)th step operation in the login process based on the carried third signature.

6. The method according to claim 5, characterized in that, If the i-th step is a scanning operation, then sending the result corresponding to the first request to the client when the verification result indicates that the verification has passed includes: If the coded graphic in the client has been successfully scanned and the verification result indicates that the verification has passed, the scan result and the third signature are sent to the client, the scan result indicating that the coded graphic has been successfully scanned.

7. The method according to claim 1, characterized in that, If the i-th step is a confirmation operation, then sending the result corresponding to the first request to the client when the verification result indicates that the verification has passed includes: If login has been confirmed and the verification result indicates that the verification was successful, a confirmation result and login credentials are sent to the client, whereby the confirmation result indicates that login has been confirmed.

8. The method according to claim 1, characterized in that, If the (i-1)th step is a generation operation, the method further includes: During the execution of the (i-1)th step, a third request is received from the client, the third request being used to request an encoded graphic; Based on the third request, the encoded graphic is generated; The first signature is determined based on the name of the i-th step operation and the preset key; The encoded graphic and the first signature are sent to the client.

9. The method according to claim 8, characterized in that, The method further includes: Based on the third request, a token is generated, which is used to identify the session of this login process; Send the token to the client.

10. The method according to claim 1, characterized in that, The determination of the second signature based on the name of the i-th step operation and the preset key from the cache space includes any one of the following: The second signature is determined based on the token carried in the first request, the name of the operation in the i-th step, and the preset key; Based on the source information of the first request, the name of the operation in the i-th step, and the preset key, the second signature is determined; The second signature is determined based on the token carried in the first request, the source information of the first request, the name of the operation in the i-th step, and the preset key; The token is used to identify the session of this login process, and the source information of the first request includes at least one of the source address and source device identifier of the second request.

11. A login device, characterized in that, Configured on a server, the device includes: The receiving unit is configured to receive a first request from the client, the first request being used to perform the i-th step of the login process based on a first signature carried, where i is an integer greater than 1; The determining unit is configured to perform a second signature based on the name and a preset key from the cache space, according to the i-th step operation. The verification unit is configured to perform verification of the first signature based on the second signature to obtain a verification result. The first signature is determined based on the name of the i-th step operation and the preset key when the server performs the i-1 step operation. The sending unit is configured to send the result corresponding to the first request to the client if the verification result indicates that the verification has passed.

12. An electronic device, characterized in that, The electronic device includes: One or more processors; Memory used to store the executable program code of the processor; The processor is configured to execute the program code to implement the login method as described in any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that, When the instructions in the computer-readable storage medium are executed by the processor of the electronic device, the electronic device is able to perform the login method as described in any one of claims 1 to 10.

14. A computer program product comprising a computer program that, when executed by a processor, implements the login method as described in any one of claims 1 to 10.

Images