Password-free login data processing method and password-free login data processing system

Abstract

This invention relates to a method and system for passwordless login data processing. The method includes: sending a first request to a server for allocating a device ID; receiving and storing the device ID returned from the server; sending a second request to the server for allocating a temporary session token based on the device ID; receiving and storing the temporary session token allocated from the server; and issuing a passwordless login request based on the device ID and the temporary session token. According to this invention, consumers can place orders and make payments using the allocated device ID without registration or login, achieving both convenience and security in payment.

Description

Technical Field

[0001] This invention relates to computer technology, and more specifically to a passwordless login data processing method and a passwordless login data processing system. Background Technology

[0002] With the development of e-commerce, it has become an important part of people's daily lives. People can shop without leaving home using computers or mobile phones, and the prices are cheaper.

[0003] Consumers need to register platform accounts by submitting personal information in order to purchase goods from various platforms. Unbeknownst to them, they may find that they have stored sensitive personal information such as phone numbers, email addresses, and passwords on many platforms, increasing the risk of personal information leakage. In particular, some users use the same usernames and passwords on different websites for ease of remembering, increasing the risk of credential stuffing attacks; a leak of an account password on one platform can lead to the leakage of account passwords on other platforms.

[0004] For consumers, many shopping platforms are used only temporarily or very infrequently, and they may not use them again after making a purchase. Therefore, there is a need to find an online payment solution that allows users to quickly and conveniently complete the shopping payment process without registration or login.

[0005] There are currently two main ways to implement login-free payment solutions:

[0006] When a user clicks to pay, the payment platform's checkout interface is displayed, where the user enters their card number and other information to complete the payment. This login-free payment process is very simple, but it has several problems. First, users cannot view their transaction history; second, others who know the payment link can view their own order information; and third, in scenarios where a single payment link allows multiple people to pay, the user cannot view previous order statuses after closing the browser.

[0007] This browser-cached approach records the user's device ID when they open a payment link. After the user clicks the payment button and is redirected to the checkout, the association between the device ID and the transaction history is recorded. While this solves the problem of users viewing historical transaction records and order status after payment, this solution has significant security vulnerabilities. For example, attackers could obtain the user's device ID through packet sniffing and other methods, allowing them to view all transaction records associated with that device ID. Summary of the Invention

[0008] In view of the above problems, the present invention aims to provide a passwordless login data processing method and system that can complete the subsequent payment process without registration and login and can ensure payment security.

[0009] Furthermore, the present invention also aims to provide a passwordless login data processing method and system that can prevent unauthorized users from requesting to query order status and historical transactions.

[0010] The passwordless login data processing method of one aspect of the present invention is characterized by comprising:

[0011] The parameter initialization step involves sending a first request to the server to request the allocation of a device ID, receiving and storing the device ID returned from the server, wherein the device ID is generated by the server based on the first request and is used to uniquely identify the client;

[0012] The temporary session token request step involves sending a second request to the server for allocating a temporary session token based on the device ID, receiving and storing the temporary session token allocated from the server, wherein the temporary session token is generated by the server based on the second request and the server stores a first correspondence between the temporary session token and the device ID;

[0013] The passwordless login step involves issuing a passwordless login request based on the device ID and the temporary session token.

[0014] Optionally, in the passwordless login request, a third request for obtaining order information is issued based on the device ID and the temporary session token, and order information related to the device ID is received from the server, wherein the server stores a second correspondence between the temporary session token and the order information.

[0015] The following is further included after the passwordless login request:

[0016] In the order payment step, a fourth request for payment is issued based on the temporary session token and the order information, and a payment link created based on the fourth request is received from the server. The server obtains the corresponding order information and generates the payment link according to the first correspondence and the second correspondence.

[0017] Optionally, the following may be included after the order payment step:

[0018] The transaction query step involves issuing a fifth request to query transaction records based on the temporary session token, and receiving the transaction records queried based on the fifth request returned from the server. The server obtains the transaction records related to the device ID corresponding to the temporary session token according to the first correspondence.

[0019] Optionally, the parameter initialization step includes:

[0020] Send a request to the server to obtain the server's public key;

[0021] Receive and store the server-side public key generated by the server in accordance with the request, wherein the server-side public key and the server-side private key corresponding to the server-side public key are stored on the server.

[0022] Generate and store the client public-private key pair and the random key;

[0023] A first request is sent to the server to request the allocation of a device ID. This first request includes the client's public key and a random key encrypted with the server's public key. The server decrypts the random key using its private key, generates a unique device ID to identify the client, encrypts the device ID using the random key, and returns it. Simultaneously, the server stores the mapping between the device ID and the client's public key.

[0024] Receive the device ID returned from the server.

[0025] Optionally, an extraction password can be set for the stored client public / private key pair and random key.

[0026] Optionally, the temporary session token request step includes:

[0027] Generate a temporary session key;

[0028] A second request is sent to the server to obtain a temporary session token. This second request includes: a device ID encrypted using the temporary session key; a signature value digitally signed using the client's private key; and a temporary session key encrypted using the server's public key. The server uses its private key to decrypt and obtain the temporary session key, then uses the temporary session key to decrypt and obtain the device ID. Based on the device ID and the mapping between the device ID and the client's public key stored on the server, the server obtains the corresponding client's public key. The client's public key is used to verify the message signature. If the verification is successful, the server generates a temporary session token and stores the temporary session token and the temporary session key in association with the device ID.

[0029] Receive the temporary session key returned from the server and the signature value of digitally signing the message using the server's private key.

[0030] Optionally, the order payment step includes the following sub-steps:

[0031] A temporary session token is used to send a request to the server to obtain order information. The server obtains the device ID and the order information associated with that device ID based on the received temporary session token.

[0032] Receive order information returned from the server to the client;

[0033] The system sends a payment request to the server, carrying a temporary session token and order information. The server uses the temporary session token to look up the device ID and client public key, then verifies the message signature. If the signature verification is successful, a payment link is created based on the order information.

[0034] Receive the payment link returned from the server.

[0035] The passwordless login data processing system of this invention is characterized by comprising: a mobile terminal and a server.

[0036] The mobile terminal includes:

[0037] The parameter initialization module is used to send a first request to the server to request the allocation of a device ID, and to receive and store the device ID returned from the server.

[0038] The temporary session module sends a second request to the server based on the device ID to request a temporary session token, and receives and stores the temporary session token returned from the server; and

[0039] The payment processing module sends a third request to obtain order information based on the device ID and the temporary session token, sends a fourth request to request payment based on the temporary session token and the order information, and completes the payment processing based on the payment link from the server.

[0040] The server includes:

[0041] The device ID generation module generates a device ID based on the first request and uses it to uniquely identify the client's device ID;

[0042] The token generation module generates a temporary session token based on the second request;

[0043] The transaction processing module, based on the third request to obtain order information, retrieves the order information related to the device ID according to the temporary session token and the ID, and creates a payment link based on the fourth request;

[0044] A database is used to store the device ID and the temporary session token, and to store a first correspondence between the temporary session token and the device ID, and a second correspondence between the temporary session token and the order information.

[0045] Optionally, the database further stores transaction records related to the device ID.

[0046] The mobile terminal further includes:

[0047] The transaction query module, based on the temporary session token, issues a fifth request to query transaction records.

[0048] The transaction processing module further receives the fifth request and queries the database for transaction records related to the device ID.

[0049] An initialization module of one aspect of the present invention is used to send a first request to the server for requesting the allocation of a device ID, and to receive and store the device ID returned from the server;

[0050] The temporary session module sends a second request to the server based on the device ID to obtain a temporary session token, and receives and stores the temporary session token returned from the server; and

[0051] The payment processing module issues a third request to obtain order information based on the device ID and the temporary session token, issues a fourth request to request payment based on the temporary session token and the order information, and completes the payment processing based on the payment link from the server.

[0052] Optionally, the mobile terminal further includes:

[0053] The transaction query module issues a fifth request for querying transaction records based on the temporary session token.

[0054] Optionally, the parameter initialization module performs the following actions:

[0055] Send a request to the server to obtain the server's public key;

[0056] Receive and store the server-side public key generated by the server in response to the request.

[0057] Generate and store the client public-private key pair and the random key;

[0058] A first request is sent to the server to request the allocation of a device ID. This first request includes the client's public key and a random key encrypted with the server's public key. The server decrypts the random key using its private key, generates a unique device ID, encrypts the device ID using the random key, and returns it to the client. Simultaneously, the server stores the mapping between device IDs and the client's public key.

[0059] Receive the device ID returned from the server.

[0060] Optionally, the parameter initialization module sets an extraction password for the stored client public / private key pair and random key.

[0061] Optionally, the temporary session token request module performs the following actions:

[0062] Generate a temporary session key;

[0063] A second request is sent to the server to obtain a temporary session token. This second request includes: a device ID encrypted using the temporary session key; a signature value digitally signed using the client's private key; and a temporary session key encrypted using the server's public key. The server uses its private key to decrypt and obtain the temporary session key, then uses the temporary session key to decrypt and obtain the device ID. Based on the device ID and the mapping between the device ID and the client's public key stored on the server, the server obtains the corresponding client's public key. The client's public key is used to verify the message signature. If the verification is successful, the server generates a temporary session token and stores the temporary session token and the temporary session key in association with the device ID.

[0064] Receive the temporary session key returned from the server and the signature value of digitally signing the message using the server's private key.

[0065] A server according to one aspect of the present invention is characterized in that it comprises:

[0066] The device ID generation module generates a device ID based on the first request and uses it to uniquely identify the client's device ID;

[0067] The token generation module generates a temporary session token based on the second request;

[0068] The transaction processing module, based on the third request to obtain order information, retrieves the order information related to the device ID according to the temporary session token and the ID, and creates a payment link based on the fourth request;

[0069] A database is used to store the device ID and the temporary session token, and to store a first correspondence between the temporary session token and the device ID, and a second correspondence between the temporary session token and the order information.

[0070] Optionally, the database further stores transaction records related to the device ID.

[0071] The transaction processing module further receives a fifth request and queries the database for transaction records related to the device ID.

[0072] A computer-readable medium of one aspect of the present invention, having a computer program stored thereon, is characterized in that,

[0073] When the computer program is executed by the processor, it implements the passwordless login data processing method described above.

[0074] A computer device according to one aspect of the present invention includes a storage module, a processor, and a computer program stored on the storage module and executable on the processor, characterized in that the processor executes the computer program to implement the passwordless login data processing method.

[0075] As described above, according to the passwordless login data processing method and system of the present invention, consumers can place orders and make payments without registering or logging in after entering the online store. They only need to use the device ID to query order information, make payments, and check transactions, making the entire shopping experience convenient and secure. Furthermore, since users do not need to retain personal account passwords or other information, they do not need to worry about their personal information being leaked or misused by the platform. Moreover, in this invention, through encryption and signature technologies, the risk of transmitted data being intercepted, tampered with, or impersonated by others can be effectively prevented, ensuring the security of user data.

[0076] A computer-readable medium of the present invention stores a computer program thereon, characterized in that the computer program, when executed by a processor, implements the passwordless login data processing method described above.

[0077] A computer device according to one aspect of the present invention includes a storage module, a processor, and a computer program stored on the storage module and executable on the processor, characterized in that the processor executes the computer program to implement the passwordless login data processing method. Attached Figure Description

[0078] Figure 1 This is a flowchart illustrating the passwordless login data processing method of the present invention.

[0079] Figure 2 This is a flowchart illustrating the initialization of system parameters in a specific implementation.

[0080] Figure 3 This is a flowchart illustrating the payment process in a specific implementation.

[0081] Figure 4 This is a flowchart illustrating the process of querying historical records in a specific implementation.

[0082] Figure 5 This is a structural block diagram illustrating the passwordless login data processing system of the present invention. Detailed Implementation

[0083] The following are some embodiments of the present invention, intended to provide a basic understanding of the invention. They are not intended to identify key or decisive elements of the invention or to limit the scope of protection sought.

[0084] For purposes of brevity and illustrativeness, the principles of the invention are described herein primarily with reference to exemplary embodiments thereof. However, those skilled in the art will readily recognize that the same principles are equivalently applicable to all types of passwordless login data processing methods and systems, and that these same principles can be implemented therein, with any such variations not departing from the true spirit and scope of this patent application.

[0085] Furthermore, reference is made in the following description to the accompanying drawings, which illustrate specific exemplary embodiments. Electrical, mechanical, logical, and structural modifications may be made to these embodiments without departing from the spirit and scope of the invention. Moreover, while features of the invention are disclosed in conjunction with only one of several embodiments, this feature may be combined with one or more other features of other embodiments if desired and / or advantageous for any given or identifiable function. Therefore, the following description should not be considered limiting in any sense, and the scope of the invention is defined by the appended claims and their equivalents.

[0086] Terms such as “possessing” and “comprising” indicate that, in addition to having units (modules) and steps that are directly and explicitly stated in the specification and claims, the technical solution of the present invention does not exclude the presence of other units (modules) and steps that are not directly or explicitly stated.

[0087] The following describes some of the technical terms that will appear in this invention.

[0088] (1) No login required: Users can use all functions without registering an account on the platform, reducing the risk of leakage of users' personal information.

[0089] (2) Digital signature: This is data attached to a data unit, or a cryptographic transformation of the data unit. This data or transformation allows the recipient of the data unit to verify the source and integrity of the data unit and protect the data from forgery by others (e.g., the recipient).

[0090] (3) RSA: It is an asymmetric encryption algorithm that is widely used in public key encryption and e-commerce.

[0091] (4) AES: It is currently the most popular symmetric encryption algorithm, also known as Advanced Encryption Standard. It is a block encryption standard adopted by the U.S. federal government.

[0092] (5) Extract password: Decrypt the key stored on the client side for sensitive data.

[0093] First, the passwordless login data processing method of the present invention will be described.

[0094] Figure 1 This is a flowchart illustrating the passwordless login data processing method of the present invention.

[0095] like Figure 1 As shown, the passwordless login data processing method of the present invention is characterized by comprising:

[0096] Parameter initialization step S100: Send a first request to the server to request the allocation of a device ID, receive and store the device ID returned from the server, wherein the device ID is generated by the server based on the first request and is used to uniquely identify the client;

[0097] Temporary Session Token Request Step S200: A second request for allocating a temporary session token is sent to the server based on the device ID; the temporary session token allocated from the server is received and stored; wherein the temporary session token is generated by the server based on the second request, and the server stores a first correspondence between the temporary session token and the device ID; and

[0098] Passwordless login request step S300: Send a passwordless login request based on the device ID and the temporary session token.

[0099] This example illustrates a scenario where passwordless login is used for order payment. Specifically, the passwordless login request step S300 includes: a third request to obtain order information, receiving order information related to the device ID returned from the server, wherein the server stores a second correspondence between a temporary session token and the order information.

[0100] The following step after the passwordless login request step S300 is (not shown):

[0101] Order payment steps: Based on the temporary session token and the order information, a fourth request for payment is issued, and a payment link created based on the fourth request is received from the server. The server obtains the corresponding order information and generates the payment link according to the first correspondence and the second correspondence.

[0102] Optionally, following the order payment step, the following may further be included (not shown):

[0103] The transaction query step involves issuing a fifth request to query transaction records based on the temporary session token, and receiving the transaction records queried based on the fifth request returned from the server. The server obtains the transaction records related to the device ID corresponding to the temporary session token according to the first correspondence.

[0104] Next, a specific embodiment of the passwordless login data processing method of the present invention will be described.

[0105] As an example of applying the passwordless login data processing method of the present invention to the payment scenario, the processing can be roughly divided into four parts: (1) initialization of system parameters, (2) temporary session token acquisition process and payment process, and (3) querying of historical records.

[0106] The following is a detailed explanation of each part.

[0107] (1) Initialize system parameters

[0108] The main purpose of initializing system parameters is to generate a unique identifier (device ID) for the current client and to generate a public-private key pair for the client. The client needs to use an encryption algorithm to encrypt the device ID and private key and store them on the client. The next time the user opens the client, it first checks if the device ID exists. If it exists, it is used directly; otherwise, the initialization process of system parameters is re-executed.

[0109] In this invention, the proposed device ID uniquely identifies the client. The device ID is used by the server (backend) to determine if it belongs to the same user. When a consumer makes a payment, the backend associates the device ID with the transaction information. The next time the user queries transaction records, they retrieve the associated transaction record based on the device ID. The public-private key pair generated on the client is used to sign and verify request messages, facilitating the server's identification of the request source and ensuring that the device ID cannot be misused.

[0110] Figure 2 This is a flowchart illustrating the initialization of system parameters in a specific implementation.

[0111] like Figure 2 As shown, the process for initializing system parameters includes:

[0112] S1: When a consumer opens any page on the front end, check whether the system parameters are initialized (whether there is device ID and other information). If the system parameters are not initialized, proceed with the following steps to initialize the system parameters.

[0113] S2: The client sends a request to the server to obtain the server's public key;

[0114] S3: The server returns the server-side public key (s_pub_key) according to the request. The client keeps the server-side public key, which is used for subsequent encryption of sensitive information. The server can generate the server-side public key and server-side private key according to the request, or the server can have generated and stored the server-side public key and server-side private key in advance.

[0115] S4: The client uses a specified algorithm to generate a client public-private key pair (client private key: c_pri_key and client public key: c_pub_key) and a random key, and encrypts and stores them on the client using a client plugin or SDK. In addition, as a preferred example, considering the risk that the client encryption algorithm may be cracked, an extraction password can be set, and it can be set so that only by entering the extraction password can the client public-private key pair (c_pri_key, c_pub_key) and the random key be obtained in the subsequent process.

[0116] S5: The client sends its client public key (c_pub_key) and a random key encrypted with the server's public key (s_pub_key) to the server to request the device ID. Here, the encryption method can be, for example, RSA.

[0117] S6: The server uses the stored server-side private key (s_pri_key) to decrypt and obtain a random key, and generates a device ID to uniquely identify the client. The server uses the random key to encrypt the device ID and returns it to the client. At the same time, the server stores information such as the device ID and the client's public key (c_pub_key) in its database, and at least stores the correspondence between the device ID and the client's public key (c_pub_key).

[0118] After receiving the device ID, the client encrypts and stores it on the client using a client plugin or SDK (obfuscation algorithms can be used when packaging the client code). Encrypting and storing the device ID can prevent it from being stolen by others.

[0119] Thus, the system parameter initialization is now complete. The next time the client is opened, it will first check if the device ID exists. If it does, there is no need to repeat the above operations.

[0120] (2) Temporary session token acquisition and payment process

[0121] Figure 3 This is a flowchart illustrating the payment process in a specific implementation.

[0122] like Figure 3 As shown, the payment process in one specific implementation includes:

[0123] S11: The consumer opens the order page or any other interface in the client;

[0124] S12: The client checks whether the system parameters are initialized. If they are not initialized, the system parameters are initialized (i.e., the process of initializing system parameters as described in (1) above is executed). If the system parameters have been initialized, the following operation is performed: the client checks whether a temporary session token already exists. If not, the operation of S13~S15 is executed.

[0125] S13: The client generates a temporary session key;

[0126] S14: The client sends a request for a temporary session to the server. The request parameters include: the device ID encrypted with the temporary session key, the message digitally signed using RSASHA256, and the temporary session key encrypted using RSA. The client's private key (c_pri_key) required for the digital signature and the server's public key (s_pub_key) required for RSA encryption are stored on the client during system parameter initialization. The encryption algorithm for the device ID can be, for example, AES. Alternatively, if an extraction password was set during system parameter initialization, this password must be entered here to retrieve the client's private key (c_pri_key) and device ID stored on the client.

[0127] S15: After receiving the message, the server uses the server-side public key (s_pri_key) to decrypt and obtain the temporary session key. Then, it uses the temporary session key to decrypt and obtain the device ID. Next, it looks up the client public key (c_pub_key) corresponding to the device ID according to the correspondence between the device ID and the client public key (c_pub_key) stored in the device ID database. Finally, it uses the client public key (c_pub_key) to verify the message signature. If all of these steps are completed normally, it means that the message is legitimate. The server then generates a temporary session token and returns it to the client. At the same time, the server caches the temporary session token and the temporary session key, and associates them with the device ID. On the other hand, the client also encrypts and caches the temporary session token and the temporary session key.

[0128] S16: After receiving the temporary session token, the client uses the temporary session token to send a request to the server to obtain order information;

[0129] S17: The server obtains the device ID based on the received temporary session token and returns the order information related to that device ID to the client;

[0130] S18: The consumer clicks the payment button;

[0131] S19: The client sends a payment request to the server, carrying a temporary session token and order information;

[0132] S20: The server looks up the device ID and client public key (c_pub_key) based on the temporary session token. Then, it verifies the message signature using the found client public key. If the verification is successful, it creates a payment link based on the order information and records the relationship between the device ID and the order.

[0133] S21: The server returns a payment link (e.g., the cashier URL) to the client;

[0134] S22: The client is redirected to the cashier page of the third-party payment platform to complete the subsequent payment process.

[0135] (3) Querying historical records.

[0136] Figure 4 This is a flowchart illustrating the process of querying historical records in a specific implementation.

[0137] like Figure 4 As shown, the process of querying historical records in one specific implementation includes:

[0138] S31: When a consumer opens the transaction record page or any other front-end interface, check whether the system parameters are initialized. If they are not initialized, initialize the system parameters. If they are initialized, perform the following operation.

[0139] S32: The client checks whether a temporary session token already exists on the front end. If not, it executes steps S33 to S35.

[0140] S33: The client generates a temporary session key;

[0141] S34: The client sends a request for a temporary session to the server. The request parameters include: a device ID encrypted with a random key, a message digitally signed using RSASHA256, and a temporary session key encrypted using RSA. The client's private key (c_pri_key) required for the digital signature and the server's public key (s_pub_key) required for RSA encryption are stored on the client during system parameter initialization. The encryption algorithm for the device ID can be, for example, AES. Alternatively, if an extraction password was set during system parameter initialization, this password must be entered here to retrieve the client's private key (c_pri_key) and device ID stored on the client.

[0142] S35: After receiving the message, the server uses its private key (s_pri_key) to decrypt and obtain the temporary session key. Then, it uses the temporary session key to decrypt and obtain the device ID. Next, it uses the device ID to look up the corresponding client public key (c_pub_key) in the database (based on the mapping between device IDs and client public keys (c_pub_key)). Finally, it uses the client public key (c_pub_key) to verify the message. If all of these steps are completed successfully, the message is considered valid. The server then generates a temporary session token and returns it to the client. At the same time, the server caches the temporary session token and temporary session key, and associates them with the device ID. Meanwhile, the client also encrypts and caches the temporary session token and temporary session key.

[0143] S36: The client sends a request to the server with a temporary session token to retrieve historical transaction records;

[0144] S37: After receiving the request, the server obtains the device ID and the corresponding client public key (c_pub_key) based on the temporary session token, and then uses the client public key (c_pub_key) to verify the signature of the message to ensure the legitimacy of the data source. If the request is legitimate, the server returns the transaction record corresponding to the device ID.

[0145] The above describes the passwordless login data processing method of the present invention. Next, the passwordless login data processing system of the present invention will be described.

[0146] Figure 5 This is a structural block diagram illustrating the passwordless login data processing system of the present invention.

[0147] like Figure 5 As shown, the passwordless login data processing system includes: a mobile terminal 100 and a server 200.

[0148] The mobile terminal 100 includes:

[0149] The parameter initialization module 110 is used to send a first request to the server for requesting the allocation of a device ID, and to receive and store the device ID returned from the server.

[0150] Temporary session module 120 sends a second request to the server for a temporary session token based on the device ID, and receives and stores the temporary session token returned from the server; and

[0151] The payment processing module 130 issues a third request to obtain order information based on the device ID and the temporary session token, issues a fourth request to request payment based on the temporary session token and the order information, and completes the payment processing based on the payment link from the server.

[0152] Server 200 includes:

[0153] Device ID generation module 210 generates a device ID based on the first request and uses it to uniquely identify the client's device ID;

[0154] Token generation module 220 generates a temporary session token based on the second request;

[0155] Transaction processing module 230, based on the third request to obtain order information, retrieves order information related to device ID according to the temporary session token and the ID, and creates a payment link based on the fourth request;

[0156] Database 240 is used to store the device ID and the temporary session token, and to store a first correspondence between the temporary session token and the device ID, and a second correspondence between the temporary session token and the order information.

[0157] Furthermore, database 240 also stores transaction records of related device IDs.

[0158] The mobile terminal 100 further includes a transaction query module 240, which issues a fifth request for querying transaction records based on the temporary session token.

[0159] The transaction processing module 230 is also configured to further receive the fifth request and query the database for transaction records related to the device ID.

[0160] The parameter initialization module 110 performs the following actions:

[0161] Send a request to the server to obtain the server's public key;

[0162] Receive and store the server-side public key generated by the server in response to the request.

[0163] Generate and store the client public-private key pair and the random key;

[0164] A first request is sent to the server to request the allocation of a device ID. This first request includes the client's public key and a random key encrypted with the server's public key. The server decrypts the random key using its private key, generates a unique device ID, encrypts the device ID using the random key, and returns it to the client. Simultaneously, the server stores the mapping between device IDs and the client's public key.

[0165] Receive the device ID returned from the server.

[0166] Furthermore, the parameter initialization module 110 sets an extraction password for the stored client public / private key pair and random key.

[0167] Temporary Session Token Request Module 120 performs the following actions:

[0168] Generate a temporary session key;

[0169] A second request is sent to the server to obtain a temporary session token. This second request includes: a device ID encrypted using the temporary session key, a message digitally signed using the client's private key, and a temporary session key encrypted using the server's public key. The server uses its private key to decrypt and obtain the temporary session key, then uses the temporary session key to decrypt and obtain the device ID. Based on the device ID and the mapping between the device ID and the client's public key stored on the server, the server obtains the corresponding client's public key. The client's public key is used to verify the signed message. If the verification is successful, the server generates a temporary session token and stores the temporary session token and the temporary session key in association with the device ID.

[0170] Receive the temporary session key returned from the server.

[0171] As described above, according to the passwordless login data processing method and system of the present invention, consumers can place orders and make payments without registering or logging in after entering the online store. They only need to use the device ID to query order information, make payments, and check transactions, making the entire shopping experience convenient and secure. Furthermore, since users do not need to retain personal account passwords or other information, they do not need to worry about their personal information being leaked or misused by the platform. Moreover, in this invention, through encryption and signature technologies, the risk of transmitted data being intercepted, tampered with, or impersonated by others can be effectively prevented, ensuring the security of user data.

[0172] The present invention also provides a computer-readable medium having a computer program stored thereon, characterized in that the computer program, when executed by a processor, implements the above-described passwordless login data processing method.

[0173] The present invention also provides a computer device, including a storage module, a processor, and a computer program stored on the storage module and executable on the processor, characterized in that the processor executes the computer program to implement the above-described passwordless login data processing method.

[0174] The above examples primarily illustrate the passwordless login data processing method and system of the present invention. Although only some specific embodiments of the present invention have been described, those skilled in the art should understand that the present invention can be implemented in many other forms without departing from its spirit and scope. Therefore, the examples and embodiments shown are considered illustrative rather than restrictive, and the present invention may cover various modifications and substitutions without departing from the spirit and scope of the invention as defined by the appended claims.

Claims

1. A method for processing passwordless login data, characterized in that, include: The parameter initialization step involves sending a first request to the server to request the allocation of a device ID, receiving and storing the device ID returned from the server, wherein the device ID is generated by the server based on the first request and is used to uniquely identify the client; The temporary session token request step involves sending a second request to the server for allocating a temporary session token based on the device ID, receiving and storing the temporary session token allocated from the server, wherein the temporary session token is generated by the server based on the second request and the server stores a first correspondence between the temporary session token and the device ID; The passwordless login process involves issuing a passwordless login request based on the device ID and the temporary session token. In the passwordless login request, a third request for obtaining order information is issued based on the device ID and the temporary session token. Order information related to the device ID is received from the server. The server stores a second correspondence between the temporary session token and the order information. The following is further included after the passwordless login request: In the order payment step, a fourth request for payment is issued based on the temporary session token and the order information, and a payment link created based on the fourth request is received from the server. The server obtains the corresponding order information and generates the payment link according to the first correspondence and the second correspondence.

2. The passwordless login data processing method as described in claim 1, characterized in that, The following steps are further included after the order payment step: The transaction query step involves issuing a fifth request to query transaction records based on the temporary session token, and receiving the transaction records queried based on the fifth request returned from the server. The server obtains the transaction records related to the device ID corresponding to the temporary session token according to the first correspondence.

3. The passwordless login data processing method as described in claim 1, characterized in that, The parameter initialization steps include: Send a request to the server to obtain the server's public key; Receive and store the server-side public key generated by the server in accordance with the request, wherein the server-side public key and the server-side private key corresponding to the server-side public key are stored on the server. Generate and store the client public-private key pair and the random key; A first request is sent to the server to request the allocation of a device ID. This first request includes the client's public key and a random key encrypted with the server's public key. The server decrypts the random key using its private key, generates a unique device ID to identify the client, encrypts the device ID using the random key, and returns it. Simultaneously, the server stores the mapping between the device ID and the client's public key. Receive the device ID returned from the server.

4. The passwordless login data processing method as described in claim 3, characterized in that, Set an extraction password for the stored client public / private key pair and random key.

5. The passwordless login data processing method as described in claim 3, characterized in that, The temporary session token request step includes: Generate a temporary session key; A second request is sent to the server to obtain a temporary session token. This second request includes: a device ID encrypted using the temporary session key; a signature value digitally signed using the client's private key; and a temporary session key encrypted using the server's public key. The server uses its private key to decrypt and obtain the temporary session key, then uses the temporary session key to decrypt and obtain the device ID. Based on the device ID and the mapping between the device ID and the client's public key stored on the server, the server obtains the corresponding client's public key. The client's public key is used to verify the message signature. If the verification is successful, the server generates a temporary session token and stores the temporary session token and the temporary session key in association with the device ID. Receive the temporary session key returned from the server and the signature value of digitally signing the message using the server's private key.

6. The passwordless login data processing method as described in claim 5, characterized in that, The order payment process includes the following sub-steps: A temporary session token is used to send a request to the server to obtain order information. The server obtains the device ID and the order information associated with that device ID based on the received temporary session token. Receive order information returned from the server to the client; The system sends a payment request to the server, carrying a temporary session token and order information. The server uses the temporary session token to look up the device ID and client public key, then verifies the message signature. If the signature verification is successful, a payment link is created based on the order information. Receive the payment link returned from the server.

7. A passwordless login data processing system, characterized in that, include: Mobile terminals and servers, The mobile terminal includes: The parameter initialization module is used to send a first request to the server to request the allocation of a device ID, and to receive and store the device ID returned from the server. The temporary session module sends a second request to the server based on the device ID to request a temporary session token, and receives and stores the temporary session token returned from the server; and The payment processing module sends a third request to obtain order information based on the device ID and the temporary session token, sends a fourth request to request payment based on the temporary session token and the order information, and completes the payment processing based on the payment link from the server. The server includes: The device ID generation module generates a device ID based on the first request and uses it to uniquely identify the client's device ID; The token generation module generates a temporary session token based on the second request; The transaction processing module, based on the third request to obtain order information, retrieves the order information related to the device ID according to the temporary session token and the ID, and creates a payment link based on the fourth request; A database is used to store the device ID and the temporary session token, and to store a first correspondence between the temporary session token and the device ID, and a second correspondence between the temporary session token and the order information.

8. The passwordless login data processing system as described in claim 7, characterized in that, The database further stores transaction records related to the device IDs. The mobile terminal further includes: The transaction query module, based on the temporary session token, issues a fifth request to query transaction records. The transaction processing module further receives the fifth request and queries the database for transaction records related to the device ID.

9. A computer-readable medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the passwordless login data processing method according to any one of claims 1 to 6.

10. A computer device, comprising a storage module, a processor, and a computer program stored on the storage module and executable on the processor, characterized in that, When the processor executes the computer program, it implements the passwordless login data processing method according to any one of claims 1 to 6.

Images