Login state synchronization method and apparatus, electronic device, and readable storage medium

Abstract

Embodiments of the present application provide a login state synchronization method and device, electronic equipment and readable storage medium. The login state synchronization method comprises: obtaining first identification ciphertext; the first identification ciphertext is obtained by encrypting first identification plaintext for identifying the non-logged-in end based on a first encryption key; the first identification ciphertext is decrypted by a first decryption key corresponding to the first encryption key to obtain the first identification plaintext; the first identification plaintext is sent to a login server, so that the login server obtains a target account logged in by the logged-in end and generates a login credential carrying the target account under the condition that the identity of the non-logged-in end is determined to be legal according to the first identification plaintext, and sends the login credential to the non-logged-in end, so that the non-logged-in end logs in the target account based on the login credential. The present embodiment can realize safe synchronization of login state and prevent leakage of login information such as login credential.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to login status synchronization methods, apparatus, electronic devices, and readable storage media. Background Technology

[0002] Some multimedia software can exist in multiple deployment forms; for example, the deployment form can include a web page (Personal Computer Webpage, PCW) and a client (Personal Computer Application, PCA); users can open multimedia software through PCW and PCA.

[0003] In related technologies, PCA can open a proxy service locally. Based on the proxy service, after a user logs in to PCA, if PCW is opened, PCW can send an access request to PCA. PCA returns login credentials to PCW based on the access request. PCW can then automatically log in based on the received login information.

[0004] However, the methods of these technologies pose a risk that unauthorized users, such as those accessing third-party websites, could steal login credentials and log in via PCA, leading to data security and user privacy breaches. Summary of the Invention

[0005] The purpose of this invention is to provide a login status synchronization method, apparatus, electronic device, and readable storage medium to address the risk of data security and user privacy leaks caused by unauthorized access from third-party websites or other unauthorized users stealing login credentials and logging in via PCA. The specific technical solution is as follows: In a first aspect of this invention, a login status synchronization method is provided, applied to a backend server. The method includes: obtaining a first identifier ciphertext; the first identifier ciphertext being obtained by encrypting a first identifier plaintext used to identify the unlogged-in terminal using a first encryption key; decrypting the first identifier ciphertext using a first decryption key corresponding to the first encryption key to obtain the first identifier plaintext; and sending the first identifier plaintext to a login server, so that the login server, upon determining the legitimacy of the unlogged-in terminal's identity based on the first identifier plaintext, obtains the target account logged in by the logged-in terminal, generates a login credential carrying the target account, and sends the login credential to the unlogged-in terminal, so that the unlogged-in terminal can log in to the target account based on the login credential.

[0006] In some embodiments of this application, the method further includes: obtaining a second identifier plaintext for identifying the logged-in terminal; the step of sending the first identifier plaintext to a login server so that the login server, based on the first identifier plaintext, determines that the identity of the unlogged-in terminal is legitimate, and obtains the target account logged in by the logged-in terminal, includes: sending the first identifier plaintext and the second identifier plaintext to the login server so that the login server, based on the first identifier plaintext, determines that the identity of the unlogged-in terminal is legitimate, and based on the second identifier plaintext, determines that the login status of the logged-in terminal is legitimate, and obtains the target account logged in by the logged-in terminal.

[0007] In some embodiments of this application, the step of sending the first and second plaintext identifiers to the login server, so that the login server can determine the legitimacy of the unlogged-in client based on the first plaintext identifier and the legitimacy of the logged-in client based on the second plaintext identifier, and then obtain the target account logged in by the logged-in client, includes: sending the first and second plaintext identifiers to the login server, so that the login server can establish and store an association between the first and second plaintext identifiers, and send an operation key to the backend server, when the login server determines the legitimacy of the unlogged-in client based on the first plaintext identifier and the legitimacy of the logged-in client based on the second plaintext identifier; returning the operation key and the first plaintext identifier to the login server, so that the login server can obtain the second plaintext identifier based on the association and the first plaintext identifier returned by the backend server, and obtain the target account logged in by the logged-in client based on the second plaintext identifier, when the login server determines that the backend server has returned the operation key within a preset time period.

[0008] In some embodiments of this application, obtaining the second identifier plaintext used to identify the logged-in terminal includes: obtaining the second identifier ciphertext; the second identifier ciphertext is obtained by the logged-in terminal encrypting the second identifier plaintext used to identify the logged-in terminal based on the second encryption key; and the second identifier ciphertext is decrypted using the second decryption key corresponding to the second encryption key to obtain the second identifier plaintext used to identify the logged-in terminal.

[0009] In some embodiments of this application, the method further includes: upon receiving a first key request from the unlogged-in terminal and successfully authenticating the unlogged-in terminal, obtaining a first key pair, sending a first encryption key from the first key pair to the unlogged-in terminal, and storing a first decryption key from the first key pair; upon receiving a second key request from the logged-in terminal and successfully authenticating the logged-in terminal, obtaining a second key pair, sending a second encryption key from the second key pair to the logged-in terminal, and storing a second decryption key from the second key pair.

[0010] In some embodiments of this application, the first identifier ciphertext is obtained by the unlogged-in terminal sending a login status query request to the logged-in terminal, and when the logged-in terminal reports that the login status of the logged-in terminal is logged in, the unlogged-in terminal encrypts the first identifier plaintext based on the first encryption key.

[0011] In a second aspect of this invention, a login status synchronization method is also provided, applied to a login server, comprising: obtaining a first identifier plaintext sent by a backend server; obtaining a first identifier ciphertext from the backend server and decrypting the first identifier ciphertext using a first decryption key; encrypting the first identifier plaintext used to identify the unlogged-in terminal using a first encryption key corresponding to the first decryption key; if the identity of the unlogged-in terminal is determined to be legitimate based on the first identifier plaintext, obtaining the target account logged in by the logged-in terminal and generating a login credential carrying the target account; and sending the login credential to the unlogged-in terminal so that the unlogged-in terminal can log in to the target account based on the login credential.

[0012] In some embodiments of this application, the step of obtaining the target account logged in by the logged-in terminal when the identity of the unlogged-in terminal is determined to be legitimate based on the first identifier plaintext includes: obtaining the second identifier plaintext sent by the backend server; the second identifier plaintext is used to identify the logged-in terminal; and obtaining the target account logged in by the logged-in terminal when the identity of the unlogged-in terminal is determined to be legitimate based on the first identifier plaintext and the login status of the logged-in terminal is determined to be legitimate based on the second identifier plaintext.

[0013] In some embodiments of this application, the step of obtaining the target account logged in by the logged-in terminal after determining that the identity of the unlogged-in terminal is legitimate based on the first identifier plaintext and the login status of the logged-in terminal is legitimate based on the second identifier plaintext includes: establishing and storing an association between the first identifier plaintext and the second identifier plaintext after determining that the identity of the unlogged-in terminal is legitimate based on the first identifier plaintext and the login status of the logged-in terminal is legitimate based on the second identifier plaintext; sending an operation key to the backend server and receiving the operation key and the first identifier plaintext returned by the backend server; obtaining the second identifier plaintext based on the association and the first identifier plaintext returned by the backend server after determining that the backend server returns the operation key within a preset time period; and obtaining the target account logged in by the logged-in terminal based on the second identifier plaintext.

[0014] In some embodiments of this application, the method further includes: storing the operation key in a preset storage space by time-limited deletion; the time-limited deletion includes: deleting the operation key in the preset storage space if the storage time exceeds a preset time; and determining that the backend server will return the operation key within a preset time after receiving the operation key returned by the backend server, if the operation key is found to be stored in the preset storage space.

[0015] In a third aspect of this invention, a login status synchronization system is also provided, including an unlogged-in client, a logged-in client, a backend server, and a login server; the unlogged-in client is configured to encrypt a first identifier plaintext for identifying the unlogged-in client based on a first encryption key, to obtain a first identifier ciphertext; the backend server is configured to obtain the first identifier ciphertext, and decrypt the first identifier ciphertext using a first decryption key corresponding to the first encryption key, to obtain the first identifier plaintext, and send the first identifier plaintext to the login server; the login server is configured to, if the identity of the unlogged-in client is determined to be legitimate based on the first identifier plaintext, obtain the target account logged in by the logged-in client, generate a login credential carrying the target account, and send the login credential to the unlogged-in client; the unlogged-in client is further configured to log in to the target account based on the login credential.

[0016] In a fourth aspect of this invention, a login status synchronization device is also provided, applied to a backend server. The device includes: a first acquisition module, configured to acquire a first identifier ciphertext; the first identifier ciphertext is obtained by encrypting a first identifier plaintext used to identify the unlogged-in terminal based on a first encryption key; a first decryption module, configured to decrypt the first identifier ciphertext using a first decryption key corresponding to the first encryption key to obtain the first identifier plaintext; and a first sending module, configured to send the first identifier plaintext to a login server, so that the login server, upon determining the legitimacy of the unlogged-in terminal's identity based on the first identifier plaintext, acquires the target account logged in by the logged-in terminal, generates a login credential carrying the target account, and sends the login credential to the unlogged-in terminal, so that the unlogged-in terminal can log in to the target account based on the login credential.

[0017] In a fifth aspect of this invention, a login status synchronization device is provided, applied to a login server. The device includes: a second acquisition module, configured to acquire a first identifier plaintext sent by a backend server; the first identifier plaintext is obtained by the backend server acquiring a first identifier ciphertext and decrypting the first identifier ciphertext using a first decryption key; the first identifier ciphertext is obtained by an unlogged-in terminal encrypting the first identifier plaintext used to identify the unlogged-in terminal using a first encryption key corresponding to the first decryption key; a login credential generation module, configured to, when determining the legitimacy of the unlogged-in terminal's identity based on the first identifier plaintext, acquire the target account logged in by the logged-in terminal and generate a login credential carrying the target account; and a second sending module, configured to send the login credential to the unlogged-in terminal so that the unlogged-in terminal can log in to the target account based on the login credential.

[0018] In a sixth aspect of the present invention, an electronic device is also provided, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; the memory is used to store computer programs; and the processor is used to implement the steps of the method described in either the first aspect or the second aspect when executing the program stored in the memory.

[0019] In a seventh aspect of the invention, a computer-readable storage medium is also provided, wherein a computer program is stored therein, and when executed by a processor, the computer program implements the steps of the method as described in either the first or second aspect.

[0020] In an eighth aspect of the invention, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute any of the login status synchronization methods described above.

[0021] In this embodiment, the first identifier ciphertext is obtained by encrypting the first identifier plaintext used to identify the unlogged-in terminal using the first encryption key. The backend server decrypts the first identifier ciphertext using the first decryption key corresponding to the first encryption key to obtain the first identifier plaintext. Only when the unlogged-in terminal is legitimate will it know the first encryption key corresponding to the first decryption key and use it to encrypt the first identifier plaintext to obtain the first identifier ciphertext. Correspondingly, the backend server can then decrypt the first identifier ciphertext using the first decryption key to obtain the correct first identifier plaintext. The login server can then determine the legitimacy of the unlogged-in terminal based on the correct first identifier plaintext, thereby obtaining the target account logged in by the logged-in terminal and generating login credentials carrying the target account. Only then can the unlogged-in terminal log in to the target account using the login credentials, achieving synchronization of the login status between the logged-in and unlogged-in terminals. Unauthorized devices do not know the first encryption key corresponding to the first decryption key, and therefore cannot use the first encryption key to encrypt the first identifier plaintext, thus failing to obtain the first identifier ciphertext that can be decrypted by the first decryption key. In other words, even if an unauthorized device obtains the plaintext of the first identifier, because it does not know the correct first encryption key, it cannot obtain the ciphertext of the first identifier that can be decrypted using the first decryption key. Therefore, when it sends the encrypted ciphertext to the backend server, the backend server cannot decrypt it using the first decryption key and obtain the correct decryption result (i.e., the plaintext of the first identifier). The backend server only receives an incorrect decryption result. After the backend server sends the incorrect decryption result to the login server, the login server, based on the incorrect decryption result, cannot pass the authentication of the unlogged-in client, and thus cannot perform the subsequent operations of obtaining the target account and generating login credentials carrying the target account. This avoids the problems of data security and user privacy leaks caused by unauthorized access from third-party websites or other sources through logged-in clients. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below.

[0023] Figure 1 A flowchart illustrating the steps of a login status synchronization method provided in this application embodiment; Figure 2 A flowchart illustrating the steps of another login status synchronization method provided in this application embodiment; Figure 3 A flowchart illustrating the steps of another login status synchronization method provided in this application embodiment; Figure 4 A flowchart illustrating the steps of another login status synchronization method provided in this application embodiment; Figure 5 This is a schematic diagram of the structure of a login status synchronization system provided in an embodiment of this application; Figure 6 A schematic diagram of another login status synchronization system provided in this application embodiment; Figure 7 A structural block diagram of a login status synchronization device provided in an embodiment of this application; Figure 8 A structural block diagram of another login status synchronization device provided in the embodiments of this application; Figure 9 This is a schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0024] The technical solutions of the present invention will now be described with reference to the accompanying drawings in the embodiments of the present invention.

[0025] Figure 1 This is a flowchart of the steps of a login status synchronization method provided in this application, see reference. Figure 1 The method may include the following steps: Step 101: Obtain the first identifier ciphertext.

[0026] In this embodiment, the method is applied to a backend server. The first identifier ciphertext is obtained by encrypting the first identifier plaintext used to identify the unlogged-in client based on the first encryption key.

[0027] An unlogged-in client can be an application software, such as a PC client software (Personal Computer Application, PCA), which can be multimedia platform software (e.g., video playback platform software). An unlogged-in client can also be a web page (Personal Computer Application Web, PCW), such as a web page of a multimedia playback platform (e.g., a video playback platform web page).

[0028] For example, the unlogged-in client encrypts the plaintext of the first identifier based on the first encryption key to obtain the ciphertext of the first identifier. The ciphertext of the first identifier can be sent to the logged-in client, which then sends it to the backend server.

[0029] For example, if the unlogged-in client is an application, the logged-in client can be a web page; if the unlogged-in client is a web page, the logged-in client can be an application.

[0030] Step 102: Decrypt the first identifier ciphertext using the first decryption key corresponding to the first encryption key to obtain the first identifier plaintext.

[0031] For example, the first encryption key and its corresponding first decryption key can be the first public key and the first private key in the first key pair, respectively. The unlogged-in client uses the first public key to encrypt the first identifier plaintext, obtaining the first identifier ciphertext. The backend server uses the first private key to decrypt the first identifier ciphertext, obtaining the first identifier plaintext.

[0032] Step 103: Send the first identifier plaintext to the login server so that the login server can obtain the target account logged in by the logged-in terminal if it determines that the identity of the unlogged-in terminal is legitimate based on the first identifier plaintext, generate a login credential carrying the target account, and send the login credential to the unlogged-in terminal so that the unlogged-in terminal can log in to the target account based on the login credential.

[0033] For example, the first identifier plaintext is sent to the login server. If the login server determines that the identity of the unlogged-in client is illegitimate based on the first identifier plaintext, the scheme is terminated and the subsequent operations of obtaining the target account and generating login credentials are no longer performed.

[0034] For example, the login server (PassPort) can be a server with authentication and login credential issuance capabilities. The login server communicates with backend servers, which can communicate with multiple devices; the devices connected to the backend servers can be PCWs or PCAs.

[0035] Legitimate devices can register with the login server. After registration, the login server stores the plaintext identifier of the legitimate device. In this step, after the backend server sends the first plaintext identifier to the login server, the login server checks whether the first plaintext identifier of an unlogged-in device exists in the stored list of legitimate device identifiers. If it exists, the unlogged-in device is deemed legitimate; otherwise, the unlogged-in device is deemed illegitimate.

[0036] For example, when a device logs in using an account and password, it sends a login request carrying the account and password to the login server. The login server authenticates the account and password, and upon successful authentication, returns a login token for the device to log in, while also storing the device's account. Conversely, when an already logged-in device logs in, the login server stores the target account of the logged-in device. In this step, if the login server verifies the legitimacy of the unlogged-in device, it can retrieve the stored target account and generate login credentials carrying that target account.

[0037] For example, the backend server sends the second identifier plaintext of the logged-in client to the backend server. After confirming that the identity of the unlogged-in client is legitimate, the backend server retrieves the account corresponding to the second identifier plaintext based on the second identifier plaintext and the stored correspondence between the account and the identifier plaintext of the logged-in device client, and identifies the account corresponding to the second identifier plaintext as the target account.

[0038] For example, the login server can send login credentials (authcookie) to the backend server, which then forwards them to the unlogged-in client. The login credentials can be a string encrypted by the login server using a preset encryption algorithm. This string can contain the target account that the logged-in client is using, as well as identifying information such as the login server's physical network interface card address (Media Access Control, MAC address) and device ID. Upon receiving the login credentials, the unlogged-in client can decrypt them using the corresponding decryption algorithm to obtain the target account and the login server's identification information. The unlogged-in client can then log in to the target account, synchronizing its login status with that of the logged-in client. Additionally, the unlogged-in client can authenticate with the login server based on the identification information, and only after successful authentication can it log in to the target account.

[0039] Some multimedia software allows users to quickly log in to PCW through an already logged-in PCA, thereby improving the convenience of user operation. For example, if PCA is already open and logged in with the target account and password in PCA, users only need to launch PCW to automatically log in to the target account without having to enter the account and password information again.

[0040] In related technologies, PCA exposes a proxy service locally at 127.0.0.1:16422 / 16423. PCW obtains the operation key (OptKey) through interaction with this proxy service and uses it to obtain login credentials (authcookie) to synchronize login status. However, the PCA local interface lacks validation for cross-domain access requests. Regardless of the legitimacy of third-party web pages, browsers, or local computer processes, any device that sends a request to obtain login credentials can obtain the user's login credentials and other sensitive user information. For example, after logging in with the user's credentials, it can obtain the user's browsing history and other information, which can lead to data security and privacy breaches. In other words, the methods of these technologies pose a risk that unauthorized users, such as those accessing third-party web pages, can steal login credentials through PCA and log in, resulting in data security and user privacy breaches.

[0041] In this embodiment, the first identifier ciphertext is obtained by encrypting the first identifier plaintext used to identify the unlogged-in terminal using the first encryption key. The backend server decrypts the first identifier ciphertext using the first decryption key corresponding to the first encryption key to obtain the first identifier plaintext. Only when the unlogged-in terminal is legitimate will it know the first encryption key corresponding to the first decryption key and use it to encrypt the first identifier plaintext to obtain the first identifier ciphertext. Correspondingly, the backend server can then decrypt the first identifier ciphertext using the first decryption key to obtain the correct first identifier plaintext. The login server can then determine the legitimacy of the unlogged-in terminal based on the correct first identifier plaintext, thereby obtaining the target account logged in by the logged-in terminal and generating login credentials carrying the target account. Only then can the unlogged-in terminal log in to the target account using the login credentials, achieving synchronization of the login status between the logged-in and unlogged-in terminals. Unauthorized devices do not know the first encryption key corresponding to the first decryption key, and therefore cannot use the first encryption key to encrypt the first identifier plaintext, thus failing to obtain the first identifier ciphertext that can be decrypted by the first decryption key. In other words, even if an unauthorized, unlogged-in client obtains the plaintext of the first identifier, because it does not know the correct first encryption key, it cannot obtain the ciphertext of the first identifier that can be decrypted using the first decryption key to obtain the correct plaintext of the first identifier. Therefore, when it sends the encrypted ciphertext to the backend server, the backend server cannot decrypt it using the first decryption key and obtain the correct decryption result (i.e., the plaintext of the first identifier). The backend server can only obtain an incorrect decryption result. After the backend server sends the incorrect decryption result to the login server, the login server, based on the incorrect decryption result, cannot pass the authentication of the unlogged-in client, and thus cannot perform the subsequent operations of obtaining the target account and generating login credentials carrying the target account. This avoids the problems of data security and user privacy leaks caused by unauthorized access from third-party websites or other entities through logged-in clients.

[0042] This application provides another embodiment of the login status synchronization method, referring to... Figure 2 The method may include the following steps.

[0043] Step 201: Obtain the first identifier ciphertext and obtain the second identifier plaintext used to identify the logged-in terminal.

[0044] In this embodiment, the application is to a backend server; the first identifier ciphertext is obtained by encrypting the first identifier plaintext used to identify the unlogged-in client based on the first encryption key. The first identifier plaintext may be the user identifier (Personal Computer Web Customer Identifier, PCW Cid) of the unlogged-in client.

[0045] For example, the unlogged-in client sends the first identifier ciphertext to the logged-in client, which then sends it to the backend server; the logged-in client sends the second identifier ciphertext to the backend server, which decrypts the second identifier ciphertext to obtain the second identifier plaintext.

[0046] In some embodiments of this application, the first identifier ciphertext is obtained by the unlogged-in terminal sending a login status query request to the logged-in terminal, and the unlogged-in terminal encrypting the first identifier plaintext based on the first encryption key when the logged-in terminal reports that the logged-in terminal is logged in.

[0047] For example, an unlogged-in client sends a login status query request to a logged-in client. Upon receiving the request, the logged-in client queries its login status. If the first condition is met, the logged-in client returns login status information indicating that it is logged in; for example, the login status information could be `canSync=true`. If the first condition is not met, subsequent processing terminates, and the process ends. The first condition can include: confirming that the logged-in client's login status is logged in; additionally, the first condition can also include: confirming that the logged-in client supports synchronous login operations.

[0048] Furthermore, upon receiving the login status information, the unlogged-in client encrypts the first identifier plaintext based on the first encryption key to generate the first identifier ciphertext, and sends the first identifier ciphertext to the logged-in client, which then sends it to the backend server.

[0049] In this embodiment, the unlogged-in terminal sends a login status query request to the logged-in terminal. If the logged-in terminal reports a login status of "logged in," the unlogged-in terminal encrypts the first identifier plaintext using the first encryption key. This embodiment ensures that subsequent operations are only performed when the logged-in terminal is already logged in, thus synchronizing the login status of the unlogged-in terminal and the logged-in terminal. If the unlogged-in terminal still generates the first identifier ciphertext and sends it to the backend server when the logged-in terminal is not logged in, the backend server will then obtain the first identifier plaintext based on the ciphertext and send it to the login authentication server. Even if the login authentication server successfully authenticates the unlogged-in terminal based on the first identifier plaintext, it cannot obtain the target account because the logged-in terminal is not logged in, and therefore cannot generate login credentials carrying the target account. In this embodiment, the unlogged-in terminal encrypts the first identifier plaintext using the first encryption key only when the logged-in terminal reports a login status of "logged in," thus avoiding unnecessary subsequent operations when the logged-in terminal is not logged in.

[0050] In some embodiments of this application, obtaining the second identifier plaintext for identifying the logged-in terminal in step 201 may include sub-steps 2011 to 2012: Sub-step 2011: Obtain the second identifier ciphertext.

[0051] The second identifier ciphertext is obtained by encrypting the second identifier plaintext used to identify the logged-in terminal using the second encryption key. The second identifier plaintext can be the user identifier (Personal Computer Application Customer Identifier, PCA Cid) of the logged-in terminal.

[0052] For example, the second identifier ciphertext is sent from the logged-in client to the backend server. Alternatively, an unlogged-in client sends the first identifier ciphertext to the logged-in client, who then encrypts the second identifier plaintext to obtain the second identifier ciphertext, and then sends both the first and second identifier ciphertexts together to the backend server.

[0053] By sending encrypted first identifier ciphertext (e.g., PCW Cid ciphertext) and second identifier ciphertext (e.g., PCACid ciphertext), a multi-layered encryption mechanism is implemented to ensure the secure transmission of sensitive information. Based on a backend server, centralized verification of logged-in and logged-out clients can be achieved. Specifically, by decrypting the first and second identifier ciphertexts on the client-side backend, centralized verification of the identities of logged-out and logged-out clients is achieved, providing unified security control capabilities. Furthermore, the credential exchange process, which is performed locally in related technologies, is migrated to a trusted backend server. Centralized verification by the backend server eliminates the security risks posed by locally exposed interfaces on logged-out clients. Using encrypted credentials instead of plaintext credentials for transmission—for example, using encrypted Cid Tokens (i.e., first and second identifier ciphertexts) instead of plaintext Cid transmission—ensures the security of sensitive information such as the first identifier of logged-out clients and the second identifier of logged-out clients during transmission.

[0054] Sub-step 2012: Decrypt the second identifier ciphertext using the second decryption key corresponding to the second encryption key to obtain the second identifier plaintext used to identify the logged-in terminal.

[0055] For example, the second encryption key and its corresponding second decryption key can be the second public key and the second private key in the second key pair, respectively. The logged-in client encrypts the second identifier plaintext using the second public key to obtain the second identifier ciphertext, and the backend server decrypts the second identifier ciphertext using the second private key to obtain the second identifier plaintext. In this embodiment, the backend server obtains the second identifier ciphertext, which is obtained by the logged-in terminal encrypting the second identifier plaintext based on the second encryption key. The second identifier ciphertext is then decrypted using the second decryption key corresponding to the second encryption key to obtain the second identifier plaintext. Transmitting the second identifier of the logged-in terminal in an encrypted manner can prevent the second identifier from being stolen by unauthorized devices and improve data security.

[0056] Step 202: Decrypt the first identifier ciphertext using the first decryption key corresponding to the first encryption key to obtain the first identifier plaintext.

[0057] The method for this step has been explained in step 102 above, and will not be repeated here.

[0058] Step 203: Send the first identifier plaintext and the second identifier plaintext to the login server so that the login server can determine the legitimacy of the non-login end based on the first identifier plaintext and the legitimacy of the login status of the logged-in end based on the second identifier plaintext, obtain the target account logged in by the logged-in end, generate a login credential carrying the target account, and send the login credential to the non-login end so that the non-login end can log in to the target account based on the login credential.

[0059] For example, if the login server determines that the identity of the unlogged-in client is illegitimate based on the first identifier plaintext, or determines that the login status of the logged-in client is illegitimate based on the second identifier plaintext, then the scheme is terminated.

[0060] For example, if the login server determines that the logged-in client's identity is legitimate and that the current login status of the logged-in client is logged in, then the login status of the logged-in client is deemed legitimate; if the login server determines that the logged-in client's identity is illegitimate, or that the current login status of the logged-in client is not logged in, then the login status of the logged-in client is deemed illegitimate.

[0061] Furthermore, the login server uses the second identifier plaintext to determine whether the logged-in client has registered with the login server. If it has registered, the logged-in client's identity is deemed legitimate; if it has not registered, the logged-in client's identity is deemed illegitimate.

[0062] Furthermore, the login server stores the identifiers of logged-in devices. In this step, if the login server finds the second identifier plaintext in the stored identifier information of logged-in devices, it determines that the logged-in device has logged in.

[0063] In this embodiment, the backend server sends a first and a second plaintext identifier to the login server. The login server, based on the first plaintext identifier, determines the legitimacy of the unlogged-in client, and based on the second plaintext identifier, determines the legitimacy of the logged-in client's login status. Then, it obtains the target account logged in by the logged-in client. Thus, the backend server and the login server work together to achieve dual authentication of both the unlogged-in client and the logged-in client based on the first and second plaintext identifiers. This prevents the unauthorized acquisition of the logged-in client's target account and the generation of login credentials based on the target account, even if the unlogged-in client is illegitimate or the logged-in client's login status is illegitimate, thus avoiding data leakage caused by unauthorized unlogged-in clients or logged-in clients obtaining login credentials. In other words, this embodiment improves data security and prevents login credential leakage.

[0064] For example, step 203 may include the following sub-steps: Sub-step 2031: Send the first and second plaintext identifiers to the login server so that the login server can establish and store the association between the first and second plaintext identifiers, and send the operation key to the backend server, after determining the legitimacy of the identity of the unlogged-in client based on the first plaintext identifier and the legitimacy of the login status of the logged-in client based on the second plaintext identifier.

[0065] In this embodiment, the operation key (Option Key, OptKey) is an intermediate parameter. The login server can send the operation key to the backend server in an encrypted manner, or it can send the operation key directly to the backend server.

[0066] Sub-step 2032: Return the operation key and the first identifier plaintext to the login server, so that the login server, after determining that the backend server has returned the operation key within a preset time, can obtain the second identifier plaintext based on the association relationship and the first identifier plaintext returned by the backend server, and obtain the target account logged in by the logged-in terminal based on the second identifier plaintext.

[0067] For example, if the login server determines that the backend server has not returned the operation key within the preset time, the scheme ends and the subsequent operations of obtaining the second identifier plaintext based on the association relationship and the first identifier plaintext returned by the backend server, and obtaining the target account logged in by the logged-in client based on the second identifier plaintext, will no longer be performed.

[0068] For example, the login server can determine the time elapsed from issuing the operation key to receiving the operation key returned by the backend server based on the time when the operation key is issued and the time when the operation key is received. If the time exceeds a preset time, it is determined that the backend server did not return the operation key within the preset time; if the time does not exceed the preset time, it is determined that the backend server returned the operation key within the preset time.

[0069] For example, when the login server issues an operation key, it stores the operation key in a preset storage space using a time-limited deletion method. This time-limited deletion includes deleting the operation key from the preset storage space if the storage time exceeds the preset time limit. If the login server receives the operation key from the backend server and recognizes that the operation key is stored in the preset storage space, it determines that the backend server will return the operation key within the preset time limit. If the login server receives the operation key from the backend server and recognizes that the operation key is not stored in the preset storage space, it indicates that the storage time has exceeded the preset time limit, and therefore determines that the backend server did not return the operation key within the preset time limit.

[0070] In this embodiment, the operation key is not static but dynamically changing. If the login server sends the operation key to the backend server, and the backend server does not return the operation key within a preset time period, the login server will consider the operation key verification unsuccessful and will not continue with subsequent operations. Furthermore, the login server will delete the stored operation key when the preset storage time is reached and generate a new operation key in the next interaction with the client backend. Through the dynamic generation and periodic updating of the operation key, dynamic key management can be achieved, preventing unauthorized devices from cracking the operation key and improving the level of security protection.

[0071] For example, the login server has two independent interfaces. The first interface can associate the first plaintext identifier of an unlogged-in client with the second plaintext identifier of a legitimate logged-in client. The second interface can obtain the second plaintext identifier based on the first plaintext identifier and the previously established association when a valid and legitimate operation key is obtained. Based on the second plaintext identifier, the target account is obtained, and login credentials are generated based on the target account.

[0072] Specifically, after receiving the first identifier plaintext (PCW Cid plaintext) and the second identifier plaintext (PCA Cid plaintext) sent by the backend server, the login server generates login credentials through two steps. The first step verifies the legitimacy of the unlogged-in client's identity based on the first identifier plaintext and the legitimacy of the logged-in client's login status based on the second identifier plaintext. If both are valid, an association is established between the first and second identifier plaintexts, generating an operation key (OptKey). This operation key is stored using a time-limited deletion mechanism and sent to the backend server. The second step involves obtaining the operation key and the first identifier plaintext returned by the backend server. If the operation key is verified as valid (i.e., found in the preset storage space), the second identifier plaintext is obtained based on the first identifier plaintext returned by the backend server and the association between the first and second identifier plaintexts. The target account is then obtained from the second identifier plaintext, and login credentials carrying the target account are generated. Through these two steps, the login server can further enhance data security. For example, by verifying the expiration date of the intermediate medium OptKey, unauthorized devices can be prevented from cracking the OptKey.

[0073] In this embodiment, the first and second plaintext identifiers are sent to the login server. The login server, upon determining the legitimacy of the logged-in client based on the second plaintext identifier and the legitimacy of the unlogged-in client based on the first plaintext identifier, establishes and stores the association between the first and second plaintext identifiers and sends an operation key to the backend server. The operation key and the first plaintext identifier are then returned to the login server. Upon confirming that the backend server returns the operation key within a preset timeframe, the login server accurately and quickly retrieves the second plaintext identifier associated with the first plaintext identifier based on the first plaintext identifier and the stored association, and retrieves the target account logged in by the logged-in client based on the second plaintext identifier. It typically takes a certain amount of time for unauthorized devices to crack operation keys using unauthorized programs. This embodiment limits the time of operation keys (i.e., the login server only performs subsequent operations if it determines that the backend server has returned the operation key within a preset time). This avoids the situation where unauthorized devices can crack operation keys using unauthorized programs without a time limit, and thus prevents unauthorized devices from sending the cracked operation key to the login server, causing the login server to generate a target account based on the cracked operation key, and subsequently generate login credentials based on the target account, leading to the leakage of login credentials.

[0074] For example, prior to step 201, the method may also include the following steps: Step 204: Upon receiving the first key request from the unlogged-in terminal and successfully authenticating the unlogged-in terminal, obtain the first key pair, send the first encryption key in the first key pair to the unlogged-in terminal, and store the first decryption key in the first key pair.

[0075] For example, the first key pair includes a first public key and a first private key. The first public key can be sent as the first encryption key to the unlogged-in terminal, and the first public key can be stored as the first decryption key.

[0076] For example, the backend server stores the identifiers of legitimate devices. When a first key request is received, the first identifier plaintext in the first key request is obtained, and then the stored legitimate device identifiers and the first identifier plaintext are compared. If the first identifier plaintext is the same as the identifier of any of the stored legitimate devices, then the authentication of the unlogged-in device is confirmed to be successful.

[0077] Step 205: Upon receiving the second key request sent by the logged-in terminal and verifying the identity of the logged-in terminal, obtain the second key pair, send the second encryption key in the second key pair to the logged-in terminal, and store the second decryption key in the second key pair.

[0078] For example, the second key pair includes a second public key and a second private key. The second public key can be sent as the second encryption key to the logged-in terminal, and the second public key can be stored as the second decryption key.

[0079] For example, the backend server stores the identifiers of legitimate devices. When a second key request is received, the plaintext of the second identifier in the second key request is obtained. Then, the stored identifiers of legitimate devices and the plaintext of the second identifier are compared. If the plaintext of the second identifier is the same as the identifier of any of the stored legitimate devices, then the authentication of the logged-in device is confirmed to be successful.

[0080] In this embodiment, if the backend server successfully authenticates an unlogged-in device, it sends the first encryption key to the unlogged-in client and stores the corresponding first decryption key locally. This prevents unauthorized devices from obtaining the first encryption key, improving data security. Furthermore, by storing the first decryption key, the backend server can successfully decrypt the first identifier ciphertext obtained by encrypting it with the first encryption key, obtaining the first identifier plaintext. If the backend server successfully authenticates a logged-in device, it sends the second encryption key to the logged-in client and stores the corresponding second decryption key locally. Similarly, by storing the second decryption key, the backend server can successfully decrypt the second identifier ciphertext obtained by encrypting it with the second encryption key, obtaining the second identifier plaintext.

[0081] Reference Figure 3 This embodiment provides a login status synchronization method, which may include the following steps: Step 301: Obtain the first identifier plaintext sent by the backend server.

[0082] The first identifier plaintext is obtained by the backend server obtaining the first identifier ciphertext and decrypting the first identifier ciphertext using the first decryption key; the first identifier ciphertext is obtained by the unlogged-in terminal encrypting the first identifier plaintext used to identify the unlogged-in terminal based on the first encryption key corresponding to the first decryption key.

[0083] In this embodiment, the application is applied to the login server.

[0084] Step 302: If the identity of the unlogged-in terminal is confirmed to be legitimate based on the first identifier plaintext, obtain the target account logged in by the logged-in terminal and generate login credentials carrying the target account.

[0085] For example, in step 302, after determining the legitimacy of the unlogged-in client based on the first identifier plaintext, obtaining the target account logged in by the logged-in client may include sub-steps 3021 to 3022: Sub-step 3021: Obtain the second identifier plaintext sent by the backend server.

[0086] The second identifier in plaintext is used to identify logged-in endpoints.

[0087] For example, the unlogged-in client is PCW, and the logged-in client is PCA; or, the unlogged-in client is PCA, and the logged-in client is PCW.

[0088] Sub-step 3022: If the identity of the unlogged-in terminal is confirmed to be legitimate based on the first identifier plaintext, and the login status of the logged-in terminal is confirmed to be legitimate based on the second identifier plaintext, then obtain the target account logged in by the logged-in terminal.

[0089] In this embodiment, the login server receives a first and a second plaintext identifier sent by the backend server. Based on the first plaintext identifier, it determines that the identity of the unlogged-in client is legitimate. And based on the second plaintext identifier, it determines that the login status of the logged-in client is legitimate. Then, it obtains the target account logged in by the logged-in client. Thus, the backend server and the login server work together to achieve dual authentication of both the unlogged-in client and the logged-in client based on the first and second plaintext identifiers. This avoids the problem of obtaining the target account of the logged-in client and generating login credentials based on the target account even when the unlogged-in client is illegitimate or the login status of the logged-in client is illegitimate, leading to unauthorized access to login credentials and data leakage. In other words, this embodiment improves data security and prevents login credential leakage.

[0090] For example, sub-step 3022 may include the following sub-steps: Sub-step 30221: If the identity of the unlogged-in terminal is determined to be legitimate based on the first identifier plaintext, and the login status of the logged-in terminal is determined to be legitimate based on the second identifier plaintext, then establish and store the association between the first identifier plaintext and the second identifier plaintext.

[0091] Sub-step 30222: Send the operation key to the backend server and receive the operation key and the first identifier plaintext returned by the backend server.

[0092] Sub-step 30223: If it is determined that the backend server returns the operation key within a preset time period, the second identifier plaintext is obtained according to the association relationship and the first identifier plaintext returned by the backend server.

[0093] Sub-step 30224: Obtain the target account logged in by the logged-in client based on the second identifier plaintext.

[0094] In this embodiment, it typically takes a certain amount of time for an unauthorized device to crack the operation key using an unauthorized program. This embodiment avoids the situation where an unauthorized device can crack the operation key using an unauthorized program without a time limit by imposing a time limit on the operation key (i.e., the login server only performs subsequent operations if it determines that the backend server has returned the operation key within a preset time period). This prevents the unauthorized device from cracking the operation key and sending it to the login server, causing the login server to generate a target account based on the cracked operation key, and subsequently generate login credentials based on the target account, leading to the leakage of login credentials.

[0095] Step 303: Send the login credentials to the non-login end so that the non-login end can log in to the target account based on the login credentials.

[0096] For example, the login server sends the login credentials to the backend server, which then forwards the login credentials to the client that is not logged in.

[0097] In this embodiment, even if an unauthorized, unlogged-in client obtains the first identifier plaintext, it cannot obtain the first identifier ciphertext that can be decrypted using the first decryption key to obtain the correct first identifier plaintext because it does not know the correct first encryption key. Therefore, it sends the encrypted identifier ciphertext to the backend server. The backend server cannot decrypt the first identifier ciphertext using the first decryption key to obtain the correct decryption result (i.e., the first identifier plaintext). The backend server only obtains an incorrect decryption result. After the backend server sends the incorrect decryption result to the login server, the login server, based on the incorrect decryption result, cannot pass the authentication of the unlogged-in client, and thus cannot perform the subsequent operations of obtaining the target account and generating login credentials carrying the target account. Therefore, this avoids the problems of data security and user privacy leakage caused by unauthorized access from third-party websites or other entities through logged-in clients, as seen in related technologies.

[0098] In some embodiments of this application, the method may further include the following steps: Step 304: Store the operation key in the preset storage space by time-limited deletion.

[0099] The time-limited deletion method includes: if the storage time exceeds the preset time, the operation key in the preset storage space will be deleted.

[0100] For example, the default storage space could be the login server's cache, memory, or other storage space.

[0101] For example, an operation key is sent to the backend server and stored in a preset storage space; the time-limited deletion method may include: if the storage time does not exceed the preset time, then continue storing; if the storage time exceeds the preset time, then delete the operation key from the preset storage space.

[0102] Step 305: After receiving the operation key returned by the backend server, if the operation key is found to be stored in the preset storage space, then the backend server will return the operation key within the preset time period.

[0103] For example, after receiving the operation key returned by the backend server, the system queries the preset storage space. If it finds that the operation key is not stored in the preset storage space, it determines that the backend server did not return the operation key within the preset time period.

[0104] In this embodiment, the operation key is stored in a preset storage space using a time-limited deletion method. The time-limited deletion method includes: if the storage time exceeds the preset time, the operation key is deleted from the preset storage space; if an operation key is received from the backend server and the operation key is stored in the preset storage space, it is determined that the backend server returned the operation key and the first identifier plaintext within the preset time. Based on this embodiment, it is possible to quickly and accurately determine whether the backend server returned the operation key within the preset time.

[0105] Reference Figure 4 The login status synchronization method in this embodiment may include the following steps: Step S1: PCW sends a login status probe request to PCA to detect whether PCA is logged in.

[0106] In this embodiment, PCW is an unlogged-in client, and PCA is a logged-in client.

[0107] It should be noted that this embodiment only uses PCW as the unlogged-in terminal and PCA as the logged-in terminal as an example to illustrate the login status synchronization method of this application. This application is not limited to the case where the unlogged-in terminal is PCW and the logged-in terminal is PCA, but also applies to the case where the unlogged-in terminal is PCA and the logged-in terminal is PCW.

[0108] PCW can initiate a login status query request to PCA at a specific time (e.g., n seconds after entering the page); PCA checks its own login status and confirms whether it supports synchronization operations; if PCA's login status is logged in and PCA supports synchronization operations, it returns data carrying the canSync=true flag, which indicates that PCA's login status is logged in; if PCA's login status is not logged in, or PCA does not support synchronization operations, the scheme terminates.

[0109] Step S2: If PCA is already logged in, send a canSync=true flag to PCW.

[0110] Step S3: PCW encrypts the plaintext PCW Cid to obtain the ciphertext PCW Cid.

[0111] Wherein, the plaintext of PCW Cid is the first identifier plaintext in the aforementioned embodiments, and the ciphertext of PCW Cid is the first identifier ciphertext in the aforementioned embodiments.

[0112] In step S4, PCW sends the PCW Cid ciphertext to PCA via a syncLogin request.

[0113] PCW sends a syncLogin request to PCA, which carries the PCW Cid ciphertext.

[0114] For example, the legitimacy of login credential requests can be enhanced through digital signatures and source verification mechanisms. For instance, the logged-in client digitally signs the PCW CID and PCA CID ciphertexts, and then sends the signed PCW CID and PCA CID ciphertexts to the backend server to prevent unauthorized devices from tampering with them. Furthermore, in subsequent processing, the backend server can use the digital signatures to determine whether the first and second identifier ciphertexts have been altered, thereby improving data security.

[0115] In step S5, PCA responds to the received syncLogin request by extracting the PCW Cid ciphertext from the syncLogin request and encrypting the PCA Cid plaintext to obtain the PCA Cid ciphertext.

[0116] Wherein, the plaintext PCA Cid is the second identifier plaintext in the aforementioned embodiment, and the ciphertext PCA Cid is the second identifier ciphertext in the aforementioned embodiment.

[0117] In step S6, PCA sends the PCW Cid ciphertext and PCA Cid ciphertext to the client backend.

[0118] In this context, the backend refers to the backend server in the aforementioned embodiments. One backend server can communicate with multiple devices, and is not limited to... Figure 4 The image shows a pair of device ends (including PCW and PCA).

[0119] In this implementation, PCA does not provide a local open interface. After PCW sends a login credential request to PCA, PCA directly returns the PCW login credential. This embodiment eliminates the local open interface of PCA in related technologies. Instead, PCA obtains the PCW Cid ciphertext and PCA Cid ciphertext and sends them to the backend server. The backend server and login server work together to authenticate PCW. Login credential is generated only after successful authentication, thereby eliminating the risk of cross-domain access at the source, eliminating local vulnerabilities, and achieving multiple encryption protection.

[0120] Step S7: The client decrypts the PCW Cid ciphertext and PCA Cid ciphertext in the backend to obtain the PCW Cid plaintext and PCA Cid plaintext.

[0121] The client-side backend, in collaboration with PCW, PCA, and the login server, implements a secure synchronous login method. Based on the client-side backend, a secure cross-platform authentication mechanism can be established, resolving the vulnerability of login credential leakage during multi-platform login state synchronization and preventing malicious programs from stealing login credentials and taking over accounts. Based on this embodiment, a highly secure synchronous login solution can be provided while ensuring user experience, fundamentally addressing the security vulnerabilities in related login state synchronization solutions and achieving secure and reliable multi-platform (Personal Computer, PC) login state synchronization.

[0122] In step S8, the client backend sends the plaintext PCW Cid and PCA Cid to the PassPort middleware.

[0123] The PassPort middleware is the login server in the aforementioned embodiments.

[0124] In this embodiment, the PCA agent receives a syncLogin request from PCW, extracts the PCWCid ciphertext carried in it, encrypts the PCA Cid plaintext with the second public key to obtain the PCA Cid ciphertext, and then sends the PCA Cid ciphertext and PCW Cid ciphertext together to the end backend.

[0125] The client backend uses the first and second private keys to decrypt the ciphertext of PCA cid and the ciphertext of PCW Cid respectively, obtaining the plaintext of PCAcid and PCW Cid. The client backend then sends the plaintext of PCA cid and PCW Cid to the PassPort middleware. The PassPort middleware verifies whether the login status of PCA is valid and whether the identity of PCW is valid. If both are valid, the client backend associates the plaintext of PCW Cid with the plaintext of PCA Cid and sends the OptKey to the client backend.

[0126] In step S9, the PassPort middleware verifies whether the PCA's login status is valid and whether the PCW's identity is valid. If both are valid, the association between the PCW's plaintext Cid and the PCA's plaintext Cid is established, and the OptKey is returned to the client backend. If the PCA's login status is invalid or the PCW's identity is invalid, the process is interrupted.

[0127] PassPort's unified authentication service enables centralized authentication and authorization management for PCW and PCA, which can improve data security.

[0128] Step S10: The client backend receives the OptKey and sends the OptKey and PCW Cid in plaintext to the PassPort middleware.

[0129] In this embodiment, PassPort synchronizes the login status through two interfaces: one interface associates the cid of PCA and PCW and returns the OptKey, and the second interface obtains the authCookie based on the valid OptKey and cid.

[0130] Passport synchronizes login status through two independent services: The first service verifies the validity of the PCW and PCA login status based on the PCWCid. If both the PCW Cid and PCA login status are valid, an association is established between the plaintext PCW Cid and the PCA Cid, and an OptKey is generated. The second service retrieves the authCookie based on the valid OptKey and PCW Cid. Specifically, if the OptKey is found in a pre-defined storage space that stores OptKeys using a time-limited deletion method, the OptKey is considered valid.

[0131] In this embodiment, PassPort does not directly generate an authcookie based on the PCW and OptKey after confirming that the PCA login status is legitimate and the PCW identity is legitimate, in order to improve data security. For example, by adding an intermediate medium parameter such as OptKey, the lifecycle of OptKey (i.e., the storage market in the preset storage space) can be verified to prevent unauthorized devices from cracking OptKey.

[0132] For example, this embodiment supports distributed deployment of backend servers to ensure high availability and stability of the service. Step S11: The PassPort middleware sends the authcookie to the client backend.

[0133] For example, dynamically generated encryption keys can be used to encrypt and protect user credentials in real time, reducing the risk of credential misuse.

[0134] For example, if PassPort obtains a valid and unexpired OptKey, it means that a valid association has been established between the PCW Cid plaintext and the PCA Cid plaintext, or that the association has not expired. In this case, based on the PCW Cid plaintext, the PCA Cid plaintext is obtained from the association, the target account is obtained from the PCA Cid plaintext, login credentials are generated based on the target account, and the unlogged-in client logs in to the target account logged in by the logged-in client based on the login credentials, thus realizing synchronous login of the target account by the unlogged-in client and the logged-in client.

[0135] In step S12, the client backend sends the authcookie to the PCW so that the PCW can perform synchronous login based on the authcookie.

[0136] authCookie is an encrypted string containing identifying information such as MAC address, device ID, and user ID, and it has an expiration time. After obtaining the OptKey, the backend uses the OptKey and the PCW Cid in plaintext to request the PassPort interface to obtain the authCookie, and then sends it to the PCW that initiated the login state synchronization. The PCW obtains the authCookie and logs into the target account, thus synchronizing the login state with the PCA.

[0137] For example, the client-side backend decrypts the PCW Cid ciphertext to obtain the PCW Cid plaintext, decrypts the PCA Cid ciphertext to obtain the PCA Cid plaintext, and then uses the PCW Cid plaintext to authenticate the unlogged-in client and the PCA Cid plaintext to authenticate the logged-in client. If both authentications pass, further processing continues; if either authentication fails, further processing is terminated.

[0138] Furthermore, after obtaining the plaintext PCW CID and PCA CID, the PassPort platform performs authentication on unlogged-in devices based on the PCW CID and on logged-in devices based on the PCA CID. If both authentications pass, a link is established between the first identifier plaintext and the PCA CID plaintext, and subsequent processing is performed. This two-factor authentication prevents unauthorized devices from obtaining login credentials through PassPort, thus improving data security.

[0139] This embodiment can be widely applied to various application scenarios that require synchronization of login status across multiple devices; for example, applicable scenarios include, but are not limited to: unified login across multiple devices on video entertainment platforms, cross-device collaboration of enterprise office software, multi-channel user experience on e-commerce platforms, and multi-platform account management on social media.

[0140] In related technologies, a local proxy service can be started on a logged-in device (such as PCA) for quick login. However, the entire process does not perform identity authentication and security verification on the source of the access request sent to PCA. This may allow any webpage, plugin, or local process to access the interface of the logged-in device and obtain Cid and OptKey data, thereby obtaining the user's authcookie, leading to authcookie leakage and the risk of account takeover.

[0141] Based on this embodiment, a multi-layered security protection system is established through a dual encryption mechanism of backend services and PassPort authentication services. This system provides enterprise-level security while ensuring convenient user login and improving user experience. By eliminating the local open interface of the PCA client, secure data exchange is performed based on the backend Application Programming Interface (API). In this embodiment, the user experience is optimized by maintaining convenient operation of logging in on one end and synchronizing across multiple devices. This embodiment supports the access and expansion of more PC-side products, exhibiting excellent application scalability. Furthermore, this embodiment supports different operating systems and browser environments, enabling cross-platform implementation of this solution.

[0142] Based on this embodiment, a centralized backend server verification architecture can be introduced into PC multi-terminal login synchronization scenarios, achieving security architecture innovation and fundamentally solving local interface security vulnerabilities. This embodiment can also employ a dual-token encryption mechanism using Cid Token (i.e., encrypted PCW Cid and encrypted PCA Cid) and OptKey Token to achieve secure transmission of sensitive data. By establishing a dual encryption protection system for backend services and PassPort services, multi-layered security protection can be provided; by introducing dynamic key management and timeliness control, the system's security protection capabilities can be significantly improved; and by implementing centralized identity verification and access control through the PassPort unified authentication service, an enterprise-level security solution can be provided, achieving unified authentication integration.

[0143] Reference Figure 5 This application embodiment also provides a login status synchronization system, including an unlogged-in terminal 401, a logged-in terminal 402, a backend server 403, and a login server 404; wherein, the unlogged-in terminal 401 is used to encrypt a first identifier plaintext for identifying the unlogged-in terminal based on a first encryption key to obtain a first identifier ciphertext; the backend server 402 is used to obtain the first identifier ciphertext, and decrypt the first identifier ciphertext using a first decryption key corresponding to the first encryption key to obtain the first identifier plaintext, and send the first identifier plaintext to the login server; the login server 403 is used to obtain the target account logged in by the logged-in terminal if the identity of the unlogged-in terminal is determined to be legitimate based on the first identifier plaintext, and generate a login credential carrying the target account, and send the login credential to the unlogged-in terminal; the unlogged-in terminal 404 is also used to log in to the target account based on the login credential.

[0144] For example, refer to Figure 6The logged-in client can be PCA, and the unlogged-in client can be PCW. The backend server can be the PC client backend, and the login server can be PassPort. The client backend includes a decryption module (Decrypt). Both the unlogged-in client and the logged-in client can interact with the client backend server, and the client backend interacts with PassPort.

[0145] Based on the login status synchronization system provided in this embodiment, login synchronization between logged-in and logged-out devices can be achieved, improving data security, preventing unauthorized devices from obtaining login credentials and logging into target accounts based on login credentials, thereby stealing user privacy data related to the target accounts.

[0146] Reference Figure 7 This application embodiment also provides a login status synchronization model training device. The device 50 includes: a first acquisition module 501, used to acquire a first identifier ciphertext; the first identifier ciphertext is obtained by encrypting a first identifier plaintext used to identify the unlogged-in terminal based on a first encryption key; a first decryption module 502, used to decrypt the first identifier ciphertext using a first decryption key corresponding to the first encryption key to obtain the first identifier plaintext; and a first sending module 503, used to send the first identifier plaintext to a login server, so that the login server, after determining the legitimacy of the unlogged-in terminal's identity based on the first identifier plaintext, can obtain the target account logged in by the logged-in terminal, generate a login credential carrying the target account, and send the login credential to the unlogged-in terminal, so that the unlogged-in terminal can log in to the target account based on the login credential.

[0147] Optionally, the device 50 further includes: a third acquisition module, used to acquire a second identifier plaintext used to identify the logged-in terminal; the third sending module 503 is specifically used to: send the first identifier plaintext and the second identifier plaintext to the login server, so that the login server can obtain the target account logged in by the logged-in terminal when it determines that the identity of the unlogged-in terminal is legitimate based on the first identifier plaintext and the login status of the logged-in terminal is legitimate based on the second identifier plaintext.

[0148] Optionally, the third sending module 503 is specifically used to: send the first identifier plaintext and the second identifier plaintext to the login server, so that the login server, based on the first identifier plaintext, determines that the identity of the unlogged-in terminal is legitimate, and based on the second identifier plaintext, determines that the login status of the logged-in terminal is legitimate, establishes and stores the association between the first identifier plaintext and the second identifier plaintext, and sends an operation key to the backend server; return the operation key and the first identifier plaintext to the login server, so that the login server, based on the association and the first identifier plaintext returned by the backend server, obtains the second identifier plaintext, and obtains the target account logged in by the logged-in terminal, based on the second identifier plaintext, provided that the backend server returns the operation key within a preset time period.

[0149] Optionally, the third sending module 503 is specifically used for: obtaining the second identifier ciphertext; the second identifier ciphertext is obtained by the logged-in terminal encrypting the second identifier plaintext used to identify the logged-in terminal based on the second encryption key; and decrypting the second identifier ciphertext using the second decryption key corresponding to the second encryption key to obtain the second identifier plaintext used to identify the logged-in terminal.

[0150] Optionally, the device 50 further includes: a first receiving module, configured to receive a first key request sent by an unlogged-in terminal, and, if the unlogged-in terminal's identity is successfully authenticated, obtain a first key pair, send a first encryption key from the first key pair to the unlogged-in terminal, and store a first decryption key from the first key pair; and a second receiving module, configured to receive a second key request sent by a logged-in terminal, and, if the logged-in terminal's identity is successfully authenticated, obtain a second key pair, send a second encryption key from the second key pair to the logged-in terminal, and store a second decryption key from the second key pair.

[0151] Optionally, the first identifier ciphertext is obtained by the unlogged-in end sending a login status query request to the logged-in end, and the unlogged-in end responding that the login status of the logged-in end is logged in, and the unlogged-in end encrypting the first identifier plaintext based on the first encryption key.

[0152] Based on this embodiment, login synchronization between logged-in and logged-out devices can be achieved, and login credentials can be prevented from being stolen by unauthorized devices, thus improving data security.

[0153] Reference Figure 8 This embodiment provides a login status synchronization device. The device 60 includes: a second acquisition module 601, used to acquire a first identifier plaintext sent by a backend server; the first identifier plaintext is obtained by the backend server acquiring a first identifier ciphertext and decrypting the first identifier ciphertext using a first decryption key; the first identifier ciphertext is obtained by the unlogged-in terminal encrypting the first identifier plaintext used to identify the unlogged-in terminal based on a first encryption key corresponding to the first decryption key; a login credential generation module 602, used to acquire the target account logged in by the logged-in terminal and generate a login credential carrying the target account, provided that the identity of the unlogged-in terminal is determined to be legitimate based on the first identifier plaintext; and a second sending module 603, used to send the login credential to the unlogged-in terminal so that the unlogged-in terminal can log in to the target account based on the login credential.

[0154] Optionally, the login credential generation module 602 is used to: obtain a second identifier plaintext sent by the backend server; the second identifier plaintext is used to identify the logged-in terminal; and, if the identity of the unlogged-in terminal is determined to be legitimate based on the first identifier plaintext, and the login status of the logged-in terminal is determined to be legitimate based on the second identifier plaintext, obtain the target account logged in by the logged-in terminal.

[0155] Optionally, the login credential generation module 602 is used to: establish and store the association between the first and second plaintext identifiers, provided that the identity of the unlogged-in terminal is deemed legitimate based on the first plaintext identifier and the login status of the logged-in terminal is deemed legitimate based on the second plaintext identifier; send an operation key to the backend server and receive the operation key and the first plaintext identifier returned by the backend server; if it is determined that the backend server returns the operation key and the first plaintext identifier within a preset time period, obtain the second plaintext identifier based on the association and the first plaintext identifier returned by the backend server; and obtain the target account logged in by the logged-in terminal based on the second plaintext identifier.

[0156] Optionally, the login credential generation module 602 is specifically used to: store the operation key in a preset storage space by means of time-limited deletion; the time-limited deletion means include: if the storage time exceeds the preset time, then delete the operation key in the preset storage space; if the operation key returned by the backend server is received, and whether the operation key is stored in the preset storage space, then determine that the backend server will return the operation key and the first identifier plaintext within the preset time.

[0157] Based on this embodiment, the problems of data security and user privacy leakage caused by unauthorized access from third-party websites and other sources through logged-in terminals can be avoided, as is the case in related technologies.

[0158] The above-described apparatus embodiments are basically similar to the method embodiments, so the description is relatively simple. For relevant details, please refer to the description of the method embodiments.

[0159] This invention also provides an electronic device, such as... Figure 9 As shown, it includes a processor 701, a communication interface 702, a memory 703, and a communication bus 704, wherein the processor 701, the communication interface 702, and the memory 703 communicate with each other through the communication bus 704. Memory 703 is used to store computer programs; When the processor 701 executes the program stored in the memory 703, it performs the following steps: obtaining a first identifier ciphertext; the first identifier ciphertext is obtained by encrypting a first identifier plaintext used to identify the unlogged-in terminal based on a first encryption key; decrypting the first identifier ciphertext using a first decryption key corresponding to the first encryption key to obtain the first identifier plaintext; and sending the first identifier plaintext to the login server, so that the login server, based on the first identifier plaintext and determining that the identity of the unlogged-in terminal is legitimate, can obtain the target account logged in by the logged-in terminal, generate a login credential carrying the target account, and send the login credential to the unlogged-in terminal, so that the unlogged-in terminal can log in to the target account based on the login credential.

[0160] Optionally, the processor 701 may also perform the following steps: obtaining a second identifier plaintext used to identify the logged-in terminal; sending the first identifier plaintext to the login server, so that the login server can obtain the target account logged in by the logged-in terminal if it determines that the identity of the unlogged-in terminal is legitimate based on the first identifier plaintext, including: sending the first identifier plaintext and the second identifier plaintext to the login server, so that the login server can obtain the target account logged in by the logged-in terminal if it determines that the identity of the unlogged-in terminal is legitimate based on the first identifier plaintext and the login status of the logged-in terminal is legitimate based on the second identifier plaintext.

[0161] Optionally, the processor 701 can also perform the following steps: sending the first identifier plaintext and the second identifier plaintext to the login server, so that the login server, based on the first identifier plaintext, determines that the identity of the unlogged-in terminal is legitimate, and based on the second identifier plaintext, determines that the login status of the logged-in terminal is legitimate, establishes and stores the association between the first identifier plaintext and the second identifier plaintext, and sends an operation key to the backend server; returning the operation key and the first identifier plaintext to the login server, so that the login server, based on the association and the first identifier plaintext returned by the backend server, obtains the second identifier plaintext, and obtains the target account logged in by the logged-in terminal, based on the second identifier plaintext, provided that the backend server returns the operation key within a preset time.

[0162] Optionally, the processor 701 may also perform the following steps: obtaining the second identifier ciphertext; the second identifier ciphertext is obtained by encrypting the second identifier plaintext used to identify the logged-in terminal based on the second encryption key; the second identifier ciphertext is decrypted using the second decryption key corresponding to the second encryption key to obtain the second identifier plaintext used to identify the logged-in terminal.

[0163] Optionally, the processor 701 may also perform the following steps: upon receiving a first key request from an unlogged-in terminal and successfully authenticating the unlogged-in terminal, obtaining a first key pair, sending the first encryption key in the first key pair to the unlogged-in terminal, and storing the first decryption key in the first key pair; upon receiving a second key request from a logged-in terminal and successfully authenticating the logged-in terminal, obtaining a second key pair, sending the second encryption key in the second key pair to the logged-in terminal, and storing the second decryption key in the second key pair.

[0164] Optionally, the first identifier ciphertext is obtained by the unlogged-in end sending a login status query request to the logged-in end, and the unlogged-in end responding that the login status of the logged-in end is logged in, and the unlogged-in end encrypting the first identifier plaintext based on the first encryption key.

[0165] Optionally, the processor 701 may also perform the following steps: obtaining the first identifier plaintext sent by the backend server; obtaining the first identifier ciphertext by the backend server and decrypting the first identifier ciphertext using the first decryption key; encrypting the first identifier plaintext used to identify the unlogged-in terminal using the first encryption key corresponding to the first decryption key; if the identity of the unlogged-in terminal is determined to be legitimate based on the first identifier plaintext, obtaining the target account logged in by the logged-in terminal and generating a login credential carrying the target account; sending the login credential to the unlogged-in terminal so that the unlogged-in terminal can log in to the target account based on the login credential.

[0166] Optionally, the processor 701 may also perform the following steps: obtaining a second identifier plaintext sent by the backend server; the second identifier plaintext is used to identify the logged-in terminal; and, based on the first identifier plaintext, determining that the identity of the unlogged-in terminal is legitimate, and based on the second identifier plaintext, determining that the login status of the logged-in terminal is legitimate, obtaining the target account logged in by the logged-in terminal.

[0167] Optionally, the processor 701 may also perform the following steps: If the identity of the unlogged-in terminal is determined to be legitimate based on the first identifier plaintext, and the login status of the logged-in terminal is determined to be legitimate based on the second identifier plaintext, establish and store the association between the first identifier plaintext and the second identifier plaintext; send an operation key to the backend server, and receive the operation key and the first identifier plaintext returned by the backend server; if the backend server returns the operation key within a preset time period, obtain the second identifier plaintext based on the association and the first identifier plaintext returned by the backend server; obtain the target account logged in by the logged-in terminal based on the second identifier plaintext.

[0168] Optionally, the processor 701 can also perform the following steps: storing the operation key in a preset storage space by means of time-limited deletion; the time-limited deletion means that if the storage time exceeds the preset time, the operation key in the preset storage space is deleted. After receiving the operation key returned by the backend server, if the operation key is found to be stored in the preset storage space, it is determined that the backend server will return the operation key within the preset time period.

[0169] The communication bus mentioned above can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0170] The communication interface is used for communication between the aforementioned terminal and other devices.

[0171] The memory may include random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0172] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0173] In another embodiment of the present invention, a computer-readable storage medium is also provided, which stores instructions that, when executed on a computer, cause the computer to perform any of the login status synchronization methods described in the above embodiments.

[0174] In another embodiment of the present invention, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute any of the login status synchronization methods described in the above embodiments.

[0175] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk (SSD)).

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

[0177] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0178] The above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention are included within the scope of protection of the present invention.

Claims

1. A login status synchronization method, characterized in that, Applied to a backend server, the method includes: Obtain the first identifier ciphertext; the first identifier ciphertext is obtained by encrypting the first identifier plaintext used to identify the unlogged-in terminal based on the first encryption key; The first identifier ciphertext is decrypted using the first decryption key corresponding to the first encryption key to obtain the first identifier plaintext; The first identifier plaintext is sent to the login server, so that the login server, after determining the legitimacy of the non-login terminal based on the first identifier plaintext, can obtain the target account logged in by the logged-in terminal, generate a login credential carrying the target account, and send the login credential to the non-login terminal, so that the non-login terminal can log in to the target account based on the login credential.

2. The method according to claim 1, characterized in that, The method further includes: Obtain the second identifier plaintext used to identify the logged-in terminal; Sending the first identifier plaintext to the login server, so that the login server can obtain the target account logged in by the logged-in client after determining the legitimacy of the unlogged-in client based on the first identifier plaintext, includes: The first identifier plaintext and the second identifier plaintext are sent to the login server so that the login server can obtain the target account logged in by the logged-in terminal if it determines that the identity of the unlogged-in terminal is legitimate based on the first identifier plaintext and the login status of the logged-in terminal is legitimate based on the second identifier plaintext.

3. The method according to claim 2, characterized in that, Sending the first and second plaintext identifiers to the login server, so that the login server can determine the legitimacy of the unlogged-in client based on the first plaintext identifier and the legitimacy of the logged-in client's login status based on the second plaintext identifier, and then obtain the target account logged in by the logged-in client, includes: The first identifier plaintext and the second identifier plaintext are sent to the login server so that the login server can establish and store the association between the first identifier plaintext and the second identifier plaintext, and send the operation key to the backend server, after determining that the identity of the unlogged-in terminal is legitimate based on the first identifier plaintext and the login status of the logged-in terminal is legitimate based on the second identifier plaintext. The operation key and the first identifier plaintext are returned to the login server, so that when the login server determines that the backend server has returned the operation key within a preset time period, it can obtain the second identifier plaintext based on the association relationship and the first identifier plaintext returned by the backend server, and obtain the target account logged in by the logged-in terminal based on the second identifier plaintext.

4. The method according to claim 2, characterized in that, The step of obtaining the second identifier plaintext used to identify the logged-in terminal includes: Obtain the second identifier ciphertext; the second identifier ciphertext is obtained by the logged-in terminal encrypting the second identifier plaintext used to identify the logged-in terminal based on the second encryption key; The second identifier ciphertext is decrypted using the second decryption key corresponding to the second encryption key to obtain the second identifier plaintext used to identify the logged-in terminal.

5. The method according to claim 4, characterized in that, The method further includes: Upon receiving the first key request sent by the unlogged-in client and successfully authenticating the identity of the unlogged-in client, the system obtains the first key pair, sends the first encryption key in the first key pair to the unlogged-in client, and stores the first decryption key in the first key pair. Upon receiving the second key request sent by the logged-in terminal and verifying the identity of the logged-in terminal, the system obtains the second key pair, sends the second encryption key in the second key pair to the logged-in terminal, and stores the second decryption key in the second key pair.

6. The method according to claim 1, characterized in that, The first identifier ciphertext is obtained by the unlogged-in terminal sending a login status query request to the logged-in terminal, and when the logged-in terminal reports that the login status of the logged-in terminal is logged in, the unlogged-in terminal encrypts the first identifier plaintext based on the first encryption key.

7. A login status synchronization method, characterized in that, Applied to a login server, the method includes: The first identifier plaintext sent by the backend server is obtained; the first identifier plaintext is obtained by the backend server by obtaining the first identifier ciphertext and decrypting the first identifier ciphertext with the first decryption key; the first identifier ciphertext is obtained by the unlogged-in terminal by encrypting the first identifier plaintext used to identify the unlogged-in terminal based on the first encryption key corresponding to the first decryption key; If the identity of the unlogged-in terminal is determined to be legitimate based on the first identifier plaintext, the target account logged in by the logged-in terminal is obtained, and a login credential carrying the target account is generated. The login credentials are sent to the non-login terminal so that the non-login terminal can log in to the target account based on the login credentials.

8. The method according to claim 7, characterized in that, The step of obtaining the target account logged into by the logged-in terminal after determining that the identity of the unlogged-in terminal is legitimate based on the first identifier plaintext includes: Obtain the second identifier plaintext sent by the backend server; the second identifier plaintext is used to identify the logged-in client; If the identity of the unlogged-in terminal is determined to be legitimate based on the first identifier plaintext, and the login status of the logged-in terminal is determined to be legitimate based on the second identifier plaintext, the target account logged in by the logged-in terminal is obtained.

9. The method according to claim 8, characterized in that, The step of obtaining the target account logged into by the logged-in terminal, after determining the identity of the unlogged-in terminal is legitimate based on the first identifier plaintext and the login status of the logged-in terminal is legitimate based on the second identifier plaintext, includes: If the identity of the unlogged-in terminal is determined to be legitimate based on the first identifier plaintext, and the login status of the logged-in terminal is determined to be legitimate based on the second identifier plaintext, then the association between the first identifier plaintext and the second identifier plaintext is established and stored. Send the operation key to the backend server and receive the operation key and the first identifier plaintext returned by the backend server; If it is determined that the backend server returns the operation key within a preset time period, the second identifier plaintext is obtained according to the association relationship and the first identifier plaintext returned by the backend server; Based on the second identifier plaintext, obtain the target account logged in by the logged-in terminal.

10. The method according to claim 9, characterized in that, The method further includes: The operation key is stored in a preset storage space by means of time-limited deletion; the time-limited deletion means that if the storage time exceeds the preset time, the operation key is deleted from the preset storage space. After receiving the operation key returned by the backend server, if the operation key is found to be stored in the preset storage space, it is determined that the backend server will return the operation key within a preset time period.

11. A login status synchronization system, characterized in that, This includes the client that is not logged in, the client that is logged in, the backend server, and the login server; The unlogged-in terminal is used to encrypt a first identifier plaintext used to identify the unlogged-in terminal based on a first encryption key, to obtain a first identifier ciphertext. The backend server is used to obtain the first identifier ciphertext, and decrypt the first identifier ciphertext using the first decryption key corresponding to the first encryption key to obtain the first identifier plaintext, and send the first identifier plaintext to the login server; The login server is configured to, when determining the legitimacy of the unlogged-in terminal based on the first identifier plaintext, obtain the target account logged in by the logged-in terminal, generate a login credential carrying the target account, and send the login credential to the unlogged-in terminal; The unlogged-in terminal is also used to log in to the target account based on the login credentials.

12. A login status synchronization device, characterized in that, Applied to backend servers, the device includes: The first acquisition module is used to acquire the first identifier ciphertext; the first identifier ciphertext is obtained by encrypting the first identifier plaintext used to identify the unlogged-in terminal based on the first encryption key; The first decryption module is used to decrypt the first identifier ciphertext using a first decryption key corresponding to the first encryption key to obtain the first identifier plaintext; The first sending module is configured to send the first identifier plaintext to the login server, so that the login server, after determining the legitimacy of the identity of the unlogged-in terminal based on the first identifier plaintext, can obtain the target account logged in by the logged-in terminal, generate a login credential carrying the target account, and send the login credential to the unlogged-in terminal, so that the unlogged-in terminal can log in to the target account based on the login credential.

13. A login status synchronization device, characterized in that, Applied to a login server, the device includes: The second acquisition module is used to acquire the first identifier plaintext sent by the backend server; the first identifier plaintext is obtained by the backend server acquiring the first identifier ciphertext and decrypting the first identifier ciphertext using the first decryption key; the first identifier ciphertext is obtained by the unlogged-in terminal encrypting the first identifier plaintext used to identify the unlogged-in terminal based on the first encryption key corresponding to the first decryption key; The login credential generation module is used to obtain the target account logged in by the logged-in terminal and generate a login credential carrying the target account, provided that the identity of the unlogged-in terminal is determined to be legitimate based on the first identifier plaintext. The second sending module is used to send the login credentials to the unlogged-in terminal so that the unlogged-in terminal can log in to the target account based on the login credentials.

14. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the steps of the method described in any one of claims 1-10.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method as described in any one of claims 1-10.

Images