Website login method, terminal device, and storage medium

Abstract

Embodiments of the present application provide a website login method, a terminal device and a storage medium. The website login method comprises: logging in a first website account in a first browser, and in the case that the first browser is not registered with a passwordless credential of the first website account, the first browser initiates a signature request to a sharing module; the sharing module requests an application management module to verify the identity of the first browser, in the case that the first browser is a legal browser and the first browser is in a browser set, the sharing module signs data carried by the signature request using an account private key of the first website account to obtain a signature value, the sharing module feeds back the signature value to the first browser, and the first browser passes the signature value to a website corresponding to the first website account, so that the website corresponding to the first website account verifies the signature value using an account public key of the first website account. The complexity of passwordless credential-based login between browsers can be reduced.

Description

Technical Field

[0001] This application relates to the field of terminal technology, specifically to a website login method, terminal device, and storage medium. Background Technology

[0002] Fast Identity Online (FIDO) is a technical specification for online user authentication developed by the FIDO Alliance industry association. This protocol is the first open industry standard for online and digital authentication, improving security, protecting privacy, and simplifying the user experience. The FIDO Alliance's passkey-free credential solution supports the use of biometrics, personal identification numbers (PINs), and other methods to replace traditional account and password logins to websites. The core of the passkey solution is that the device generates a public-private key pair for each user's account on the website. Each account on each website has its own independent and unique public-private key pair.

[0003] Registering for the same website without password credentials on different browsers of the same device is cumbersome and complex. Summary of the Invention

[0004] This application provides a website login method, terminal device, and storage medium, which can reduce the complexity of passwordless login between browsers.

[0005] A first aspect of this application provides a website login method, the method being applied to a terminal device, the terminal device including a sharing module, an application management module, and N browsers, the method including:

[0006] When a user logs into a first website account in a first browser, and the first browser has not registered a password for the first website account, the first browser sends a signature request to the sharing module. The first browser is any one of the N browsers, and the signature request carries the first website account.

[0007] The sharing module requests the application management module to verify the identity of the first browser. If the first browser is a legitimate browser and is in the browser set, the sharing module uses the private key of the first website account to sign the data carried in the signature request to obtain a signature value. The sharing module then feeds back the signature value to the first browser. The browser set is the set of browsers in which the first website account is allowed to share without password credentials.

[0008] The first browser transmits the signature value to the website corresponding to the first website account, so that the website corresponding to the first website account can use the account public key of the first website account to verify the signature value. If the verification is successful, it is determined that the first browser has successfully logged into the website corresponding to the first website account.

[0009] Optionally, if the first browser logs into the first website account and the first browser has not registered passwordless credentials for the first website account, the first browser initiates a signature request to the sharing module, including:

[0010] When the user logs into the first website account in the first browser, the first browser initiates user authentication.

[0011] If the user authentication is successful and the first browser does not have password credentials for the first website account, the first browser initiates a signature request to the sharing module.

[0012] Optionally, the data transmitted between the sharing module and the first browser is encrypted using a first symmetric key, which is a symmetric key between the sharing module and the first browser.

[0013] Alternatively, the data transmitted between the sharing module and the first browser may be encrypted using the other party's public key.

[0014] Optionally, before the first browser initiates a signature request to the sharing module, the method further includes:

[0015] When the sharing module and the second browser verify each other's identities as legitimate through the application management module, the sharing module and the second browser perform key negotiation to obtain a shared secret value. Based on the shared secret value, a second symmetric key is derived. The second symmetric key is the symmetric key between the sharing module and the second browser, where the second browser is any one of the N browsers, and N is an integer greater than or equal to 2.

[0016] The sharing module collects a list of registered website accounts without password credentials held by the second browser.

[0017] The sharing module determines the set of browsers that the second website account is allowed to share with, and the second website account is any one of the registered website accounts without password credentials held by the second browser;

[0018] The sharing module collects the private key of the second website account from the second browser; wherein the data transmitted between the sharing module and the second browser is encrypted with the second symmetric key, or the data transmitted between the sharing module and the second browser is encrypted with the other party's public key.

[0019] Optionally, the sharing module determines the set of browsers that the second website account is allowed to share with, including:

[0020] The sharing module displays a list of registered website accounts without password credentials held by the second browser;

[0021] For each website account in the list of website accounts, receive the set of browsers that the user selects that each website account is allowed to share.

[0022] Optionally, the terminal device further includes a security module. When the sharing module and the second browser mutually verify each other's identities through the application management module, the sharing module and the second browser perform key negotiation to obtain a shared secret value, and derive a second symmetric key based on the shared secret value, including:

[0023] When the sharing module and the second browser mutually verify each other's identities through the application management module and the security module verifies that the second browser is a secure browser, the sharing module and the second browser perform key negotiation to obtain a shared secret value, and derive a second symmetric key based on the shared secret value.

[0024] Optionally, after the sharing module collects the private key of the second website account from the second browser, the method further includes:

[0025] The sharing module establishes a list of associations between the second website account, the second browser, the private key of the second website account, and the set of browsers that the second website account is allowed to share.

[0026] Optionally, the method further includes:

[0027] When the private key of the second website account is updated, the second browser sends the updated private key of the second website account to the sharing module so that the sharing module updates the association list;

[0028] And / or, when the list of registered website accounts without password credentials held by the second browser is updated or the set of browsers that the second website account is allowed to share with is updated, the sharing module updates the association list and sends a change notification message to the browser that has been updated.

[0029] Optionally, the sharing module and the second browser perform key negotiation to obtain a shared secret value, and derive a second symmetric key based on the shared secret value, including:

[0030] The sharing module and the second browser each generate a public-private key pair. The sharing module and the second browser exchange their respective public keys, negotiate and generate a shared secret value based on the other party's public key and their own private key, and derive a second symmetric key based on the shared secret value.

[0031] A second aspect of this application provides a terminal device, including a sharing module, an application management module, and N browsers;

[0032] The first browser is used to log in to the first website account in the first browser, and in the case where the first browser has not registered the first website account without password credentials, to initiate a signature request to the sharing module. The first browser is any one of the N browsers, and the signature request carries the first website account.

[0033] The sharing module is used to request the application management module to verify the identity of the first browser;

[0034] The sharing module is further configured to, when the first browser is a legitimate browser and the first browser is in a browser set, use the account private key of the first website account to sign the data carried in the signature request to obtain a signature value, wherein the browser set is a set of browsers in which the first website account is allowed to share passwordless credentials.

[0035] The sharing module is also used to feed back the signature value to the first browser;

[0036] The first browser is further configured to transmit the signature value to the website corresponding to the first website account, so that the website corresponding to the first website account can use the account public key of the first website account to verify the signature value. If the verification is successful, it is determined that the first browser has successfully logged into the website corresponding to the first website account.

[0037] A third aspect of this application provides a terminal device including a processor and a memory, the memory being used to store a computer program, the computer program including program instructions, and the processor being configured to invoke the program instructions to execute the step instructions as described in the first aspect of this application.

[0038] A fourth aspect of this application provides a computer-readable storage medium storing a computer program for electronic data interchange, the computer program including program instructions that, when executed by a processor, cause the processor to perform the step instructions as described in the first aspect of this application.

[0039] A fifth aspect of this application provides a computer program product, wherein the computer program product includes a computer program, the computer program including program instructions, and the program instructions, when executed by a processor, cause the processor to perform the step instructions as described in the first aspect of this application.

[0040] In the website login method of this application embodiment, when logging into a first website account in a first browser, if the first browser has not registered passwordless credentials for the first website account, the first browser can initiate a signature request to the sharing module. The signature request carries the first website account. The sharing module verifies the legitimacy of the first browser's identity and, if the first browser belongs to the set of browsers where the first website account is allowed to share passwordless credentials, it can use the private key of the first website account to sign the data carried in the signature request to obtain a signature value. The first browser transmits the signature value to the website corresponding to the first website account. The website corresponding to the first website account uses the public key of the first website account to verify the signature value. If the verification is successful, it is determined that the first browser has successfully logged into the website corresponding to the first website account. In this embodiment, when the first browser does not have passwordless credentials for the first website account, if the first browser belongs to the set of browsers where the first website account is allowed to share passwordless credentials, the first browser can log in to the website corresponding to the first website account by signing the signature value of the account private key shared by other browsers (browsers that have registered passwordless credentials for the first website account). The first browser does not need to register passwordless credentials for the first website account, and can also log in to the website corresponding to the first website account based on passwordless credentials. It does not require repeated registration of passwordless credentials for the same website on different browsers, thereby improving the convenience of logging into the same website between different browsers and reducing the complexity of logging into the same website between browsers based on passwordless credentials. Attached Figure Description

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

[0042] Figure 1This is a schematic diagram of the software architecture of a terminal device provided in an embodiment of this application;

[0043] Figure 2 This is a flowchart illustrating a website login method provided in an embodiment of this application;

[0044] Figure 3 This is a flowchart illustrating another website login method provided in an embodiment of this application;

[0045] Figure 4 This is a schematic diagram of the structure of a terminal device provided in an embodiment of this application;

[0046] Figure 5 This is a schematic diagram of the structure of another terminal device provided in an embodiment of this application. Detailed Implementation

[0047] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0048] The terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0049] In this application, the reference to "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described in this application can be combined with other embodiments.

[0050] The terminal devices involved in the embodiments of this application may include portable computers (such as mobile phones), tablet computers, laptop computers, personal computers (PCs), wearable electronic devices (such as smartwatches), augmented reality (AR) / virtual reality (VR) devices, in-vehicle computers, etc. The embodiments of this application do not limit the specific form of the terminal device.

[0051] In this embodiment, when the first browser does not have passwordless credentials for a first website account, if the first browser belongs to the set of browsers where passwordless credentials for the first website account are allowed to be shared, the first browser can log in to the first website using a signature value obtained by signing the private key of the first website account shared by other browsers (browsers that have registered passwordless credentials for the first website account). The first browser does not need to register passwordless credentials for the first website account and can still log in based on passwordless credentials, eliminating the need to repeatedly register passwordless credentials for the same website on different browsers. This improves the convenience of logging into the same website across different browsers and reduces the complexity of passwordless credential-based login between browsers. This will be explained in detail below.

[0052] Currently, one of the mainstream passwordless credential support solutions in the industry is as follows: the browser holds the private key, and the website holds the public key. The process is roughly as follows: When a user registers for a passwordless credential (password key) on a website, the browser generates a public-private key pair for the user's website account. The browser holds the private key and registers the corresponding public key with the website (the website holds the public key). The browser can then initiate user authentication operations such as biometric identification and input of a personal identification number (PIN) by calling the corresponding application programming interface (API) on the device. After successful user authentication, the browser uses the private key to generate a signature value and sends it to the website. The website uses the public key to verify the signature, confirming the user's identity authentication result on the device. After successful verification, the user can log in to the website.

[0053] However, different browsers do not share their private key data. Due to commercial interests and the industry adoption of passkey solutions, different browsers store their own private key data, and there is currently no passkey data sharing solution.

[0054] When the range of websites for which a passkey has been registered differs across different browsers on the same device (for example, on browser A, the registered websites are websites 1, 2, 3, 4, and 5, while on browser B, the registered websites are websites 2, 3, 4, 5, and 6), the user experience of using the passkey function on the same device will be inconsistent. For instance, on the same website (e.g., website 1), accessing it via browser A allows for quick login with a passkey, while logging in via browser B requires entering a username and password. Furthermore, repeatedly registering passwordless credentials for the same website on different browsers on the same device is cumbersome and complex.

[0055] Please see Figure 1 , Figure 1 This is a schematic diagram of the software architecture of a terminal device provided in an embodiment of this application. For example... Figure 1 As shown, the software architecture includes a shared module, an application management module, and N browsers.

[0056] First browser (for example, Figure 1 Browser A in the first browser is used to log in to the first website account in the first browser, and in the case that the first browser has not registered the first website account without a password credential (passkey), it initiates a signature request to the sharing module. The first browser is any one of the N browsers.

[0057] The sharing module is used to request the application management module to verify the identity of the first browser;

[0058] The sharing module is further configured to use the private key of the first website account to sign the data carried in the signature request to obtain a signature value when the first browser is a legitimate browser and the first browser is in the browser set. The browser set is the set of browsers in which the first website account is allowed to share passwordless credentials.

[0059] The sharing module is also used to feed back the signature value to the first browser;

[0060] The first browser is further configured to transmit the signature value to the website corresponding to the first website account, so that the website corresponding to the first website account can use the account public key of the first website account to verify the signature value. If the verification is successful, it is determined that the first browser has successfully logged into the website corresponding to the first website account.

[0061] In this embodiment, a browser can be referred to as a browser application. The N browsers can be browsers installed on the terminal device. The N browsers can be all browsers installed on the terminal device, or they can be some of the browsers installed on the terminal device (e.g., browsers commonly used by the user); this embodiment does not impose any limitations.

[0062] N can be a positive integer greater than or equal to 2.

[0063] The application management module manages the various applications installed on the terminal device. It can record the identity information of each application (such as the application ID). The application module can record the IDs of various browsers, as well as the IDs of shared modules.

[0064] A sharing module, which can be a pre-installed software module in the operating system, offers high security. It can request assistance from the application management module on the terminal device to verify the authenticity of the applications used by various browsers. The application management module can record the identity information of each browser. The sharing module and the browsers can communicate with each other. The sharing module can store a list of registered website accounts without password credentials (password keys) for each browser, and it can also store a set of browsers authorized to share passwordless credentials for each registered website account.

[0065] Please refer to Table 1, which is a table showing the correspondence between various browsers stored in a shared module and the corresponding list of registered website accounts with passkeys provided in this application embodiment.

[0066] Table 1

[0067]

[0068]

[0069] As shown in Table 1, website account 1 registered a passkey on browser A, website account 2 registered a passkey on browser A, website account 3 registered a passkey on both browser A and browser B, website account 4 registered a passkey on both browser A and browser B, website account 5 registered a passkey on browser B, and website account 6 registered a passkey on browser B.

[0070] Please refer to Table 2, which is a table showing the correspondence between website accounts with registered passkeys for each browser and the corresponding set of browsers allowed to share passkeys, stored in a shared module according to an embodiment of this application.

[0071] Table 2

[0072] Registered passkey website account The collection of browsers that are allowed to share passkeys Website Account 1 Browser B, Browser C Website Account 2 Browser B, Browser C, Browser D Website Account 3 Browser C Website Account 4 Browser C, Browser D Website Account 5 Browser A, Browser C, Browser D Website Account 6 Browser C, Browser D … …

[0073] Combining Tables 1 and 2, it can be seen that website account 1 registered a passkey on browser A. When website account 1 registered the passkey on browser A, browser A held the private key of website account 1, and the website corresponding to website account 1 held the public key of website account 1. The set of browsers allowed for passkey sharing for website account 1 are: browser B and browser C. When logging into website account 1 on browser B or browser C, a signature request can be sent to the sharing module. The sharing module verifies the legitimacy of the browser, and if it detects that the browser is in the set of browsers allowed for passkey sharing for website account 1, it can use the private key of website account 1 to verify the data carried in the signature request, obtain a signature value, and pass the signature value to the browser. The browser then passes the signature value to the website corresponding to website account 1. The website uses the public key of website account 1 to verify the signature value. If the verification is successful, it is determined that the login to the website corresponding to website account 1 on the browser is successful. If the verification fails, the login to the website corresponding to website account 1 based on the passkey cannot be achieved on the browser.

[0074] Website account 2 registered a passkey on browser A. The browsers allowed for passkey sharing by website account 2 are: browsers B, C, and D. Website account 3 registered a passkey on both browsers A and B. The browser allowed for passkey sharing by website account 3 is: browser C. Website account 4 registered a passkey on both browsers A and B. The browsers allowed for passkey sharing by website account 4 are: browsers C and D. Website account 5 registered a passkey on browser B. The browsers allowed for passkey sharing by website account 5 are: browsers A, C, and D. Website account 6 registered a passkey on browser B. The browsers allowed for passkey sharing by website account 6 are: browsers C and D.

[0075] The shared module can store Tables 1 and 2 in a secure storage manner.

[0076] In this embodiment, when the first browser does not have passwordless credentials for the first website account, if the first browser belongs to the set of browsers where the first website account is allowed to share passwordless credentials, the first browser can log in to the website corresponding to the first website account by signing the signature value of the account private key shared by other browsers (browsers that have registered passwordless credentials for the first website account). The first browser does not need to register passwordless credentials for the first website account, and can also log in to the website corresponding to the first website account based on passwordless credentials. It does not require repeated registration of passwordless credentials for the same website on different browsers, thereby improving the convenience of logging into the same website between different browsers and reducing the complexity of logging into the same website between browsers based on passwordless credentials.

[0077] Optional, Figure 1 The software architecture can also include a security module.

[0078] The security module manages the security of various applications installed on the terminal device. It can record access behavior information of each application (such as accessed resource information, access frequency, access time, etc.). Resources can be system resources, such as camera, photo album, microphone, etc.

[0079] The sharing module can verify the browser's security through the security module, checking whether the browser is a malicious application, such as maliciously accessing unauthorized system resources.

[0080] Please see Figure 2 , Figure 2 This is a flowchart illustrating a website login method provided in an embodiment of this application. Figure 2 The method can be based on Figure 1 The implementation of the software architecture, such as Figure 2 As shown, the method may include the following steps.

[0081] 201. When logging into the first website account in the first browser, and the first browser does not have the password credentials to register the first website account, the first browser sends a signature request to the sharing module. The first browser is any one of N browsers, and the signature request carries the first website account.

[0082] In this embodiment, a website account is an account registered by a user on a website. Specifically, a first website account is an account registered by a user on a first website, and the first website is the website where the first website account is registered; the first website can also be referred to as the website corresponding to the first website account. For example, if a user logs into website X on browser A, the user login account registered on website X is the account registered on website X.

[0083] When a user registers a login account on website X using browser A, the specific process is as follows if a passwordless authentication method is used: Browser A generates a public-private key pair (the website account's public key and private key) for the user's account on website X. The browser holds the private key and registers the corresponding public key with website X (the website holds the public key). Browser A can then initiate user authentication operations such as biometric identification and PIN input by calling the corresponding application programming interface (API) on its device. After successful user authentication, browser A uses the private key to generate a signature value and sends it to website X. Website X uses the public key to verify the signature value. After successful verification, the user can log in to website X using the website account.

[0084] The first browser sends a signature request to the sharing module, requesting the sharing module to sign the data carried in the signature request using the private key of the first website account.

[0085] The signature request carries the primary website account. It may also carry login information related to that primary website account. This login information may include business information required for this website login, depending on the specific website's login policy.

[0086] The signature request can also carry the browser identification information (ID) of the first browser. The sharing module can determine the identity of the browser that sent the signature request based on the browser ID of the first browser.

[0087] Where N can be a positive integer greater than or equal to 2.

[0088] 202. The sharing module requests the application management module to verify the identity of the first browser. If the first browser is a legitimate browser and is in the browser set, the sharing module uses the private key of the first website account to sign the data carried in the signature request, obtains the signature value, and sends the signature value back to the first browser. The browser set is the set of browsers that the first website account is allowed to share without password credentials.

[0089] In this embodiment, after receiving the signature request from the first browser, the sharing module verifies the legitimacy of the first browser's identity. The application management module stores a set of browser IDs it manages. The sharing module can send the browser ID of the first browser to the application management module. If the browser ID of the first browser is in the set of browser IDs stored in the application management module, the application management module returns a first indication to the sharing module, indicating that the first browser is a legitimate browser. If the browser ID of the first browser is not in the set of browser IDs stored in the application management module, the application management module returns a second indication to the sharing module, indicating that the first browser is an illegitimate browser.

[0090] If the first browser is a legitimate browser, the sharing module, based on the first website account carried in the signature request, checks whether the first browser is in the set of browsers allowed to share without password credentials corresponding to the first website account stored in the sharing module (as shown in Table 2 above). If so, the sharing module uses the private key of the first website account to sign the data carried in the signature request, obtains the signature value, and sends the signature value back to the first browser.

[0091] In this embodiment, the sharing module requests the application management module to verify the identity of the first browser. The sharing module queries whether the first browser is in the set of browsers allowed to share credentials without passwords corresponding to the first website account. If the first browser is a legitimate browser and is in the set of browsers, the sharing module considers the first browser to be one of the browsers allowed to share credentials without passwords corresponding to the first website account. The sharing module can then respond to the signature request initiated by the first browser, using the account private key of the first website account to sign the data carried in the signature request, obtaining a signature value, and feeding the signature value back to the first browser. The entire signing process is completed on the sharing module side; the first browser does not need to hold the account private key of the first website account, nor does it need to sign itself. The sharing module is a pre-built module in the operating system, which can improve the security of the signature.

[0092] Optionally, if the first browser is an invalid browser, or if the first browser is not in the set of browsers allowed to share passwordless credentials for the first website account, the sharing module sends a notification message to the first browser rejecting the signature request. This can improve the security of logging into websites based on passwordless credentials.

[0093] 203. The first browser passes the signature value to the website corresponding to the first website account, so that the website corresponding to the first website account can use the public key of the first website account to verify the signature value. If the verification is successful, it is determined that the first browser has successfully logged into the website corresponding to the first website account.

[0094] In this embodiment, after receiving the signature value from the sharing module, the first browser can transmit the signature value to the website corresponding to the first website account. The website then uses the public key of the first website account to verify the signature value. If the verification is successful, the first browser is confirmed to have successfully logged into the website corresponding to the first website account. The entire verification process is completed on the website side corresponding to the first website account. Throughout the signing and verification process, the browser only acts as an intermediary for data transmission. The first browser does not need to hold the private key of the first website account, reducing the risk of the private key being leaked. Furthermore, the signing is performed by the pre-built sharing module in the operating system, which improves the security of the signature.

[0095] If the signature verification fails, the user will be unable to log in to the website corresponding to the first website account on the first browser without password credentials.

[0096] In this embodiment, when the first browser does not have passwordless credentials for the first website account, if the first browser belongs to the set of browsers where the first website account is allowed to share passwordless credentials, the first browser can log in to the website corresponding to the first website account by signing the signature value of the account private key shared by other browsers (browsers that have registered passwordless credentials for the first website account). The first browser does not need to register passwordless credentials for the first website account, and can also log in to the website corresponding to the first website account based on passwordless credentials. It does not require repeated registration of passwordless credentials for the same website on different browsers, thereby improving the convenience of logging into the same website between different browsers and reducing the complexity of logging into the same website between browsers based on passwordless credentials.

[0097] Optionally, in step 201, if the first browser logs into the first website account and the first browser does not have password credentials for registering the first website account, the first browser initiates a signature request to the sharing module, which may specifically include the following steps (101) and (102).

[0098] (101) When the first website account is logged in in the first browser, the first browser initiates user authentication;

[0099] (102) If the user authentication is successful and the first browser does not have passwordless credentials for registering the first website account, the first browser initiates a signature request to the sharing module.

[0100] In this embodiment, when a user logs into a first website account in a first browser, the first browser initiates user authentication. The browser can subsequently initiate user authentication operations such as biometric identification or requiring the user to input a personal identification number (PIN) by calling the corresponding application programming interface (API) on the device. Biometric identification can include any of the following methods: facial recognition, fingerprint recognition, palm print recognition, iris recognition, etc.

[0101] After user authentication is successful, and even if the first browser does not have passwordless credentials to register a first website account, the first browser can send a signature request to the sharing module, thereby improving the security of logging into the first website account without password credentials.

[0102] Optionally, if user authentication fails, the first browser will refuse the user's attempt to log in to the first website account using passwordless credentials. This can improve the security of logging into the website using passwordless credentials.

[0103] Optionally, the data transmitted between the sharing module and the first browser is encrypted using a first symmetric key, which is a symmetric key between the sharing module and the first browser.

[0104] Alternatively, the data transmitted between the sharing module and the first browser may be encrypted using the other party's public key.

[0105] In this embodiment of the application, all data transmitted between the sharing module and the first browser can be encrypted, thereby improving the security of data transmitted between the sharing module and each browser.

[0106] The security module can store the symmetric keys derived between the security module and each browser, and each browser can store the symmetric keys derived between itself and the security module.

[0107] In one embodiment, the data transmitted between the sharing module and the first browser can be encrypted using a symmetric key shared between the sharing module and the first browser.

[0108] In this embodiment, before executing step 201, the sharing module can negotiate keys with each browser to obtain a shared secret value, and derive a symmetric key based on the shared secret value. For example, the sharing module can negotiate keys with the first browser using a key negotiation algorithm to obtain a first shared secret value, and derive a first symmetric key based on the first shared secret value and a key derivation algorithm. When deriving a symmetric key based on the shared secret value, a different symmetric key can be derived each time, making the method of generating symmetric keys more flexible and more secure.

[0109] In another embodiment, the data transmitted between the sharing module and the first browser can be encrypted using the other party's public key.

[0110] In this embodiment of the application, before executing step 201, the sharing module can generate a public-private key pair with each browser, and exchange its public key with each browser. For example, the sharing module and the first browser can each generate a public-private key pair, and exchange their public keys. When transmitting data between the sharing module and the first browser, the other party's public key can be used for encryption.

[0111] Please see Figure 3 , Figure 3 This is a flowchart illustrating another website login method provided in an embodiment of this application. Figure 3 The method can be based on Figure 1 The implementation of the software architecture, such as Figure 3 As shown, the method may include the following steps.

[0112] 301. When the shared module and the second browser verify each other's identities as legitimate through the application management module, the shared module and the second browser negotiate a key to obtain a shared secret value. Based on the shared secret value, a second symmetric key is derived. The second symmetric key is the symmetric key between the shared module and the second browser. The second browser is any one of N browsers, where N is an integer greater than or equal to 2.

[0113] In this embodiment, the sharing module can request the application management module to verify whether the identity of each of the N browsers is legitimate, that is, to verify whether each browser is a legitimate browser. For details, please refer to the relevant description of step 202 above, which will not be repeated here.

[0114] The second browser can request the application management module to verify whether the shared module is a system-pre-installed application. System-pre-installed applications are software modules that are pre-installed in the terminal device's operating system.

[0115] The application management module stores the IDs of all applications it manages, including the ID of the shared module. If the application management module detects that the ID of the shared module is included among the application IDs it manages, it considers the shared module to be a pre-installed system application and its identity to be legitimate; if the application management module detects that the ID of the shared module is not included among the application IDs it manages, it considers the shared module to be a non-pre-installed system application and its identity to be illegitimate.

[0116] The sharing module and the second browser verify each other's identities through the application management module, indicating that the sharing module verifies the second browser as a legitimate browser through the application management module, and the second browser verifies the sharing module as a legitimate module through the application management module.

[0117] The process ends when the sharing module verifies the second browser as an illegitimate browser through the application management module, or when the second browser verifies the sharing module as an illegitimate module through the application management module.

[0118] The shared module can negotiate a key with each browser to obtain a shared secret value, and derive a symmetric key between the shared module and each browser based on the shared secret value.

[0119] The sharing module can use a key negotiation algorithm to negotiate a shared secret value with the second browser, and then derive a second symmetric key based on this shared secret value and a key derivation algorithm. The key negotiation algorithm can include internationally recognized algorithms, such as the elliptic curve Diffie-Hellman key exchange algorithm. The key derivation algorithm can also be an internationally recognized algorithm, such as the HMAC-based key derivation function (HKDF) algorithm.

[0120] The sharing module and the second browser perform key negotiation to obtain a shared secret value, and derive a second symmetric key based on the shared secret value, including:

[0121] The sharing module and the second browser each generate a public-private key pair. The sharing module and the second browser exchange their respective public keys, negotiate and generate a shared secret value based on the other party's public key and their own private key, and derive a second symmetric key based on the shared secret value.

[0122] In this embodiment, the sharing module and the second browser can each generate a public-private key pair based on an asymmetric encryption algorithm (e.g., RSA). The sharing module holds its own private key and sends its own public key to the second browser. The second browser holds its own private key and sends its own public key to the sharing module. The sharing module generates a shared secret value based on the other party's public key and its own private key, or the second browser also generates a secret shared value based on the other party's public key and its own private key. After generating the secret shared value, a second symmetric key is derived from the shared secret value.

[0123] In this method, when deriving a second symmetric key based on a shared secret value, a different symmetric key can be derived each time, making the key generation more flexible and more secure. For example, after the sharing module and the second browser have negotiated once, they can derive the key based on the shared secret value. Each subsequent generation of the second symmetric key can incorporate relevant information from each session (such as session parameters), using this information as the derivation parameters to generate a unique second symmetric key each time.

[0124] The second browser can be different from or the same as the first browser.

[0125] Optionally, in step 301, if the sharing module and the second browser mutually verify each other's identities through the application management module, the sharing module and the second browser perform key negotiation to obtain a shared secret value, and derive a second symmetric key based on the shared secret value, which may include the following steps:

[0126] When the sharing module and the second browser verify each other's identities through the application management module and the security module verifies that the second browser is a secure browser, the sharing module and the second browser negotiate a key to obtain a shared secret value, and derive a second symmetric key based on the shared secret value.

[0127] In this embodiment, after the sharing module and the second browser verify each other's identities as legitimate through the application management module, the security module can also verify whether the second browser is a secure browser. If the second browser is a secure browser, the sharing module and the second browser can negotiate a key.

[0128] The security module manages the security of various applications installed on the terminal device. It can record access behavior information for each application (e.g., accessed resources, access frequency, access time, etc.). The security module can analyze the access behavior information of a secondary browser to determine whether it is a secure browser. The security management module uses a security detection model to detect malicious behavior in the secondary browser based on its expected access capabilities and access behavior information. For example, if a secondary browser does not normally have the ability to access the photo album, and its expected access capabilities do not include this ability, then if the secondary browser accesses the photo album, it is considered to be engaging in malicious behavior and is an insecure browser.

[0129] This process ends when the sharing module verifies through the security module that the second browser is not a secure browser.

[0130] This application embodiment can verify whether the second browser has malicious behavior through the security module, thereby avoiding the security module from performing key negotiation with the browser with malicious behavior, which can improve the security of browser login.

[0131] 302, The sharing module collects a list of registered website accounts without password credentials held by the second browser.

[0132] In this embodiment, the sharing module sends a request to the second browser to collect a list of registered website accounts without password credentials held by the second browser. Upon receiving the request, the second browser can send a list of all website accounts registered without password credentials on the second browser (as shown in a row of Table 1 above) to the sharing module. Alternatively, the second browser can store a list of all website accounts registered without password credentials on the second browser (as shown in a row of Table 1 above), and upon receiving the request, send this list to the sharing module.

[0133] 303, The sharing module determines the set of browsers that the second website account is allowed to share with. The second website account is any one of the registered website accounts without password credentials held by the second browser.

[0134] In this embodiment, after receiving Table 1 above, the sharing module can determine which browsers each website has registered passwordless credentials (passkeys). The sharing module can default to selecting browsers on which each website account is allowed to share, specifically those browsers on the terminal device that do not have passwordless credentials (passkeys) registered for that website account. Alternatively, the sharing module can receive user selections to determine the set of browsers allowed to share for each website account.

[0135] It should be noted that the set of browsers that the second website account is allowed to share with can be either an empty set or a non-empty set. If the set of browsers that the second website account is allowed to share with is empty, it means that the user does not allow the second website account to be shared with other browsers (browsers other than the second browser) using the passkey.

[0136] Optionally, in step 303, the sharing module determines the set of browsers that the second website account is allowed to share with, which may include the following steps (3031) and (3032).

[0137] (3031) The sharing module displays a list of registered website accounts without password credentials held by the second browser;

[0138] (3032) For each website account in the list of website accounts, the sharing module receives the set of browsers that the user selects for sharing each website account.

[0139] In this embodiment, the sharing module displays a list of registered website accounts without password credentials held by the second browser (as shown in a row of Table 1 above). When the user selects each website account in the list, the user is prompted to manually select the set of browsers that the website account is allowed to share with. The module displays all browsers that do not have the website account registered with password credentials for the user to choose from. The user can then select the set of browsers that the website account is allowed to share with.

[0140] After executing step 303, the sharing module can store a table (as shown in Table 2 above) that corresponds to registered website accounts without password credentials and the corresponding set of browsers that are allowed to share without password credentials. Each row of the table represents the set of browsers that a website account is allowed to share with.

[0141] 304, The sharing module collects the private key of the second website account from the second browser; wherein the data transmitted between the sharing module and the second browser is encrypted with the second symmetric key, or the data transmitted between the sharing module and the second browser is encrypted with the other party's public key.

[0142] In this embodiment of the application, the sharing module initiates a request to the second browser to collect the private key of the second website account. After receiving the request, the second browser can send the private key of the second website account to the sharing module.

[0143] In one embodiment, the data transmitted between the sharing module and the second browser can be encrypted using a second symmetric key (the symmetric key between the sharing module and the second browser).

[0144] In this embodiment of the application, before executing step 304, in step 301, the sharing module can perform key negotiation with each browser to obtain a shared secret value, and derive a symmetric key based on the shared secret value. For example, the sharing module can perform key negotiation with the second browser using a key negotiation algorithm to obtain a second shared secret value, and derive a second symmetric key based on the second shared secret value and a key derivation algorithm.

[0145] In another embodiment, the data transmitted between the sharing module and the second browser can be encrypted using the other party's public key.

[0146] In this embodiment of the application, before executing step 304, in step 301, the sharing module can generate a public-private key pair with each browser, and the sharing module exchanges its public key with each browser. For example, the sharing module and the second browser generate a public-private key pair respectively, and the sharing module and the second browser exchange their public keys. When transmitting data between the sharing module and the second browser, the other party's public key can be used for encryption.

[0147] Optionally, after performing step 304, steps 201 to 203 can also be performed.

[0148] In this embodiment, when the sharing module and the second browser mutually verify each other's identities through the application management module, the sharing module and the second browser negotiate a key to obtain a shared secret value. A second symmetric key is derived based on this shared secret value. The sharing module collects a list of registered website accounts without password credentials held by the second browser. The sharing module determines the set of browsers that the second website account is allowed to share with. The second website account is any one of the registered website accounts without password credentials held by the second browser. The sharing module collects the private key of the second website account from the second browser. The sharing module can store the set of browsers that each website account is allowed to share with, as well as the private key of each website account. This prepares for subsequent logins by browsers without password credentials that have not registered a specific website account, thereby improving the convenience of logging into the same website across different browsers and reducing the complexity of passwordless login between browsers.

[0149] Optionally, after executing 304, you can also execute step 305.

[0150] 305. The sharing module establishes a list of associations between the second website account, the second browser, the private key of the second website account, and the set of browsers that the second website account is allowed to share.

[0151] Please refer to Table 3. Table 3 is a list of associations between various website accounts stored in a shared module according to an embodiment of this application, browsers that have registered the website accounts without password credentials, the account private keys of the website accounts, and the set of browsers that the website accounts are allowed to share.

[0152] Table 3

[0153]

[0154]

[0155] As shown in Table 3, website account 1 registered a passkey on browser A. Website account 1's private key is priv1. The browsers allowed for passkey sharing for website account 1 are: browsers B and C. Website account 2 registered a passkey on browser A. Website account 2's private key is priv2. The browsers allowed for passkey sharing for website account 2 are: browsers B, C, and D. Website account 3 registered a passkey on both browsers A and B. Website account 3's private key is priv3. The browsers allowed for passkey sharing for website account 3 are: browser C. Website account 4 registered a passkey on both browsers A and B. Website account 4's private key is priv4. The browsers allowed for passkey sharing for website account 4 are: browsers C and D. Website account 5 registered a passkey on browser B. Website account 5's private key is priv5. The browsers allowed for passkey sharing for website account 5 are: browsers A, C, and D. Website account 6 registered a passkey on browser B. The private key of website account 6 is priv6. The set of browsers that website account 6 is allowed to share its passkey with are: browser C and browser D.

[0156] After executing step 305, the sharing module stores a list of associations between the second website account, the second browser, the private key of the second website account, and the set of browsers that the second website account is allowed to share with. The sharing module can store the above association list in a secure manner.

[0157] Optionally, after performing step 305, steps 201 to 203 can also be performed.

[0158] After executing step 305, when executing step 202, the first browser can be verified according to Table 3 above to see if it is in the set of browsers where the first website account is allowed to share passwordless credentials.

[0159] Optionally, after performing step 305, step 306 can also be performed.

[0160] 306. When the private key of the second website account is updated, the second browser sends the updated private key of the second website account to the sharing module so that the sharing module updates the association list.

[0161] And / or, when the list of registered website accounts without password credentials held by the second browser is updated, or when the set of browsers that the second website account is allowed to share is updated, the sharing module updates the association list and sends a change notification message to the browser that has been updated.

[0162] In this embodiment, Table 3 may change. When the private key of a website account is updated (the key changes), a browser that has registered the website account but has no password credentials can send the updated private key to the sharing module, and the sharing module can update Table 3. When the list of registered website accounts without password credentials held by the browser is updated (the list of website accounts with registered password credentials held by the browser is updated, as shown in Table 1 above), the sharing module can update Table 3. When the set of browsers that allow sharing of website accounts is updated, the sharing module can update Table 3.

[0163] Optionally, after performing step 306, steps 201 to 203 can also be performed.

[0164] In this embodiment of the application, when the list of registered website accounts without password credentials held by the second browser is updated or the set of browsers that the second website account is allowed to share is updated, a change notification message can also be sent to the browser that has been updated, so as to notify the browser in a timely manner.

[0165] This application proposes a method for sharing passkey data between browsers based on a shared module, summarized as follows.

[0166] The sharing module on the terminal device requests the application management module on the terminal device to help verify the authenticity of the application identities of each browser on the terminal device and record the identity information of each browser; then the sharing module requests the security module on the terminal device to help confirm the security of each browser application.

[0167] When the sharing module on the terminal device sends a request to each browser to collect information, each browser requests the application management module on the terminal device to help verify that the application identity of the sharing module is a pre-installed system application.

[0168] The sharing module and each browser randomly generate and store a public-private key pair. After the sharing module and each browser mutually verify the authenticity of each other's application identities, the sharing module and each individual browser exchange public keys and negotiate a shared secret value to derive a symmetric key.

[0169] When subsequent data is transmitted between the shared module and various browsers, the derived symmetric key is used for encryption and decryption of the transmitted data.

[0170] The sharing module obtains a list of website accounts with registered passkeys held by each browser and allows users to select the range of passkey accounts to be shared and the range of browsers that each shared passkey account is allowed to access.

[0171] The sharing module collects the private key information of the shared passkey accounts from the corresponding browsers based on the user-selected range of shared passkey accounts. It then allows browsers within the user-selected range to access the shared passkey data. The sharing module verifies the current browser's identity and generates a signature value for the current browser using the private key of the website account sharing the passkey, enabling the browser to easily log in to the website account sharing the passkey.

[0172] This browser-to-browser passkey data sharing method based on a shared module can specifically include the following seven parts.

[0173] The first part involves the shared module (share_manager) verifying the identity of each browser. This first part may include steps (11) to (15) below.

[0174] (11) The terminal equipment OEM manufacturer pre-installs a shared module (denoted as share_manager) in the device operating system.

[0175] (12) share_manager requests the application management module on the terminal device to help verify the application identity of different browsers on the terminal device (supporting two or more browsers, hereinafter taking two browsers as an example, referred to as browserA and browserB respectively), and records the identity information of browserA and browserB (referred to as browserA_ID and browserB_ID respectively).

[0176] (13) share_manager requests the security module on the terminal device to help confirm the security of browserA and browserB, and to confirm whether browserA and browserB are malicious applications.

[0177] (14) If the identities of browserA and browserB are genuine and no security risks are detected (they are not malicious applications), share_manager initiates a key negotiation request to browserA and browserB.

[0178] (15) BrowserA and BrowserB respectively request the application management module on the device to help verify whether the application identity of share_manager is a pre-installed system application.

[0179] The second part involves key negotiation between the shared module (share_manager) and each browser. This second part may include steps (21) to (23) below.

[0180] (21) After the share_manager and browserA and browserB confirm the authenticity of each other's application identities and there are no security risks, share_manager, browserA and browserB will randomly generate a pair of public and private keys and store them.

[0181] The public-private key pair generated by share_manager is denoted as share_pub and share_priv. The public-private key pair generated by browserA is denoted as A_pub and A_priv. The public-private key pair generated by browserB is denoted as B_pub and B_priv.

[0182] (22) share_manager exchanges public keys with each browser (browserA, browserB) on the terminal device, performs key negotiation, and derives symmetric keys.

[0183] The symmetric key derived between share_manager and browserA is denoted as A_DEK, and the symmetric key derived between share_manager and browserB is denoted as B_DEK.

[0184] (23) share_manager securely stores the symmetric keys between each browser, and each browser stores the symmetric keys derived between itself and share_manager.

[0185] The third part involves the sharing module (share_manager) collecting a list of passkey accounts from the browser. This third part may include steps (31) through (35).

[0186] (31) Based on the browser application information browserA_ID and browserB_ID recorded in step (12) on the terminal device, share_manager sends a request to the corresponding browsers browserA and browserB to collect the website account information of the registered passkey held by browserA and browserB.

[0187] (32) BrowserA and BrowserB respectively request the application management module on the device to verify whether the received request comes from the real share_manager.

[0188] (33) After the share_manager identity is verified, browserA and browserB respectively organize the website accounts with registered passkeys they hold and form a list (the information lists formed by browserA and browserB are respectively denoted as listA and listB). listA and listB may contain website accounts or may contain website accounts and the account IDs corresponding to the website accounts.

[0189] (34) BrowserA and BrowserB encrypt listA and listB respectively using A_DEK and B_DEK, and then pass the ciphertext of listA and listB to share_manager respectively.

[0190] (35) share_manager uses A_DEK and B_DEK respectively to decrypt the received ciphertext and obtain the plaintext data listA and listB.

[0191] In the fourth part, the user selects the shared passkey range and the target shared browser range. The fourth part may include the following steps (41) to (44).

[0192] (41) share_manager calls the relevant APIs on the terminal device to verify the user's identity through biometrics and other means.

[0193] (42) After the user is authenticated, share_manager displays listA, listB, and the list of all browsers on the terminal device (i.e., browserA and browserB) to the user.

[0194] (43) The user selects the passkey website account (denoted as share_accounts) to be shared from the account information contained in listA and listB, and selects the range of browsers (denoted as share_browsers) to be allowed to share share_accounts from the list of all verified browsers on the terminal device.

[0195] (44) After the user confirms the scope of share_browsers, share_manager requests the security module on the terminal device to confirm the security of the browser applications in share_browsers and whether they contain malware.

[0196] If malware is found in share_browsers, it will be removed from share_browsers and the user will be notified promptly. If no malware is found in share_browsers, no action will be taken.

[0197] Part 5, the sharing module (share_manager) collects the shared passkey account private key. Part 5 may include the following steps (51) to (56).

[0198] (51) Based on share_accounts, share_manager requests the share_accounts passkey private key (denoted as shared_priv) from the corresponding browsers (denoted as source_browsers) that hold the passkey private key of share_accounts.

[0199] (52) Source_browsers Each browser calls the relevant APIs for biometric identification and other methods to verify the user's identity and confirm the scope of the share_accounts that the user is about to share.

[0200] (53) After the user is authenticated and the passkey sharing scope is confirmed to the user, source_browsers use the derived symmetric key to encrypt shared_priv of share_accounts and send the ciphertext to share_manager.

[0201] (54) share_manager uses the derived symmetric key to decrypt and store shared_priv.

[0202] (55) share_manager keeps a record and maintains a list of relationships between share_accounts, source_browsers, shared_priv, and share_browsers (denoted as share_list).

[0203] (56) The share_manager informs the share_browsers of the range of share_accounts that are allowed to be used, based on the user's selection.

[0204] Part VI, the share module (share_manager) provides share_browsers with private key signing for share_accounts. Part VI may include steps (61) through (66) below.

[0205] (61) When a user logs into share_accounts in share_browsers, share_browsers initiates biometric identification and other methods to verify the user's identity.

[0206] (62) After the user identity verification is successful, share_browsers sends a signature request to share_manager, passing the share_accounts to be logged in this time and other relevant information for this login.

[0207] (63) share_manager requests the application management module on the device to help verify that this login request comes from the real share_browsers.

[0208] (64) After share_browsers are authenticated, share_manager determines whether share_browsers are allowed to share_priv of the share_accounts to be logged in this time based on the maintained share_list.

[0209] If not allowed, share_manager rejects the signature request from share_browsers.

[0210] If permitted, proceed to step (65).

[0211] (65) share_manager uses shared_priv to sign the data passed to share_browsers and returns the signature value to share_browsers.

[0212] (66) share_browsers sends the signature value to the website corresponding to share_accounts. The website will use the public key corresponding to shared_priv to verify the signature. Once the signature is successfully verified, the login is confirmed to be successful.

[0213] Part 7, Shared data refresh of the shared module (share_manager). Part 7 may include the following steps (71) to (72).

[0214] (71) When the shared_priv shared by source_browsers is refreshed, source_browsers send the updated data to share_manager.

[0215] (72) When a user changes the scope of the shared account and the shared browser, source_browsers collects new data from the corresponding browser or deletes the shared data it maintains, refreshes the share_list, and notifies the corresponding browser of the changes.

[0216] The encryption algorithm used in the embodiments of this application can be flexibly selected, for example, the international standard AES algorithm can be used. The key negotiation algorithm used in this application can also be flexibly selected, for example, the international standard ECDH algorithm can be used.

[0217] This application embodiment supports users sharing the passkey of some website accounts across different browsers, improving the user experience of the passkey function on different browsers, reducing the tedious operation of repeatedly registering the passkey for the same website on different browsers, and improving the device's support for the passkey function and the ease of use of the passkey function.

[0218] In this embodiment, the user can choose the range of shared passkeys and the range of browsers that are allowed to share the passkeys, which flexibly supports user configuration and improves flexibility.

[0219] This application provides a shared module on the device to manage data uniformly, rather than requiring browsers to provide data to each other. This avoids direct interaction between different browsers and the need to modify browser function modules, improves the compatibility of the solution, and facilitates its promotion among many browsers.

[0220] This application avoids browsers providing data to each other, avoids the possibility of data pollution between different browsers, and avoids potential negative impacts on browser business interests caused by data interaction between browsers.

[0221] The embodiments of this application adopt a key negotiation method to negotiate and derive encryption keys for transmitting data between encrypted applications, thereby improving data confidentiality and security during data transmission.

[0222] The above primarily describes the solutions of the embodiments of this application from the perspective of the method execution process. It is understood that, in order to achieve the above functions, the terminal device includes the corresponding hardware structure and / or software modules for executing each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the various examples described in the embodiments provided herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0223] This application embodiment can divide the terminal device into functional units according to the above method example. For example, each function can be divided into a separate functional unit, or two or more functions can be integrated into one processing unit. The integrated unit can be implemented in hardware or as a software functional unit. It should be noted that the unit division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0224] Please see Figure 4 , Figure 4 This is a schematic diagram of the structure of a terminal device provided in an embodiment of this application. The terminal device 400 may include a sharing module 410, an application management module 420, and N browsers; the N browsers include a first browser 431 and a second browser 432. The first browser 431 and the second browser 432 may be the same browser or different browsers.

[0225] The first browser 431 is used to log in to the first website account in the first browser 431, and in the case where the first browser 431 has not registered the first website account without password credentials, it sends a signature request to the sharing module 410. The first browser 431 is any one of the N browsers, and the signature request carries the first website account.

[0226] The sharing module 410 is used to request the application management module 420 to verify the identity of the first browser 431;

[0227] The sharing module 410 is further configured to, when the first browser 431 is a legitimate browser and the first browser 431 is in the browser set, use the account private key of the first website account to sign the data carried in the signature request to obtain a signature value, wherein the browser set is the set of browsers in which the first website account is allowed to share passwordless credentials.

[0228] The sharing module 410 is also used to feed back the signature value to the first browser 431;

[0229] The first browser 431 is further configured to transmit the signature value to the website corresponding to the first website account, so that the website corresponding to the first website account can use the account public key of the first website account to verify the signature value. If the verification is successful, it is determined that the first browser 431 has successfully logged into the website corresponding to the first website account.

[0230] Optionally, the first browser 431 is also used to initiate user authentication when logging into the first website account in the first browser 431;

[0231] The first browser 431 is further configured to initiate a signature request to the sharing module 410 when the user authentication is successful and the first browser 431 has no password credentials for registering the first website account.

[0232] Optionally, the signature request carries the first website account and login information related to the first website account.

[0233] Optionally, the data transmitted between the sharing module 410 and the first browser 431 is encrypted using a first symmetric key, which is the symmetric key between the sharing module 410 and the first browser 431.

[0234] Alternatively, the data transmitted between the sharing module 410 and the first browser 431 may be encrypted using the other party's public key.

[0235] Optionally, the sharing module 410 is further configured to, when the sharing module 410 and the second browser 432 mutually verify each other's identities through the application management module 420, perform key negotiation with the second browser 432 to obtain a shared secret value, and derive a second symmetric key based on the shared secret value. The second symmetric key is the symmetric key between the sharing module 410 and the second browser 432, where the second browser 432 is any one of the N browsers, and N is an integer greater than or equal to 2.

[0236] The sharing module 410 is also used to collect a list of registered website accounts without password credentials held by the second browser 432 from the second browser 432.

[0237] The sharing module 410 is further configured to determine the set of browsers that the second website account is allowed to share, wherein the second website account is any one of the registered website accounts without password credentials held by the second browser 432;

[0238] The sharing module 410 is also used to collect the private key of the second website account from the second browser 432; wherein the data transmitted between the sharing module 410 and the second browser 432 is encrypted with the second symmetric key, or the data transmitted between the sharing module 410 and the second browser 432 is encrypted with the other party's public key.

[0239] Optionally, the sharing module 410 is also used to display a list of registered website accounts without password credentials held by the second browser 432;

[0240] The sharing module 410 is also configured to receive, for each website account in the list of website accounts, a set of browsers that the user selects for sharing.

[0241] Optionally, the sharing module 410 is further configured to generate a public-private key pair with the second browser 432 respectively;

[0242] The sharing module 410 is also used to exchange public keys with the second browser 432, generate a shared secret value based on the other party's public key and its own private key, and derive a second symmetric key based on the shared secret value.

[0243] Optionally, the terminal device further includes a security module 440;

[0244] The sharing module 410 is further configured to perform key negotiation with the second browser 432 to obtain a shared secret value, and to derive a second symmetric key based on the shared secret value, when the application management module 420 verifies that the other party's identity is legitimate and the security module 440 verifies that the second browser 432 is a secure browser.

[0245] Optionally, the sharing module 410 is further configured to establish a list of associations between the second website account, the second browser 432, the account private key of the second website account, and the set of browsers that the second website account is allowed to share.

[0246] Optionally, the second browser 432 is used to send the updated private key of the second website account to the sharing module 410 when the private key of the second website account is updated, so that the sharing module 410 updates the association list;

[0247] The sharing module 410 is also used to update the association list and send a change notification message to the browser that has been updated when the list of registered website accounts without password credentials held by the second browser 432 is updated or the set of browsers that the second website account is allowed to share is updated.

[0248] In this embodiment, the sharing module 410, application management module 420, and security module 440 can be processors in a terminal device. The first browser 431 and the second browser 432 can be browser applications installed on the terminal device.

[0249] Figure 4 For a detailed implementation of the terminal device 400 shown, please refer to [link / reference]. Figures 2 to 3 The method embodiments shown are not described in detail here.

[0250] In this embodiment, when the first browser does not have passwordless credentials for the first website account, if the first browser belongs to the set of browsers where the first website account is allowed to share passwordless credentials, the first browser can log in to the website corresponding to the first website account by signing the signature value of the account private key shared by other browsers (browsers that have registered passwordless credentials for the first website account). The first browser does not need to register passwordless credentials for the first website account, and can also log in to the website corresponding to the first website account based on passwordless credentials. It does not require repeated registration of passwordless credentials for the same website on different browsers, thereby improving the convenience of logging into the same website between different browsers and reducing the complexity of logging into the same website between browsers based on passwordless credentials.

[0251] Please see Figure 5 , Figure 5 This is a schematic diagram of the structure of another terminal device provided in an embodiment of this application, such as... Figure 5 As shown, the terminal device 500 includes a processor 501 and a memory 502, which can be interconnected via a communication bus 503. The communication bus 503 can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The communication bus 503 can be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, Figure 5The bus is represented by a single thick line, but this does not indicate that there is only one bus or one type of bus. Memory 502 stores computer programs, which include program instructions. Processor 501 is configured to call these program instructions, which include instructions for execution. Figures 2 to 3 Some or all of the steps in the method shown.

[0252] Memory 502 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital versatile optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto. Memory may exist independently and be connected to the processor via a bus. Memory may also be integrated with the processor.

[0253] The terminal device 500 may also include a communication module, which may include a communication chip, a radio frequency transceiver, a radio frequency front-end module, an antenna, etc.

[0254] The terminal device 500 may also include a display module.

[0255] In this embodiment, when the first browser does not have passwordless credentials for the first website account, if the first browser belongs to the set of browsers where the first website account is allowed to share passwordless credentials, the first browser can log in to the website corresponding to the first website account by signing the signature value of the account private key shared by other browsers (browsers that have registered passwordless credentials for the first website account). The first browser does not need to register passwordless credentials for the first website account, and can also log in to the website corresponding to the first website account based on passwordless credentials. It does not require repeated registration of passwordless credentials for the same website on different browsers, thereby improving the convenience of logging into the same website between different browsers and reducing the complexity of logging into the same website between browsers based on passwordless credentials.

[0256] This application also provides a computer-readable storage medium storing a computer program for electronic data interchange, which causes a computer to perform some or all of the steps of any of the website login methods described in the above method embodiments.

[0257] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0258] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0259] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some interfaces; indirect couplings or communication connections between devices or units may be electrical or other forms.

[0260] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0261] Furthermore, the functional units in the various embodiments of the application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software program module.

[0262] If the integrated unit is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, terminal device, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0263] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage device, which may include: a flash drive, a read-only memory, a random access memory, a magnetic disk, or an optical disk, etc.

[0264] The embodiments of this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A website login method, characterized in that, The method is applied to a terminal device, the terminal device including a sharing module, an application management module, and N browsers, and the method includes: When a user logs into a first website account in a first browser, and the first browser has not registered a password for the first website account, the first browser sends a signature request to the sharing module. The first browser is any one of the N browsers, and the signature request carries the first website account. The sharing module requests the application management module to verify the identity of the first browser. After the application management module verifies that the first browser is a legitimate browser, and the sharing module queries the browser set, the sharing module uses the account private key of the first website account to sign the data carried in the signature request to obtain a signature value. The sharing module then feeds back the signature value to the first browser. The browser set is the set of browsers where the first website account is allowed to share without password credentials. The first browser transmits the signature value to the website corresponding to the first website account, so that the website corresponding to the first website account can use the account public key of the first website account to verify the signature value. If the verification is successful, it is determined that the first browser has successfully logged into the website corresponding to the first website account.

2. The method according to claim 1, characterized in that, In the case where the first browser logs into the first website account and the first browser has not registered the first website account with passwordless credentials, the first browser initiates a signature request to the sharing module, including: When the user logs into the first website account in the first browser, the first browser initiates user authentication. If the user authentication is successful and the first browser does not have password credentials for the first website account, the first browser initiates a signature request to the sharing module.

3. The method according to claim 1, characterized in that, The data transmitted between the sharing module and the first browser is encrypted using a first symmetric key, which is the symmetric key between the sharing module and the first browser. Alternatively, the data transmitted between the sharing module and the first browser may be encrypted using the other party's public key.

4. The method according to any one of claims 1 to 3, characterized in that, Before the first browser sends a signature request to the sharing module, the method further includes: When the sharing module and the second browser verify each other's identities as legitimate through the application management module, the sharing module and the second browser perform key negotiation to obtain a shared secret value. Based on the shared secret value, a second symmetric key is derived. The second symmetric key is the symmetric key between the sharing module and the second browser. The second browser is any one of the N browsers, where N is an integer greater than or equal to 2. The sharing module collects a list of registered website accounts without password credentials held by the second browser. The sharing module determines the set of browsers that the second website account is allowed to share with, and the second website account is any one of the registered website accounts without password credentials held by the second browser; The sharing module collects the private key of the second website account from the second browser; wherein the data transmitted between the sharing module and the second browser is encrypted with the second symmetric key, or the data transmitted between the sharing module and the second browser is encrypted with the other party's public key.

5. The method according to claim 4, characterized in that, The sharing module determines the set of browsers that the second website account is allowed to share with, including: The sharing module displays a list of registered website accounts without password credentials held by the second browser; For each website account in the list of website accounts, receive the set of browsers that the user selects that each website account is allowed to share.

6. The method according to claim 4, characterized in that, The terminal device further includes a security module. When the sharing module and the second browser mutually verify each other's identities through the application management module, the sharing module and the second browser perform key negotiation to obtain a shared secret value, and derive a second symmetric key based on the shared secret value, including: When the sharing module and the second browser mutually verify each other's identities through the application management module and the security module verifies that the second browser is a secure browser, the sharing module and the second browser perform key negotiation to obtain a shared secret value, and derive a second symmetric key based on the shared secret value.

7. The method according to claim 4, characterized in that, After the sharing module collects the private key of the second website account from the second browser, the method further includes: The sharing module establishes a list of associations between the second website account, the second browser, the private key of the second website account, and the set of browsers that the second website account is allowed to share.

8. The method according to claim 7, characterized in that, The method further includes: When the private key of the second website account is updated, the second browser sends the updated private key of the second website account to the sharing module so that the sharing module updates the association list; And / or, when the list of registered website accounts without password credentials held by the second browser is updated or the set of browsers that the second website account is allowed to share with is updated, the sharing module updates the association list and sends a change notification message to the browser that has been updated.

9. A terminal device, characterized in that, The device includes a processor and a memory, the memory being used to store a computer program, the computer program including program instructions, and the processor being configured to invoke the program instructions to perform the method as described in any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer program including program instructions that, when executed by a processor, cause the processor to perform the method as described in any one of claims 1 to 8.

Images