A honeyword-based password leakage query system

Abstract

The application relates to a honeyword-based password leakage query system, which comprises a server, a Honeychecker and a client, a query process comprises two stages of a preprocessing stage and an online query stage, the server stores original leakage data sets, the original leaked data is subjected to encryption processing in the preprocessing stage, and the encrypted data is stored in the background database of the server; in addition, the server also needs to generate honeywords in the preprocessing stage, uses the honeywords to assist in detecting data leakage of the background database, and gives the index value of the original leaked password and the variant of the original leaked password to the Honeychecker for storage; the server completes interaction with the client in the online query stage, and informs the client of the leakage situation of the input credential.

Description

Technical Field

[0001] This invention belongs to the field of information security technology and relates to a method for detecting computer data leaks, specifically a password leak query system based on honeywords. Background Technology

[0002] As the most widely used authentication method, passwords are simple to use, inexpensive, and easy to change, and will remain the primary authentication method for the foreseeable future. Therefore, password security holds a fundamental and crucial position in the field of cyberspace security. However, password-based authentication systems require maintaining a user password database on the server side, making it a highly valuable target for attackers. In recent years, attacks such as credential stuffing and data breaches have led to the leakage of large amounts of password data, inevitably threatening user privacy and security. Password security faces severe challenges.

[0003] More seriously, many websites often fail to detect these password leaks in a timely manner, giving attackers ample time to exploit the leaked data for attacks or even to profit from it online. For example, the 2008 Myspace data breach involving 360 million records was only discovered eight years later; the 2014 Yahoo password breach involving 500 million records was only discovered after some of the data was sold on the dark web in 2016. By then, notifying users to update their passwords is too late. Therefore, timely reporting of password leaks to users and mitigating the harm caused by such leaks is of paramount importance.

[0004] To enable timely detection of password file leaks, Juels and Rivest first proposed the concept of "honeywords" in 2013. This scheme associates a set of honeywords with each user's account. Even if an attacker steals the password file and successfully recovers the plaintext password through offline guessing, the real password remains hidden within a set of honeywords. When the honeyword generation algorithm is sufficiently sophisticated to be indistinguishable from the real password, online interaction with the target server becomes the only way for the attacker to distinguish the real password. Thus, online login attempts not only significantly slow down the attacker's guessing speed, but the server can also detect the password file leak through the honeywords used by the attacker during login.

[0005] To defend against credential stuffing attacks, third-party services, known as C3 services, have been continuously proposed to check whether user passwords have been compromised. For example, Troy Hunt and Cloudflare deployed HaveIBeenPWned (HIBP) in 2018, and subsequently, websites such as Firefox and 1Password also deployed the service. In 2019, Google launched a password checking extension, Password Checkup (GPC), in Chrome to help Chrome users check whether their usernames and passwords are in Google's database of compromised credentials. In 2021, Microsoft introduced Microsoft Password Monitor in Edge, reportedly the first consumer application to use homomorphic encryption to protect user privacy.

[0006] However, these services only check if the exact password has been leaked, making them vulnerable to recently proposed credential adjustment attacks, where attackers guess variations of a user's leaked password. In reality, password reuse is common; users often choose similar passwords across different websites (e.g., replacing lowercase letters with uppercase letters according to website policies, or simply adding a "1" to the end of an old password). Pal et al. estimated through simulations that, despite using C3 services, such credential adjustment attackers could compromise the other accounts of 10% of users with leaked passwords in less than 10 guesses.

[0007] To address this issue, Pal et al. designed "Might I Get Pwned" (MIGP). This model is based on their first proposed similarity-aware C3 service. For a user-entered password, it not only queries whether the password itself is leaked, but also checks whether similar variants of the password exist in the leaked dataset. This warns the user not to choose a password that is similar to (or the same as) a leaked password, which enhances the timeliness of client-side leak detection.

[0008] However, existing password leakage query systems still have security vulnerabilities: they cannot detect in a timely manner whether the password files stored in the system have been leaked. Therefore, it is necessary to design and implement a new password leakage query scheme.

[0009] References

[0010] [1]Wang D, Zou Y, Dong Q, et al. How to attack and generate honeywords[C] / / Proc.IEEE S&P 2022:489-506.

[0011] [2]Ari Juels,Ronald L Rivest.Honeywords:Making password-crackingdetectable[C].Proc.ACM CCS 2013,pp.145–160

[0012] [3]Kurt Thomas,Jennifer Pullman,Kevin Yeo,Ananth Raghunathan,PatrickGageKelley,Luca Invernizzi,Borbala Benko,Tadek Pietraszek,Sarvar Patel,DanBoneh,et al.2019.Protecting accounts from credential stuffing with passwordbreachalerting.In 28th USENIX Security Symposium(USENIX Security 19).1556–1571.

[0013] [4]Troy Hunt.2018.Have I Been Pwned?https: / / haveibeenpwned.com / Passwords / .

[0014] [5]2019.Testing Firefox Monitor,a New Security Tool.https: / / blog.mozilla.org / futurereleases / 2018 / 06 / 25 / testing-firefox-monitor-a-new-security-tool / .

[0015] [6]2018.Finding pwned passwords with 1Password.https: / / blog.1password.com / finding-pwned-passwords-with-1password / .

[0016] [7]Jennifer Pullman,Kurt Thomas,and Elie Bursztein.2019.Protect youraccountsfrom data breaches with Password Checkup.https: / / security.googleblog.com / 2019 / 02 / protect-your-accounts-from-data.html.

[0017] [8]A.Das,J.Bonneau,M.Caesar,N.Borisov,and X.Wang.The tangled web ofpasswordreuse.In NDSS,volume 14,pages 23–26,2014.

[0018] [9]B.Pal,T.Daniel,R.Chatterjee,and T.Ristenpart.Beyond credentialstuffing:Password similarity using neural networks.IEEE Symposium on Securityand Privacy,2019.

[0019]

[10] D.Wang,Z.Zhang,P.Wang,J.Yan,and X.Huang.Targeted online passwordguessing:An underestimated threat.In Proceedings of the 2016ACM SIGSACconference oncomputer and communications security,pages 1242–1254.ACM,2016.

[0020]

[11] S.Pearman,J.Thomas,P.E.Naeini,H.Habib,L.Bauer,N.Christin,F.Cranor,S.Egelman,and A.Forget.Let’s go in for a closer look:Observingpasswordsin their natural habitat.In Proceedings of the 2017ACM SIGSACConference onComputer and Communications Security,pages 295–310.ACM,2017.

[0021]

[12] Y.Zhang,F.Monrose,and M.K.Reiter.The security of modern passwordexpiration:an algorithmic framework and empirical analysis.In Proceedings ofthe 2010ACMSIGSAC conference on computer and communications security,pages176–186,2010.

[0022]

[13] Pal,Bijeeta and Islam,Mazharul and Bohuk,Marina Sanusi andValenta,Luke andWood,Chris and Whalen,Tara and Sullivan,Nick and Ristenpart,Thomas andChatterjee,Rahul 2022.Might I Get Pwned:A Second GenerationPassword BreachAlerting Service.In 31th USENIX Security Symposium(USENIXSecurity 22)

[0023]

[14] Matt Weir,Sudhir Aggarwal,Breno de Medeiros,Bill Glodek.Passwordcrackingusing probabilistic context-free grammars[C].Proc.IEEE S&P 2009,pp.391–405

[0024]

[15] Krawczyk, H.: HMQV: A high-performance secure Diffie-Hellmanprotocol. In: Shoup, V. (ed.) CRYPTO 2005. LNCS, vol. 3621, pp. 546–566.

[0025]

[16] J ARECKI, S., K IAYIAS, A., AND K RAWCZYK, H. Round-optimal password-protectedsecret sharing and t-pake in the password-only model. In ASIACRYPT(2014), Springer, pp.233–253. Summary of the Invention

[0026] The purpose of this invention is to provide a password leakage query system. This system can provide a password leakage query service, that is, when a user enters their username and password, the system will provide feedback on various scenarios indicating whether the password has been leaked. Based on this service, this invention also introduces honeywords technology to enhance the timeliness of server-side leakage detection. The technical solution is as follows:

[0027] A password leakage query system based on honeywords includes a server, Honeychecker, and a client. The query process comprises two stages: a preprocessing stage and an online query stage. The server stores the original leaked dataset. During the preprocessing stage, the original leaked data is encrypted and stored in the server's backend database. Additionally, the server generates honeywords during the preprocessing stage to assist in detecting data leaks in the backend database. The server also provides the index values ​​of the original leaked passwords and their variants in the corresponding data tables to Honeychecker for storage. During the online query stage, the server interacts with the client, transmitting data tables containing the client's input credentials. Honeychecker stores the index values ​​of the original leaked passwords and their variants in the original data tables. Furthermore, during the online query stage, it interacts with the client, informing them of the credential leakage. The client is a platform for internet users. Users input username-password pairs on the client, which then interacts with the server and Honeychecker, ultimately providing feedback to the user regarding the credential leakage.

[0028] Furthermore, in the preprocessing stage, the server uses its private key k to preprocess and encrypt the original leaked dataset. The original leaked dataset consists of pairs of leaked usernames and passwords. After encryption, the encrypted data is stored in the backend database. Let the leaked username be u and the plaintext leaked password be pw. The preprocessing includes the following steps:

[0029] A1. For the password pw that has been exposed in plaintext, generate its honeywords, and combine the password pw and the generated honeywords to form the honyelist of user u.

[0030] A2. Iterate through honeylist and generate n password variations for each password in the list;

[0031] A3. Encrypt each password pw and its n variants in honeylist using the OPRF encryption algorithm to obtain an encrypted data list associated with user u. Save the encrypted data to the data table corresponding to user u. The table name is generated based on user u's username.

[0032] A4. In the obtained encrypted data list, find a set of index values ​​for the user password pw and its n similar variants in the data table, and send this set of index values ​​to Honeychecker, which is responsible for password leakage detection, for storage.

[0033] Furthermore, users can conduct online password leak checks through the following steps:

[0034] B1. The user enters the username and password pair for the query on the client. The client generates a random private key r and performs preliminary encryption on the user's input credentials according to OPRF to obtain encrypted data x. The client then generates the table name j of the data table corresponding to the encrypted data x based on the username.

[0035] B2. The client sends encrypted data x to the server, corresponding to the table name j of the data table.

[0036] B3. After receiving the data, the server first checks whether a data table j corresponding to the encrypted data exists. If it does not exist, the user is informed that "the password has not been leaked" and the query is terminated. If it exists, the private key k is used to blind x according to the OPRF to obtain the data y.

[0037] B4. The server sends the data y and the data table j corresponding to the encrypted data to the client;

[0038] B5. After receiving the server's response, the client uses the private key r to decrypt y according to the OPRF to obtain the final encrypted data z;

[0039] B6. The client negotiates a key with Honeychecker to generate a key k′ for encrypting subsequent interactions between the two parties;

[0040] B7. The client checks whether the final encrypted data z is in the data table sent by the server. There are three possibilities: First, z is in the data table, and the index i of z in the data table is obtained; second, a variant of z is in the data table, and the index i of the variant of z in the data table is obtained; third, z is not in the data table, which means that the user password has not been leaked, but in order to prevent attackers from directly obtaining the result through the number of message rounds, a random number is selected and assigned to i. In addition, the client assigns a value to the variable s, which is the identifier corresponding to the above three cases.

[0041] B8. The client uses k′ to encrypt i and s, and sends the encrypted data to Honeychecker;

[0042] After receiving the client's request, Honeychecker decrypts the data to obtain 's' and checks which of the following scenarios from B7 it falls under. In the first two scenarios, Honeychecker compares the sent index value 'i' with the index value of the original password or a variant of the original password that it stores. If they are the same, it means that the user's password or a variant of the password has been leaked, and the client is notified that the password has been leaked. If they are different, it means that the client has entered 'honeywords', and the client is a dangerous client. In this case, the client must be informed that the password has not been leaked, and an alert must be sent to the server. In the third scenario, Honeychecker does not need to decrypt the data and directly tells the client that the password has not been leaked.

[0043] B10. The client uses k′ to encrypt the response indicating whether the password has been leaked, and then sends the encrypted response to the client.

[0044] B11. The client uses k′ to decrypt and obtains the response result, outputs the password leakage status locally, and the query ends.

[0045] Through the above steps, the present invention enables user-oriented password leakage query and provides the password leakage query system with the function of detecting system password file leakage.

[0046] Compared with the prior art, the beneficial effects of the present invention are:

[0047] This invention provides a password leakage query system based on honeyword, which can provide users with basic password leakage query services and feedback on password leakage or similar password leakage; it can also realize the leakage detection of password files in the system background. Attached Figure Description

[0048] Figure 1 The system model for using the present invention.

[0049] Figure 2 This is a flowchart of the server preprocessing stage.

[0050] Figure 3 The flowchart for the first stage of online query.

[0051] Figure 4 The flowchart for the second stage of online query. Detailed Implementation

[0052] The present invention will now be described in conjunction with the accompanying drawings and embodiments.

[0053] This invention provides a password leakage query system based on honeywords. The system offers a password leakage query service; when a user enters their username and password, the system provides feedback: the entered credentials have been leaked, they have not been leaked, or passwords similar to the entered password have been leaked. Building upon this service, this invention also introduces honeywords technology to enhance the timeliness of server-side leakage detection, thereby enabling timely remedial measures.

[0054] This invention mainly consists of two stages: a preprocessing stage and a user online query stage. In the preprocessing stage, the server generates the honeyword and encrypts the password data; in the query stage, it provides feedback on whether the user-entered password has been leaked.

[0055] like Figure 1 As shown, this invention relates to three systems: a server, Honeychecker, and a client; it involves two stages: a preprocessing stage and an online query stage. The server possesses the original leaked dataset. In the preprocessing stage, it encrypts the original leaked data and stores the encrypted data in the server's backend database. Furthermore, the server generates honeywords during the preprocessing stage to assist in detecting data leaks in the backend database, and provides the index values ​​of the original leaked passwords and their variants in the corresponding data tables to Honeychecker for storage. In the online query stage, the server interacts with the client, transmitting data tables containing potential client input credentials. Honeychecker stores the index values ​​of the original leaked passwords and their variants in the original data tables. Simultaneously, in the online query stage, it interacts with the client, informing them of the credential leak. The client is a platform for internet users. Users enter their username-password credential pair on the client, which then interacts with the server and Honeychecker, ultimately providing feedback to the user regarding the credential leak.

[0056] The invention will be further illustrated by the following examples.

[0057] Server preprocessing stage, such as Figure 2 As shown. The server stores the original leaked dataset, which needs to be encrypted. The original leaked dataset consists of username-password pairs. The preprocessing stage requires encryption of each username-password pair. For ease of distinction, in this invention, a set of username-password pairs read from the original leaked dataset is referred to as a username-original password pair.

[0058] For example, for the username-original password pair u-pw, its pre-computation steps are as follows:

[0059] 1. Generate m (m=19) honeywords from the original password pw. Honeywords can be generated using classic password probability models, such as PCFG, Markov, or List. Finally, the original password pw and the m honeywords form the honeylist for user u.

[0060] 2. Iterate through the honeylist, and for each record, generate n (n=100) password variations. For example, for the password "Alice123", the generated variations might be "Alice1234", "Alice123!", etc. Similar variations can be generated using algorithms such as pass2edit and wEdit.

[0061] 3. After completing steps 1 and 2, the username "Alice" corresponds to (m+1)*(n+1) username-password pairs. Next, OPRF encryption is performed on each username-password pair. For example, for "AliceAlice123", OPRF encryption is performed, which mainly involves two hash encryptions and one elliptic curve blinding calculation. This yields the final encrypted form of the credential. Furthermore, to distinguish the original password from the password variants generated in the pre-computation stage, the final ciphertext of the password variant is further modified by flipping the last bit. This results in (m+1)*(n+1) ciphertexts. For example, if the last bit of the ciphertext for "AliceAlice1234" is "1", it needs to be replaced with "0". This operation is to allow the online query stage to provide feedback to the user regarding whether their password variant has been leaked.

[0062] 4. Shuffle the order of the (m+1)*(n+1) ciphertexts corresponding to "Alice".

[0063] 5. Store the scrambled encrypted data in the server's database. The username can be hashed, and the first 20 (or 16) bits of the hash ciphertext can be used as the table name *j* for which the username should be stored. For example, for the username "Alice", the username string can be encrypted using the SM3 algorithm. The first 20 bits of the hash ciphertext, represented in hexadecimal as "32451", will be used as the table name corresponding to "Alice". All (m+1)*(n+1) ciphertext entries for the username "Alice" will eventually be inserted into the table named "32451".

[0064] 6. Locate the original password pw and its n variants in the stored data table z. jThe index values ​​c(w0), ..., c(wn) are used, where c(w0) is the index of the original password, and c(wi), i∈[1,n] are the indexes of the variants. Finally, the server sends the username u along with c(w0), ..., c(wn) to honeychecker.

[0065] 7. Honeychecker stores the index values ​​of the actual leaked passwords in the corresponding data tables on the server. Its database partitioning method is the same as the server. For example, the index information for "Alice" is stored in a data table named "32451" in Honeychecker. The Honeychecker database stores each index information and its tag. The tag indicates whether the index information is a variant. For example, the tag corresponding to the index information of the original password "Alice123" is "1", and the tag corresponding to its variants "Alice1234" and "Alice123!" is "0".

[0066] After data preprocessing is completed, the server begins to officially provide users with the password leak query service.

[0067] During the online query phase, the client needs to interact with the server and honeychecker sequentially, thus it can be divided into a first phase and a second phase. The specific communication process is detailed in [link to documentation]. Figure 3 , Figure 4 The steps for users to query online are as follows:

[0068] 1. The user enters the username and password to be queried in the client, for example, "Alice" and "Alice123".

[0069] 2. The client first encrypts the username-password pair (e.g., "AliceAlice123") according to OPRF, obtaining ciphertext x. Next, it calculates the table name j corresponding to the username; the table name corresponding to the username "Alice" is "32451". Then, it sends x and the table name to the server.

[0070] 3. The server first checks if table j exists. If not, it reports to the server that the password has not been leaked. If table j exists, the server performs secondary encryption on x according to OPRF to obtain y. Then, it combines y with all data z from table j. j Send to the client, z j Use a list data structure.

[0071] 4. The client performs a final encryption on y, obtaining ciphertext z. The client then checks z against the list z. j The correspondence is as follows: In the first case, if z is in z j In the first case, there is a possibility of password leakage; in the second case, the last bit of z is flipped to get z′, if z′ is in zj In the case of z, there is a possibility of leakage of similar variants; in the third case, if neither z nor z′ is in z j In this case, there is no leakage.

[0072] 5. Perform an HMQV protocol transaction with honeychecker to obtain the shared key k′. Then, handle the three scenarios differently:

[0073] 5.1 First case: obtaining z in the list z j The index i in the code is used, and the character s is assigned the value '1'. Then, k' is used to encrypt j, i, and s using a symmetric encryption algorithm such as SM4, and the code is sent to honeychecker.

[0074] 5.2 In the second case, we obtain z′ in z j The index i is used, and the character s is assigned the value '2'. Then, k' is used to encrypt j, i, and s using a symmetric encryption algorithm such as SM4, and the encryption is sent to honeychecker.

[0075] 5.3 In the third scenario, the password is not leaked. However, to prevent adversaries from learning the result that the user's password has not been leaked by listening to the number of message rounds, a random number i is selected, and the character s is assigned the value '3'. k' is used to encrypt j, i, and s using a symmetric encryption algorithm such as SM4, and then sent to honeychecker.

[0076] 6. After receiving the data from the client, honeychecker uses k′ and SM4 to decrypt it, obtaining j, i, and s. Based on the different values ​​of s, it sends feedback to the client:

[0077] 6.1 If s is '1', then check if there exists a record in table j with the same index value as i:

[0078] 6.1.1 If it exists, check its tag value. If the tag value is '1', it means that the user's input password has been leaked. The corresponding result is "match". If the tag value is '0', it means that the user's input password variant has been leaked. The corresponding result is "similar". Use the SM4 algorithm to encrypt the leaked result and send it to the client.

[0079] 6.1.2 If the password does not exist, it means the user entered the honeyword, and the password file of the password leakage query system's backend is highly likely to have been leaked, identifying the target client as a malicious client. On one hand, the non-leaked result "none" is encrypted using SM4 and sent to the client; on the other hand, a warning is sent to the password leakage query server, informing it of the malicious client's IP address, and the server will take appropriate restrictions on that IP address based on the specific circumstances.

[0080] 6.2 If s is '2', then check if there exists a record in table j with the same index value as i:

[0081] 6.2.1 If it exists, then the variant of the user's entered password has been leaked. Use SM4 to encrypt the leaked result as "similar" and send it to the client.

[0082] 6.2.2 If it does not exist, it means that the user has entered the honeyword, and the operation is the same as 6.1.2.

[0083] 6.3 If s is '3', the password entered by the client is not leaked. The result "none" is encrypted using SM4 and sent to the client.

[0084] 7. After receiving the feedback result from honeychecker, the client uses SM4 to decrypt it. There are three possible scenarios:

[0085] 7.1 The feedback result is "match", at which point the user's entered password is leaked;

[0086] 7.2 If the feedback result is "similar", then a variant of the user's entered password is leaked.

[0087] 7.3 The feedback result is "none", indicating that the user's password was not leaked.

[0088] 8. The client finally outputs the leak results, and this query ends.

[0089] In short, steps 1-3 constitute the first stage of online querying, involving interaction between the client and the server, such as... Figure 3 As shown. Steps 4-8 constitute the second stage of the online query, where the client interacts with honeychecker, as follows. Figure 4 As shown.

[0090] It should be noted that the purpose of disclosing the embodiments is to help further understand the present invention. However, those skilled in the art will understand that various substitutions and modifications are possible without departing from the spirit and scope of the present invention and the appended claims. Therefore, the present invention should not be limited to the content disclosed in the embodiments, and the scope of protection of the present invention is defined by the scope of the claims.

Claims

1. A password leakage query system based on honeywords, comprising a server, Honeychecker, and a client. The query process includes two stages: a preprocessing stage and an online query stage. The server stores the original leaked dataset. In the preprocessing stage, the original leaked data is encrypted and stored in the server's backend database. Furthermore, the server generates honeywords in the preprocessing stage to assist in detecting data leakage in the backend database and provides the index values ​​of the original leaked passwords and their variants in the corresponding data tables to Honeychecker for storage. In the online query stage, the server interacts with the client, transmitting data tables containing the client's input credentials. Honeychecker stores the index values ​​of the original leaked passwords and their variants in the original data tables and interacts with the client in the online query stage, informing the client of the credential leakage. The client is a platform for internet users. Users input username-password pairs in the client, which then interacts with the server and Honeychecker, ultimately providing feedback to the user regarding the credential leakage.

2. The password leakage query system according to claim 1, characterized in that, In the preprocessing stage, the server uses its private key k to preprocess and encrypt the original leaked dataset, which consists of pairs of leaked usernames and passwords. After encryption, the encrypted data is stored in the backend database. Let the leaked username be u and the plaintext leaked password be pw. The preprocessing includes the following steps: A1. For the password pw that has been exposed in plaintext, generate its honeywords, and combine the password pw and the generated honeywords to form the honyelist of user u. A2. Iterate through honeylist and generate n password variations for each password in the list; A3. Encrypt each password pw and its n variants in honeylist using the OPRF encryption algorithm to obtain an encrypted data list associated with user u. Save the encrypted data to the data table corresponding to user u. The table name is generated based on user u's username. A4. In the obtained encrypted data list, find a set of index values ​​for the user password pw and its n similar variants in the data table, and send this set of index values ​​to Honeychecker, which is responsible for password leakage detection, for storage.

3. The password leakage query system according to claim 2, characterized in that, Users can perform online password leak inquiries through the following steps: B1. The user enters the username and password pair for the query on the client. The client generates a random private key r and performs preliminary encryption on the user's input credentials according to OPRF to obtain encrypted data x. The client then generates the table name j of the data table corresponding to the encrypted data x based on the username. B2. The client sends encrypted data x to the server, corresponding to the table name j of the data table. B3. After receiving the data, the server first checks whether a data table j corresponding to the encrypted data exists. If it does not exist, the user is informed that "the password has not been leaked" and the query is terminated. If it exists, the private key k is used to blind x according to the OPRF to obtain the data y. B4. The server sends the data y and the data table j corresponding to the encrypted data to the client; B5. After receiving the server's response, the client uses the private key r to decrypt y according to the OPRF to obtain the final encrypted data z; B6. The client negotiates a key with Honeychecker to generate a key k′ for encrypting subsequent interactions between the two parties; B7. The client checks whether the final encrypted data z is in the data table sent by the server. There are three possibilities: First, z is in the data table, and the index i of z in the data table is obtained; second, a variant of z is in the data table, and the index i of the variant of z in the data table is obtained; third, z is not in the data table, which means that the user password has not been leaked, but in order to prevent attackers from directly obtaining the result through the number of message rounds, a random number is selected and assigned to i. In addition, the client assigns a value to the variable s, which is the identifier corresponding to the above three cases. B8. The client uses k′ to encrypt i and s, and sends the encrypted data to Honeychecker; After receiving the client's request, Honeychecker decrypts the data to obtain s and checks which of the following situations in B7 it belongs to. In the first two situations, Honeychecker compares the sent index value i with the index value of the original password or the original password variant stored in its database. If they are the same, it means that the user's password or password variant has been leaked, and the user informs the client of the password leak. If they are different, it means that the client has entered honeywords, and the client is a dangerous client. In this case, the client should be informed that the password has not been leaked, and an alert should be sent to the server. In the third case, honeychecker does not need to decrypt and directly tells the client that the password has not been leaked. B10. The client uses k′ to encrypt the response indicating whether the password has been leaked, and then sends the encrypted response to the client. B11. The client uses k′ to decrypt and obtains the response result, outputs the password leakage status locally, and the query ends.

Images