Mechanism to detect compromise of synced passkeys

Abstract

A method includes a user device generating a detection secret set (Π). The user device obtains a user credential (η) from a user of the user device. The user device determines a real secret (η∗) based on the detection secret set (Π) and the user credential (η). The user device stores the real secret (η∗). The user device provides the detection secret set (Π) and a backup account identifier (aid) for an account associated with the user to a server computer.

Description

PATENT Attorney Docket No.079900-1490324-7861WO01 Client Ref. No.7861WO01 MECHANISM TO DETECT COMPROMISE OF SYNCED PASSKEYS CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application is a PCT application which claims priority to U.S. Provisional Patent Application No.63 / 639,138, filed on April 26, 2024, which is herein incorporated by reference in its entirety. BACKGROUND

[0002] Credential backup services (CBSs) provide a solution to the account recovery problem by backing up users’ cryptographic credentials remotely. However, while solving the recovery problem, such a credential backup service introduces a new technical problem: the potential leakage of users’ credentials when credential backup services get compromised.

[0003] Cryptographic credential-based user authentication methods (e.g., FIDO2

[0013] , one-time passwords (OTP)

[0011] ) are increasingly being preferred and adopted in practice over user-chosen credential-based authentication methods (e.g., passwords, passphrases, or security questions).

[0004] In some systems, FIDO2 is set to replace user-chosen text password-based authentication completely in the near future [2], and one-time password holds a majority type of existing two-factor authentication systems.

[0005] This wide adoption is primarily due to the compelling high-security guarantees cryptographic credential-based authentication protocols bring by design. Specifically, the private keys used in FIDO2-based authentication

[0017] , or the seeds used to generate fresh one-time passwords [49, 50] are not guessable, chosen uniformly randomly, and thus secure from remote guessing attacks. In contrast, user-chosen credentials are highly predictable and thus vulnerable to guessing. However, this randomness makes cryptographic credentials not memorable for users

[0028] and users have to store these random credentials on their devices for logging into their accounts. 79571371V.1

[0006] This caveat necessitates existing websites to allow users to fall back to the user-chosen secrets to facilitate account recovery when cryptographic credentials become unavailable due to users’ device loss, theft, or failure. However such an insecure account recovery option defeats all high-security guarantees cryptographic credentials can offer; since attackers can now instead turn their attention to guessing the user-chosen secret required to complete the insecure account recovery process [41, 53].

[0007] Credential backup services, such as iCloud Keychain [1], Google Password Manager

[0014] , 1Password [6], LastPass [5], DashLane [4], and two-factor authentication (2FA) apps

[0031] , provide a solution to this account recovery problem by backing up users’ cryptographic credentials to cloud storage, and later, synchronizing their credentials back to their devices when needed. While a credential backup service is a promising solution for users and websites that do not want to fall back to unsecured user-chosen secret-based authentication methods for account recovery, it opens a new attack surface when credential backup services gets compromised. Attackers can steal users’ credentials from compromised credential backup service’s cloud storage and use those stolen credentials to take over users’ accounts at different websites. Such compromise can happen, for instance, due to a credential backup service getting breached or an insider attacker getting oracle access to the credential key-value store used by the credential backup service.

[0008] Embodiments of the disclosure address this problem and other problems individually and collectively. BRIEF SUMMARY

[0009] One embodiment is related to a method comprising: generating, by a user device, a detection secret set; obtaining, by the user device, a user credential from a user of the user device; determining, by the user device, a real secret based on the detection secret set and the user credential; storing, by the user device, the real secret; and providing, by the user device, the detection secret set and a backup account identifier for an account associated with the user to a server computer.

[0010] Another embodiment is related to a user device comprising: a processor; and a computer-readable medium coupled to the processor, the computer-readable medium comprising code executable by the processor for implementing a method 79571371V.1comprising: generating a detection secret set; obtaining a user credential from a user of the user device; determining a real secret based on the detection secret set and the user credential; storing the real secret; and providing the detection secret set and a backup account identifier for an account associated with the user to a server computer.

[0011] Another embodiment is related to a method comprising: receiving, by a computer, a user account identifier from a user device attempting to access an account maintained by the computer on behalf of the user device; generating, by the computer, an authentication message in response to the user account identifier; providing, by the computer, the authentication message to the user device, wherein the user device modifies the authentication message using a cryptographic credential that is associated with a verification key; receiving, by the computer, the modified authentication message from the user device; determining, by the computer, whether or not the modified authentication message was modified using the cryptographic credential that is associated with a stored verification key in a set of verification keys or in a subset of verification keys stored in the computer, wherein the subset of verification keys include decoy keys; if the modified authentication message was modified using the cryptographic credential that is associated with a stored verification key in the subset of verification keys, generating, by the computer, a cryptographic credential compromise message; and providing, by the computer, the cryptographic credential compromise message to a user associated with the account using an alternate communication channel.

[0012] Another embodiment includes a relying party computer comprising a processor and a computer readable medium. The computer readable medium comprises code, executable by the processor, for performing the above method.

[0013] Further details regarding embodiments of the disclosure can be found in the Detailed Description and the Figures. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] FIG.1 shows a block diagram of a system according to embodiments.

[0015] FIG.2 shows a block diagram of components of a user device according to79571371V.1

[0016] FIG. 3 shows a system and a flow diagram illustrating an overview of messages and phases in a system according to embodiments.

[0017] FIG. 4 shows a flow diagram illustrating a new credential backup and restoration method according to embodiments.

[0018] FIG.5 shows a flow diagram illustrating an authentication method according to embodiments.

[0019] FIG. 6 shows flow diagrams illustrating detection methods according to embodiments.

[0020] FIG. 7 shows graphs illustrating minimum expected true detection probabilities as a function of with varying and , where = 32 according to embodiments.

[0021] FIG. 8 shows graphs illustrating minimum expected true detection probabilities as a function of with varying , , and according to embodiments. DETAILED DESCRIPTION

[0022] Prior to discussing embodiments of the disclosure, some terms can be described in further detail.

[0023] A “user” may include an individual. In some embodiments, a user may be associated with one or more personal accounts and / or mobile devices. The user may also be referred to as a cardholder, account holder, or consumer in some embodiments.

[0024] A “user device” may be a device that is operated by a user. Examples of user devices may include a mobile phone, a smart phone, a card, a personal digital assistant (PDA), a laptop computer, a desktop computer, a server computer, a vehicle such as an automobile, a thin-client device, a tablet PC, etc. Additionally, user devices may be any type of wearable technology device, such as a watch, earpiece, glasses, etc. The user device may include one or more processors capable of processing user input. The user device may also include one or more input sensors for receiving user input. As is known in the art, there are a variety of input sensors capable of detecting user input, such as accelerometers, cameras, microphones, etc. The user input obtained by the input sensors may be from a variety of data input types, including, but 79571371V.1not limited to, audio data, visual data, or biometric data. The user device may comprise any electronic device that may be operated by a user, which may also provide remote communication capabilities to a network. Examples of remote communication capabilities include using a mobile phone (wireless) network, wireless data network (e.g., 3G, 4G or similar networks), Wi-Fi, Wi-Max, or any other communication medium that may provide access to a network such as the Internet or a private network.

[0025] The term “verification” and its derivatives may include a process that utilizes information to determine whether an underlying subject is valid under a given set of circumstances. Verification may include any comparison of information to ensure some data or information is correct, valid, accurate, legitimate, and / or in good standing.

[0026] A “user credential” ( ) can include information that indicates information for orabout a user. A user credential can include information that is specific to a user. A user credential can be kept as a secret by a user device for a user. A user credential can be a password, a PIN, a passphrase, an answers to a secret questions, a graphical password, a user biometric, etc.

[0027] A “secret” can include information that is not typically shared between devices. A secret can be a private cryptographic key.

[0028] A “detection secret set” ( ) can include a plurality of secrets. A detectionsecret set can include a real secret and a plurality of decoy secrets.

[0029] A “real secret” ( ) can include a secret of a plurality of secrets that is selectedas an actual secret. A real secret can be utilized to obfuscate data. A real secret can be used in a masking process to mask cryptographic credentials. A real secret can be utilized by a user device to communicate with other computers to authenticate the user device. A user device can use a real secret to obfuscate a cryptographic credential, such as a private key, that can be used to sign, modify, or otherwise interact with data that is sent to another computer for authentication of the user device. The other computer can verify that the data was, for example, signed with the cryptographic credential using a verification key that corresponds to the cryptographic credential.

[0030] A “decoy secret” can include a secret of a plurality of secrets that is not selected as an actual secret. A decoy secret hide a real secret from identification in a 79571371V.1detection secret set. A decoy secret can be used similarly to a real secret. However, in some embodiments, when a decoy secret is identified as being used, then the device that identified the decoy secret can determine that there has been a data breach and the device using the decoy secret is a malicious device. A decoy secret can be used to similarly obfuscate a cryptographic credential for use during authentication. If a cryptographic credential that is obfuscated by a decoy secret is identified as being used, then the using computer can be identified as a malicious computer.

[0031] A “cryptographic credential” ( ) can include data that can be used tocryptographically modify other data. A cryptographic credential can be used to sign, modify, or otherwise interact with data. Data that is signed, modified, or interacted by a cryptographic credential can be verified using a verification key. For example, a cryptographic credential can be a cryptographic key. In some embodiments, a cryptographic credential can be a private key in a public-private key pair. A cryptographic credential may correspond to a verification key. In other embodiments, a cryptographic credential can be a symmetric cryptographic key, where a corresponding verification key is the same key as the cryptographic credential.

[0032] A “verification key” ( ) can include a public cryptographic key used to identifya particular cryptographic credential. A verification key can be generated based on a cryptographic credential. A verification key can be used, for example, to verify a signature on data that is created by a corresponding cryptographic credential.

[0033] A “set of verification keys” ( ) can include a plurality of verification keys. Theverification keys in the set of verification keys can correspond to the cryptographic credential that is obfuscated with a real secret and a plurality of decoy cryptographic credentials that are obfuscated with decoy secrets.

[0034] A “backup account identifier” ( ) can be a value that identifies a backupaccount. A backup account identifier can identify a backup account that a user device has or is establishing with a provider computer.

[0035] A “user account identifier” ( ) can be a value that identifies a user account.A user account identifier can identify a user account that a user device has or is establishing with a relying party computer. 79571371V.1

[0036] A “relying party computer identifier” ( ) can be a value that identifies arelying party computer. A relying party computer can be associated with a unique relying party computer identifier.

[0037] A “processor” may include a device that processes something. In some embodiments, a processor can include any suitable data computation device or devices. A processor may comprise one or more microprocessors working together to accomplish a desired function. The processor may include a CPU comprising at least one high-speed data processor adequate to execute program components for executing user and / or system-generated requests. The CPU may be a microprocessor such as AMD's Athlon, Duron and / or Opteron; IBM and / or Motorola's PowerPC; IBM's and Sony's Cell processor; Intel's Celeron, Itanium, Pentium, Xeon, and / or XScale; and / or the like processor(s).

[0038] A “memory” may be any suitable device or devices that can store electronic data. A suitable memory may comprise a non-transitory computer readable medium that stores instructions that can be executed by a processor to implement a desired method. Examples of memories may comprise one or more memory chips, disk drives, etc. Such memories may operate using any suitable electrical, optical, and / or magnetic mode of operation.

[0039] A “server computer” may include a powerful computer or cluster of computers. For example, the server computer can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit. In one example, the server computer may be a database server coupled to a Web server. The server computer may comprise one or more computational apparatuses and may use any of a variety of computing structures, arrangements, and compilations for servicing the requests from one or more client computers. I. INTRODUCTION

[0040] Embodiments solve the technical problem of the potential leakage of users’ credentials when credential backup services get compromised. To solve this technical problem, embodiments provide for a framework that allows an uncompromised website to detect unauthorized login attempts using credentials stolen from compromised credential backup services. 79571371V.1

[0041] Embodiments provide for a new credential backup protocol that shields users’ backed-up credentials from credential backup service compromise and implements a probabilistic detection mechanism that websites can employ during login attempts. The security of embodiments is presented and its benefits are analyzed conservatively for attackers who always select the best strategy. The analysis based on model checking finds the framework according to embodiments to be effective even in the case when attackers after obtaining leaked credentials from the credential backup service breach attempt to avoid detection by observing breaches from other compromised websites. Overall the framework is seamlessly incorporated into two widely used cryptographic authentication protocols, and discuss the framework’s easy deployability — most importantly without reintroducing the account recovery problem, and necessitating any marked changes to existing credential backup services used in practice. The framework according to embodiments can be readily adopted by websites, and empower users to detect unauthorized use of users’ cryptographic credentials happening due to credential backup services getting compromise.

[0042] Embodiments address the problem of a users’ account takeover due to credential backup services getting compromised by carefully designing a detection framework. Embodiments provide for a method that can enable a website or computer to detect the compromise of users’ cryptographic credential that is backed up at a credential backup service — without reintroducing the account recovery problem.

[0043] To achieve this, embodiments introduce a new credential backup protocol and implement a detection mechanism. Specifically, the backup protocol protects the cryptographic credentials with end-to-end encryption under a recovery key, and carefully divides an entire set of invalid credentials of a user into two subsets: a decoy subset and a non-decoy subset. In particular, the backup protocol that can ensure, attackers — with full access to the user’s credentials stored at credential backup service (e.g., such as during a full data breach) — will derive one of the decoy credentials the majority of the time (e.g., with high probability) when the attacker uses one of the incorrect recovery keys. Subsequently, the proposed detection technique allows a website (e.g., a target website) or computer to flag login attempts from attackers using the decoy credentials with high probability and notifies the user of this incident that their credential backup at the credential backup service has been compromised. 79571371V.1

[0044] The security of the protocol is formally evaluated herein and the effectiveness of embodiments are described even under threats when attackers could attempt to avoid detection by leveraging information of the breached persistent storage from other non-target websites. This is a technically important and challenging threat to consider given the increasing number of data breaches, and a quantitative analysis based on model checking shows that embodiments remain substantially effective even under such threats for attackers that always perform optimal attack strategies.

[0045] Embodiments are deployable in that embodiments can be incorporated into existing authentication protocols (e.g., FIDO2, one-time password), while incurring negligible performance and storage overhead overall. Embodiments achieve this without requiring additional trusted hardware assumptions or relying on the distributed trust assumption similar to the blockchain infrastructure setting.

[0046] From a usability perspective, embodiments can ensure low false alarms with simple secret management solutions that are easy for users. For instance, an empirical evaluation based on a prototype implementation shows that with users remembering four-digit system-generated PINs, the false detection rate of embodiments is practically negligible. II. BACKGROUND INFORMATION

[0047] Various information in reference to credential backup services, cryptographic authentication protocols, and decoy-based defense against credential compromise will be discussed. A. Credential Backup Service

[0048] A credential backup service is among the most user-friendly account recovery solutions, allowing a user to easily back up their cryptographic authentication credentials, and later recover them after successful authentication. Users have to register their account at a credential backup service, which is typically protected by user-chosen password based authentication. These credential backup services, however, have become a lucrative target for attackers due to their centralized nature in storing users’ cryptographic credentials. As a result, most (but not all) credential 79571371V.1backup services now use a cryptographic key to protect a user’s credential backup at rest and in transit, for example, by encrypting it with the cryptographic key.

[0049] This key needs to be recoverable for users — otherwise, users will not be able to decrypt the encrypted credential backup retrieved from the credential backup service, which will, unfortunately, reintroduce the account recovery problem that credential backup service attempts to solve in the first place. Considering that managing a cryptographic key has been long a daunting task to users

[0028] , existing credential backup services only require users to maintain a user secret (e.g., a password in most cases) which is presumably more memorable, recallable and hence recoverable than a cryptographic key. In practice, this secret can be used in two flavors of strategies with different emphases on the security and recoverability of the cryptographic key and accordingly users’ credential backup.

[0050] As adopted by popular credential managers such as LastPass [5], 1Password [6], and many OTP-based 2FA applications

[0031] , the user secret can be used to directly derive the cryptographic key (e.g., via key derivation functions (KDF)). This approach allows the encryption and decryption of a user’s backup to be completed entirely locally on the user’s device, and avoids giving the credential backup service access to plaintext cryptographic keys. While this strategy provides the user with some level of security control over their cryptographic credential backup at credential backup service, it also allows attackers to perform offline cracking on the user’s credential backup that has been leaked from credential backup service.

[0051] The feasibility of such offline attacks depends on how the following two factors resist offline attacks: the user-chosen password, and the key derivation function algorithm. Relying on these two factors to protect users from credential backup service compromise has been a long-standing issue. For instance, prior research has observed that user-chosen secrets are easily guessable, particularly those that users can recall consistently

[0037] . Encouraging users to choose passwords that could resist offline attack (e.g., via password composition policies, strength meters, etc.) is difficult to ensure, and often-times not accurate [32, 54]. Many applications utilize a key derivation function defined in public-key cryptography standards (PKCS#11) which is not appropriate to withstand offline attacks leveraging modern hardware. LastPass, 1Password, and KeePass (and many others) use password-based key derivation 79571371V.1function 2 (PBKDF2)

[0048] , which is the recommended function. However, even in that case, ensuring resistance against offline attacks is challenging. Concerns about such attacks are not superfluous. In March 2023, LastPass completed assessing the extent of damage from a breach of cloud storage [8] that happened in twice in 2022 [8, 39].

[0052] For a completely different strategy, which is adopted by popular platform providers such as Apple, Google, and Microsoft, a user secret (e.g., in the form of a PIN, a password, a screen lock pattern, etc.), independent of the generation of the cryptographic key, merely serves a verification secret that the credential backup service provider, or its components, use to verify the user’s identity. More specifically, the credential backup service generates a cryptographic key independently, stores it on its own key management service (KMS) provided by the credential backup service itself, and uses this key to encrypt users’ cryptographic credentials before storage. Users could retrieve their key from the key management service after proving their legitimacy by providing a valid verification secret to the key management service. Compared to the former strategy, a user must give up their entire control over their credentials while trusting the credential backup service provider’s ability and willingness to design and implement their key management service correctly and securely as promised from attackers who have compromised users’ encrypted credentials leaked from cloud storage.

[0053] Unfortunately, with this strategy users have no means to know if their cryptographic credentials are leaked due to credential backup service’s key management service design or implementation flaws — similar to the recently undisclosed security vulnerability of Apple’s credential wallet

[0051] . Even if such implementation is secure, insider attackers within the credential backup service could get query access to the key management service, and retrieve the key after guessing the low entropy verification secret

[0024] successfully — even within the rate limit specified by credential backup service [In practice providers like Google, Apple apply lock users account after 10 failed login attempts. However, prior research has shown PIN, and screen lock could be guessed easily even within 10 guesses [3, 18].]. Apple has employed trusted cloud hardware in the form of a hardware secure module for key management service and destroyed the administrative access cards eliminating the possibility that any party accessing the key without providing the correct verification secret. However, insider attackers could still get query access to the hardware secure 79571371V.1module, steal users’ keys by correctly guessing the verification secret, and it would not be detectable from the outside. This is possible for insider attackers, even without altering the administrative policies of a hardware secure module.

[0054] What is more concerning is that remote attackers can compromise users’ accounts at credential backup service that relies on one or more noncryptographic “out-of-band” authentication methods such as user chosen passwords, short message service (SMS) OTP, email OTP.

[0055] However, the security of a user’s credential backup for all of their accounts is eventually reduced to that of these non-cryptographic “out-of-band” authentication methods, unfortunately, most of which have weaker security guarantees, such as against phishing as well as relying on other weak authentication methods such as passwords.

[0056] The foregoing discussion echoes the challenge systems are facing today to secure users’ cryptographic credentials against credential backup service breaches, revolving around many moving parts including but not limited to security of users’ accounts at a credential backup service, offline cracking resistance of user-chosen passwords and a key derivation function, and correctness of credential backup services’ key management service implementations from insider attackers. Failure of any of these parts potentially makes all cryptographic credentials of users vulnerable. This has accumulated in user mistrust over credential backup services

[0045] , and systems need a mechanism to detect cryptographic credentials misused compatible agnostic to existing credential backup service infrastructure, easy to deploy, and does not affect the recoverability of users’ credentials adversely to address this issue. B. Cryptographic Authentication Protocols

[0057] The device that generates the cryptographic credentials is referred to as an authenticator, which can be dedicated physical hardware or virtual platform dependent. An application (e.g., browsers, mobile applications, etc.) running on the user device can contact a relying party (RP) and, with the help of the authenticator, perform user authentication.

[0058] The information used by the relying party to authenticate the login requests are referred to as verifiers. Whether this verifier is symmetric or asymmetric depends 79571371V.1on the authentication protocol itself. For example, one-time password / passcode (OTP) have symmetric verifiers since the cryptographic seed is shared between the authenticator and the relying party. Whereas, the FIDO2 protocol has an asymmetric verifier since the relying party stores the public key associated with the private signing key, and the authenticator does not share this private signing key with the relying party.

[0059] Below, a brief background of the FIDO2 and OTP-based cryptographic user authentication protocol are provided. 1. FIDO2 and passkeys

[0060] FIDO2-based user authentication is touted as the next-generation user authentication replacing traditional text-based user-chosen password-based user authentication. FIDO2 itself is a set of standards specified by the coalition of FIDO alliance and the W3C WebAuthn community, which over-seen by more than 250 organizations

[0013] including Google, Apple, Meta, Visa. In this authentication protocol,during registration, a user device generates a new authentication key pair s , v ,where s is the private signing key and v is the public verification key. Only the publicverification key v is sent to the online service (or relying party) while the private signingkey s stays on the user device. During a login phase, the relying party sends achallenge, and the user device completes the challenge using the private signing keys . Finally, the relying party can verify the correctness of the complete challenge usingthe public verification key v , and allow the user to login.

[0061] FIDO2-based user authentication brings compelling security against phishing, credential theft, reply attacks, and keylogging by design. Its security guarantees has been formally verified [19, 21, 33]. Today, FIDO2 is supported by major web browsers, operating systems, and many web services

[0012] . However, one serious barrier to the widespread adoption of FIDO2-based user authentication adoption has been its lack of secure account recovery when users lose access to their device-hosted private signing keys due to device lost, reset, theft [20, 30, 41, 44, 45, 47, 52, 58].

[0062] Although many online services have reluctantly resorted to password-based account recovery options for usability, attackers could compromise users’ accounts by downgrading FIDO2-based authentication to this insecure account (password-based) recovery option

[0053] . In particular, a study from Bicakci et al.

[0020] , and Würsching et 79571371V.1al.

[0058] listed lack of convenient and secure account recovery method for FIDO2 password-less authentication, as one of the major reasons why it will not be possible to eliminate passwords on the web in the near foreseeable future. Las et al.

[0041] found that more than 60% of participants expressed their serious concerns around secure account recovery in enterprise settings.

[0063] To tackle this problem an industry-led effort has turned their attention tocredential backup services and making all private signing keys s hosted by theauthenticator syncable and referred to as such keys as passkeys.

[0064] Passkeys have been the main propellant to replace password-based user authentication, and as such Apple, Google, and Microsoft have shared their vision to completely transition from passwords to passkeys in the near future [2]. Credential backup services thus far is playing a crucial role in the widespread deployment of FIDO2. Now, credential wallets / password managers, including 1Password, Dashlane, KeePass, LastPass, etc., all provide (or in the process of providing) this service [4–6]. Apple and Google are offering this service by iCloud keychain [1], and Google password manager

[0015] respectively. 2. One-time password

[0065] One-time passcode / password (OTP) is widely used as multi-factor authentication (MFA) to strengthen the security of password-based user authentication or as the primary authentication option

[0010] .

[0066] As the name suggests, one-time password dynamically creates a new password each time, denoted by password of digits by applying a hash functionover a cryptographically generated random seed s as in the following equation:, . Here, is a value that is updated to maintain the freshness of thepassword w. This update can be counter-based for hash-based OTP (HOTP)

[0050] or timing-based for timing-based OTP (TOTP)

[0049] .

[0067] Similar to FIDO2, users could lose access to their cryptographic credential sdue to device loss, reset, theft, and be susceptible to account lockout due to not being able to generate new one-time passwords and complete the multi-factor authentication, especially required for login in for a new device in most cases. To tackle this problem, a credential backup service could back up users’ cryptographic one-time 79571371V.1password seed s on their cloud storage. For instance, Google recently announcedthat they are backing up users’ OTP seed to their cloud storage

[0023] to accelerate the adoption of OTP based MFA.

[0068] However, embodiments consider the threat when users’ cryptographic credentials (e.g., cryptographic seeds for OTP, private keys from FIDO2) get leaked from a credential backup service, and how to detect users’ account compromise due to such attacks. C. Decoy-Based Defense Against Credential Compromise

[0069] Decoy-based defense can involve decoy password vaults, decoy-based credential breach detection, and decoy credential generation. 1. Decoy password vaults

[0070] Password vaults, also known as password managers, allow users to store their passwords in a vault file that is encrypted with a master password. For a better cross-device user experience, this encrypted vault file is often backed up to the cloud and can be downloaded to multiple devices with authorized access. Such convenience, however, exposes the vault file to threats such as unauthorized access due to weak authentication and vault file compromise as a result of cloud breaches. After gaining access to a vault file, an attacker can try to crack it offline by guessing the master password or even by brute forcing with powerful computation resources. Unfortunately, the attacker can do so unnoticeably and efficiently, as incorrect master passwords can be easily identified and ruled out when the corresponding decrypted vault entries that appear random and unreadable. Decoy password vaults, or honey vaults, can produce plausible-looking password entries after decryption with incorrect master passwords. Their goal is to slow down offline vault cracking and force the attacker to perform additional online verification with those plausible-looking passwords. However, let alone existing honey vault designs facing unsolved challenges in defending against intersection attacks

[0038] (where an attacker exploits user passwords reused across different sites) and more powerful and practical distinguishing attacks based on prior knowledge about users

[0026] , most websites do not enforce rate limiting on account login attempts

[0046] , casting doubt on the efficacy of honey vaults in practice. 79571371V.12. Decoy-based credential breach detection

[0071] Unlike embodiments, which deals with compromise of users’ authentication secrets stored at a credential backup service computer, previous research on decoy- based credential breach detection systems [27, 38, 56] has primarily focused on detecting credential breaches at a relying party computer. For example, instead of storing the user-chosen password alone, these systems allow a relying party computer to plant a certain number of carefully chosen decoy passwords in its password database, which, if used during a login attempt, can alert the relying party to its password database breach. In these systems, the relying party computer relies on various forms of detection indicators to be able to distinguish between the real credential and the decoys. Based on whether or not such detection indicators are assumed private despite the breach of the relying party, these detection systems can be classified into two types: asymmetric and symmetric

[0057] . More specifically, asymmetric designs assume that the relying party has more information, in the form of persistent storage across multiple authentication instances, than the attacker does from its breach. For example, Jules & Rivest’s design

[0038] leverages an identifier that points to the real credential. This identifier is assumed inaccessible to the attacker despite the breach. Similarly, another design called Lethe

[0027] assumes the security of a seed for a pseudorandom number generator, which is consistently reused by the defender across multiple authentication instances to identify the use of a decoy credential. In contrast, the symmetric design, Amnesia

[0056] , enables a relying party to identify the use of a decoy even if the attacker has access to the same amount of information equivalent to that in the relying party computer’s persistent storage.

[0072] While the proposed framework according to embodiments can work with all detection algorithms in the aforementioned designs, asymmetric (e.g., Jules & Rivest’s

[0038] and Lethe

[0027] ) or symmetric (e.g., Amnesia

[0056] ), handling the symmetric case requires more careful considerations. This is because symmetric design assumes a more powerful attacker, and demonstrating embodiment’s detection effectiveness against such attackers is more challenging. 3. Decoy credential generation

[0073] How to generate good decoy credentials for decoy-based breach detection, however, has been more of an orthogonal research topic to the design of breach 79571371V.1detection algorithms introduced herein. Most of the existing work (e.g., [16, 29, 55]), has mainly focused on improving the flatness of decoy passwords (or referred to as “honeywords” in most related literature) against increasingly sophisticated attackers. These methods, typically rely heavily on additional user information (e.g., personal identifiable information, phone numbers, addresses, passwords for other sites, etc.) to generate more genuine-looking decoy passwords. Similarly, distinguishing attackers or false alarm attackers can leverage the same, if not greater, amount of such user information to attempt to avoid detection or to trigger false alarms respectively. Such a tension between true and false-alarm rates is difficult to resolve due to uncertain amount of accessible user information by the attacker and the defender, leading Huang et al.

[0036] to conclude, based on their systematic analysis of existing decoy password generation algorithms, that “there appears to be no known algorithm providing a good trade-off for account with user-chosen passwords”. Bernoulli honeywords

[0057] , however, takes a different strategy by selecting decoy passwords via a probabilistic process independent of user information, resulting quantifiably low false detection probabilities.

[0074] According to embodiments, the decoy detection secret generation algorithm, GenDetectSecret, as specified in Table 1, follows a similar idea of Bernoulli honeywords by randomly picking decoy detection secrets from a large secret space to accommodate the needs of quantifiable detection effectiveness and secret recoverability. Nevertheless, embodiments are, by design, compatible with other decoy credential algorithms. More specifically, GenDetectSecret can be instantiated in a plug-and-play manner with decoy credential algorithms that output a detection secret set (e.g., also referred to as a decoy secret set) with a certain level of flatness. It is shown herein that embodiments preserve the flatness despite the compromise of credential backup service storage. III. EXEMPLARY NETWORK AND DEVICE INFRASTRUCTURE

[0075] Embodiments can utilize systems and devices to securely generate and backup credentials, with a provider computer, for user devices that can be used to authenticate the user device to relying party computers. 79571371V.1A. Interaction System

[0076] FIG.1 shows a system 100 according to embodiments of the disclosure. The system 100 comprises a user device 102, a relying party computer 104, and a provider computer 106.

[0077] The user device 102 can be in operative communication with the relying party computer 104 and the provider computer 106. The relying party computer 104 can be in operative communication with the provider computer 106.

[0078] For simplicity of illustration, a certain number of components are shown in FIG.1. It is understood, however, that embodiments of the invention may include more than one of each component. In addition, some embodiments of the invention may include fewer than or greater than all of the components shown in FIG.1.

[0079] Messages between at least the devices in the system 100 in FIG. 1 can be transmitted using a secure communications protocols such as, but not limited to, File Transfer Protocol (FTP); HyperText Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS), SSL, ISO (e.g., ISO 8583) and / or the like. The communications network may include any one and / or the combination of the following: a direct interconnection; the Internet; a Local Area Network (LAN); a Metropolitan Area Network (MAN); an Operating Missions as Nodes on the Internet (OMNI); a secured custom connection; a Wide Area Network (WAN); a wireless network (e.g., employing protocols such as, but not limited to a Wireless Application Protocol (WAP), I-mode, and / or the like); and / or the like. The communications network can use any suitable communications protocol to generate one or more secure communication channels. A communications channel may, in some instances, comprise a secure communication channel, which may be established in any known manner, such as through the use of mutual authentication and a session key, and establishment of a Secure Socket Layer (SSL) session.

[0080] The user device 102 can include a device operated by a user. The user device 102 can be a mobile phone, a smart phone, a card, a personal digital assistant, a laptop computer, a desktop computer, a server computer, a vehicle such as an automobile, a thin-client device, a tablet PC, a wearable technology device (e.g., a 79571371V.1watch, earpiece, glasses, etc.), or other device that can be utilized by a user and can communicate with other devices.

[0081] The user device 102 can communicate with a relying party computer 104 to authenticate the user and / or the user device 102 to access an account maintained by the relying party computer 104 for the user and / or the user device 102. The account can be an account that allows the user and / or the user device 102 to access a secure webpage hosted by the relying party computer 104. The account can be a video steaming account, a bank account, a social media account, an employee / employer account, etc. The account can be identified by a user account identifier.

[0082] The relying party computer 104 can include a computer that can authenticate the user device 102 when the user device 102 requests to access an account. The relying party computer 104 can utilize verification keys received from the user device 102 during user device enrollment to verify data received from the user device 102. Based on the verification, the relying party computer 104 can grant or deny access to the account to the user device.

[0083] The provider computer 106 can include a computer that can store backup data for the user device 102. The provider computer 106 can store backup credentials or derivations thereof that are used by the user device 102 to request access to the account maintained by the relying party computer 104. As such, if the user device 102 were to be lost, or had its memory deleted, then the user device 102 could communicate with the provider computer 106 to reobtain the backed up data. B. User Device

[0084] FIG. 2 shows a block diagram of a user device 102 according to embodiments. The exemplary user device 102 may comprise a processor 204. The processor 204 may be coupled to a memory 202, a network interface 206, and a computer readable medium 208. The computer readable medium 208 can comprise a plurality of modules. For example, the computer readable medium 208 can comprise an authentication module 208A, a registration module 208B, and a backup module 208C.

[0085] The memory 202 can be used to store data and code. For example, the memory 202 can store cryptographic keys, credentials, authentication data, etc. The 79571371V.1memory 202 may be coupled to the processor 204 internally or externally (e.g., cloud based data storage), and may comprise any combination of volatile and / or non-volatile memory, such as RAM, DRAM, ROM, flash, or any other suitable memory device.

[0086] The computer readable medium 208 may comprise code, executable by the processor 204, for performing a method comprising: generating, by a user device, adetection secret set ( ); obtaining, by the user device, a user credential ( ) from a userof the user device; determining, by the user device, a real secret ( ) based on thedetection secret set ( ) and the user credential ( ); storing, by the user device, thereal secret ( ); and providing, by the user device, the detection secret set ( ) and abackup account identifier ( ) for an account associated with the user to a servercomputer.

[0087] The authentication module 208A may comprise code or software, executable by the processor 204, for performing authentication. The authentication module 208A, in conjunction with the processor 204, can perform authentication methods to authenticate a user of the user device 102. The authentication module 208A, in conjunction with the processor 204, can authenticate the user locally on the user device 102 or can aid remote computers (e.g., the relying party computer 104, the provider computer 106, etc.) with authenticating the user.

[0088] For example, the authentication module 208A, in conjunction with the processor 204, can obtain user inputs from the user of the user device 102. The user inputs can include passwords, codes, biometrics, etc. The authentication module 208A, in conjunction with the processor 204, can compare a received user input to a stored user input. The authentication module 208A, in conjunction with the processor 204, can determine whether or not the user is authentic based on whether or not the two user inputs match. For example, the authentication module 208A, in conjunction with the processor 204, can obtain a user input that is a biometric of the user’s fingerprint. The authentication module 208A, in conjunction with the processor 204, can compare the biometric of the user’s fingerprint with a stored biometric of the user’s fingerprint. The authentication module 208A, in conjunction with the processor 204, can determine a matching value that indicates how well the two biometrics match. If the matching value is greater than a threshold, then the authentication module 208A, in conjunction with the processor 204, can determine that the user is authentic.20 79571371V.1

[0089] The registration module 208B may comprise code or software, executable by the processor 204, for registering the user device 102 and / or the user with other computers. The registration module 208B, in conjunction with the processor 204, can register for accounts for the user and / or the user device 102 that are maintained by another computer.

[0090] The registration module 208B, in conjunction with the processor 204, can register the user device 102 with the provider computer 106 to create a backup account with the provider computer 106. The registration module 208B, in conjunction with the processor 204, can register with the relying party computer 104 to create a user account with the relying party computer 104. The registration module 208B, in conjunction with the processor 204, can perform different registration processes for different computers as described in detail herein.

[0091] The backup module 208C may comprise code or software, executable by the processor 204, for creating and using backups. The backup module 208C, in conjunction with the processor 204, can communicate with the provider computer 106, which can be a credential backup service computer. After creating a backup account with the provider computer 106, the backup module 208C, in conjunction with the processor 204, can provide data to the provider computer 106 that the user device 102 can later obtain from the provider computer 106 when requested.

[0092] For example, the backup module 208C, in conjunction with the processor 204, can send a backup account identifier and a detection secret set to the provider computer 106 to be stored. Even if the provider computer 106 were to be compromised (e.g., a data breach), then a malicious attacker still would not be able to access the user device’s real secret as it is obfuscated in the detection secret set.

[0093] As another example, the backup module 208C, in conjunction with the processor 204, can store masked cryptographic credentials with the provider computer 106. The masked cryptographic credentials can mask cryptographic credentials that are private keys used to generate to signatures to authenticate the user device 102 to a relying party computer 104. Even if the provider computer 106 were to be compromised, then a malicious attacker still would not be able to fraudulently authenticate themselves as the user device to the relying party computer 104 since the cryptographic credential is masked. 79571371V.1

[0094] The network interface 206 may include an interface that can allow the user device 102 to communicate with external computers. The network interface 206 may enable the user device 102 to communicate data to and from another device (e.g., the relying party computer 104, the provider computer 106, etc.). Some examples of the network interface 206 may include a modem, a physical network interface (such as an Ethernet card or other Network Interface Card (NIC)), a virtual network interface, a communications port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, or the like. The wireless protocols enabled by the network interface 206 may include Wi-FiTM. Data transferred via the network interface 206 may be in the form of signals which may be electrical, electromagnetic, optical, or any other signal capable of being received by the external communications interface (collectively referred to as “electronic signals” or “electronic messages”). These electronic messages that may comprise data or instructions may be provided between the network interface 206 and other devices via a communications path or channel. As noted above, any suitable communication path or channel may be used such as, for instance, a wire or cable, fiber optics, a telephone line, a cellular link, a radio frequency (RF) link, a WAN or LAN network, the Internet, or any other suitable medium. IV. THREAT MODEL AND GOALS A. Setup

[0095] FIG.3 shows a flow diagram illustrating an overview of messages and phases in a system according to embodiments. FIG.3 will be described at a high level, while further details of each step of the process are described below. FIG. 3 includes the user device 102, the relying party 104, the provider computer 106, and an attacker device 302.

[0096] Prior to step 310, the user device 102 can register with the provider computer 106 to create a backup account. During this process, as described in further detail below, the user device 102 can generate a detection secret set that includes a plurality of decoy secrets and one real secret. The real secret in the detection secret set can be utilized to create cryptographic credentials for communicating with relying party79571371V.1

[0097] The user device 102 can include a physical authenticator or a virtual authenticator that is capable of authenticating the user of the user of the user device 102. For example, the user device 102 can include an authentication application that is capable of authenticating the user of the user device 102 using user inputs (e.g., passwords, codes, biometrics, etc.).

[0098] The relying party computer 104 can maintain a website. The user device 102 can attempt to register and create an account (e.g., a user account) with the website. The website can be referred to as a target website and the relying party computer 104 can be referred to as a target relying party computer. Other relying party computers where the user has accounts, can be referred to as non-target relying party computers.

[0099] At step 310, the user device 102 and the relying party computer 104 can perform authentication and registration methods that are described in further detail herein. For example, the authentication application on the user device 102 can perform authentication of the user. The user can authenticate themselves to the user device via a PIN, a FaceID, a TouchID, a screen lock, etc.

[0100] After authenticating the user, the user device 102 can register and create an account with the relying party computer 104 using a cryptographic credential , as described in further detail herein. At later points in time, the user device 102 can utilize the cryptographic credential to login or otherwise interact with the website maintained by the relying party computer 104.

[0101] At step 320, the user device 102 can communicate with the provider computer 106 to back up the cryptographic credential in a secure manner. In particular, the user device 102 can mask the cryptographic credential to obtain a masked cryptographic credential . The user device 102 can provide the masked cryptographic credential to the provider computer 106 for storage.

[0102] The provider computer 106 can create a backup of the masked cryptographic credential to a cloud storage database after the user device 102 registers with the relying party computer 104. Backing up of the masked cryptographic credential leads to the technical solution of the account recovery technical problem.

[0103] Embodiments can provide for cryptographic credential security even if at some point later in time, at step 330, the attacker device 302 compromises the provider23 79571371V.1computer 106 and, at step 340, uses compromised data to attempt to login to the users’ account at the relying party computer 104. For example, the attacker device 302 may obtain the masked cryptographic credential , but cannot utilize the masked cryptographic credential since it is cryptographically obfuscated.

[0104] As another example, if the attacker device 302 obtains the detection secret set, then the attacker device 302 does not know which of the secrets in the detection secret set is the real secret. If the attacker device 302 tries to randomly select a secret (e.g., a decoy secret with high probability) in the detection secret set to use to attempt to maliciously login to the user’s account at the relying party computer 104, then the relying party computer can detect the decoy secret as in step 350.

[0105] At step 350, the relying party computer 104 can detect the use of the compromised decoy secret. The relying party computer 104 can generate a compromised data alert message based on the compromised data. The relying party computer 104 can provide the compromised data alert message to the user device 102. Embodiments allow the relying party computer 104 to detect when attackers use the compromised data and to send an alert to users’ devices without reintroducing the account recovery problem. B. Threat Model

[0106] One technical problem solving goal of embodiments is to enable the target relying party computer to detect when attackers steal a user’s cryptographic credentials leaked from the credential backup service to maliciously login to a website as the user. It is assumed that the attacker compromising the credential backup service is semi-honest. As such, attackers know any cryptographic credentials that are shared by the user device with the credential backup service to be leaked to the attackers. In the credential backup service section, above, it is discussed how attackers could access cryptographic credentials backed up by the credential backup service on their cloud storage despite performing encryption.

[0107] It can also be assumed that the target relying party computer performing detection is not compromised and is trusted (e.g., the user device is attempting to access a trusted website). To model the benefit of attackers in avoiding detection by leveraging the increasing number of data breaches from different relying party 79571371V.1computers, embodiments allow several non-target relying party computers to get passively compromised — revealing their persistent storage to attackers. However, even after getting breached, the integrity of these non-target relying party computer’s persistent storage is maintained, and non-target relying party computer’s always execute their prescribed algorithms. In other words, the goal of the semi-honest attackers is to leverage the breaches from credential backup service computer, and non-target relying party computers to compromise users’ account at a target relying party computer without getting detected.

[0108] It can be assumed that the authenticator (e.g., an application performing authentication of the user) and the user device are trusted. Compromise of these assumptions are separate issues as discussed in prior work

[0043] . Thus the authenticator, the application, and the user device can be considered together as a single trusted entity and for simplicity it is referred to it as the user device from now on. C. System Goals

[0109] Embodiments achieve a number of technical system design goals to detect when attackers compromise cryptographic credentials from credential backup service computers. These technical system design goals are advantages provided by embodiments.

[0110] An advantage of embodiments is compatibility. Since users may use different types of cryptographic authentication protocols, the ideas used by the detection framework need to be generalizable across different protocols. It is expected that the framework according to embodiments can be easily incorporated with any existing authentication protocol flow without necessitating modifications to existing authentication protocol flows. In the detection protocol section, below, it is shown how to do this for two popular cryptographic authentication protocols: FIDO2, and OTP- based user authentication.

[0111] Another advantage of embodiments is easy of deployment. To enable wide deployment, the detection framework needs to be easy to deploy. Embodiments can include an application / browser extension running on the user device that coordinates with target relying party computers to detect credential backup service computer 79571371V.1compromise. Thus, deploying the framework according to embodiments is straightforward, and as simple as users installing an application on user device, while relying party computers, and credential backup service computers make negligible changes. Besides this, additional deployment challenges are not expected. For instance, the framework according to embodiments is independent of the hardware and software of the user device, and thus the user’s do not need to obtain additional equipment (e.g., additional secure elements, etc.).

[0112] Another advantage of embodiments is that the system and methods are independent to credential backup service computer infrastructure. Since there are many types of existing credential backup service computers, the detection framework should be independent of credential backup service computer infrastructure. For instance, many prior works

[0022] on detecting and protecting users’ cryptographic credentials of digital wallets rely on the assumption that credential backup service computer is decentralized. The framework according to embodiments does not require such assumptions and is compatible with any credential backup service computer implementation.

[0113] Another advantage of embodiments is that it is account recovery friendly. The detection framework should not rely on users having multiple devices, and being able to sync their credentials across their devices for account recovery friendliness for two reasons. First, many users have only one device [7] and, secondly, syncing credentials across devices is challenging for many users

[0058] . The framework according to embodiments can require users to rely on simple secret management skills such as remembering a system-generated short secret. Users could even opt for user-chosen secrets, and the framework according to embodiments will not degrade the security strength of the user-chosen secret.

[0114] Another advantage of embodiments is the efficacy of the detection framework. To be effective, a detection framework should have a high true detection probability (TDP) and a low false detection probability (FDP). This is while considering the practically feasible yet strong threat model scenario when attackers could breach the persistent storage of the non-target relying party. The effectiveness of embodiments is gauged via model checking as described in further detail in the detection effectiveness section, below. 79571371V.1V. DETECTION SECRETS

[0115] The framework according to embodiment can utilize a set of detection secrets,denoted by = { 1, 2, ,— one of these secrets is the real secret denoted by, and the other secrets are referred to as decoy secrets. The notation is overloaded slightly and use to represent the information needed to identify the real secret from a given detection secret set . The information needed to identify the real secret can be referred to as a real secret identifier or a user credential (e.g., a user survivable secret). The user credential is only known to the user and not shared with either credential backup service or any relying party.

[0116] It can be assumed that two properties of the user credentialare that the user credential is survivable and that the user credential is always accessible by the user (even in the case of user device loss or failure). For example, the user credential could be instantiated in practice by secrets that can be easily remembered by the user (e.g., phone numbers, birth dates, etc.) or retrievable by the user (e.g., credit card numbers, bank account numbers, social security numbers, etc.). The options of instantiating the user credential with a properly secure user secret will be discussed further in the discussion section, below.

[0117] The framework according to embodiments may utilize a randomized decoy generation procedure (GenDetectSecret) and a deterministic detection secret selection procedure (SelectRealSecret). Specifically, the randomized decoy generation procedure (GenDetectSecret) produces a detection secret set of size +1 when given an integer size and a detect secret space specified by the process. The deterministic detection secret selection procedure (SelectRealSecret) takes thedetection secret set and the user credential as input, and outputs the real secretthat is in the detection secret set). The detection secret set includesthe real secretand a plurality of decoy secrets .

[0118] An instantiation example of the randomize decoy generation procedure (GenDetectSecret) and the deterministic detection secret selection procedure (SelectRealSecret) are respectively illustrated in Tables 1 and 2, below. The randomize decoy generation procedure (GenDetectSecret) and the deterministic detection secret selection procedure (SelectRealSecret) can aid a device in generating27 79571371V.1a detection secret set and select a real secret from the detection secret set based on the user credential so that given a detection secret set , the device can always recover the real secret given the user credential while the attacker can only make guesses on which among the detection secret set is the real secretwithout knowledge of the user credential .Table 1: Example instantiation of a randomize decoy generation procedure (GenDetectSecret)

[0119] Table 1 depicts a process of generating the detection secret set . The user device 102 can generate the detection secret set based on the integer size and the detect secret space . The user device 102 can start with an empty set 0 for the detection secret set . The user device 102 can, for a number of 1 iterations,(e.g., for 1,2, … 1 ) randomly generate a secret (e.g., ) and include the secretinto the detection secret set . The secrets can be randomly selected and / or generated from the detect secret space . In some embodiments, the user device 102 may not need to generate the detection secret set based on the detect secret space . Rather, the user device 102 can randomly generate values for the secrets that are to be added to the detection secret set over each iteration. The detect secret space can be 0,1 which represents the space of all binary strings of length . Forexample, if the length is equal to two (e.g., 2), then 0,1 , which isequivalently 00, 01,10, 11 .

[0120] As an illustrative example, the user device 102 can generate a detection secret set that includes a first secret of “1234567890,” a second secret of “846973089,” and a third secret of “467099438.” The first secret, the second secret, 79571371V.1and the third secret can be random values that do not match other secrets in thedetection secret set .Table 2: Example instantiation of a deterministic detection secret selection procedure (SelectRealSecret)

[0121] Table 2 depicts a process of selecting a secret of the detection secret set to be the real secret while the remaining secrets are decoy secrets. The user device 102 can perform a hash sort operation (e.g., HashSort) to sort all elements in the detection secret set according to their hash values, as determined by Hash, and output these elements as an ordered list. After sorting the secrets in the detection secret set , the user device 102 can determine a hash value of the user credential (e.g., ). The user device 102 can use modular arithmetic to determine an index of the sorted detection secret set using the hashed user credential. As such, the user credential is used to select a secret in the detection secret set as being the real secret .

[0122] The difficulty faced by the attacker identifying the real secret from the detection secret set with a flatness, defined as follows, can be measured and evaluated as indicated in Table 3, below.79571371V.1Table 3: Attacker difficulty evaluation

[0123] The flatness of the detection secret set in respect to the real secret is defined as:, , and amaximum is taken over all distinguishing attackers .

[0125] It is noted that the randomize decoy generation procedure (GenDetectSecret) can be completely randomized, where the detection secret set is uniformly randomly selected from the entire detection secret space . VI. FRAMEWORK DESIGN

[0126] The framework of systems and methods will now be discussed. In particular, a credential backup and restoration protocol, a detection protocol, flatness preservation, and performance will be discussed.

[0127] To enable a relying party computer to detect the compromise of a credential backup service computer, the framework according to embodiments includes a new credential backup protocol and a detection mechanism that can be tailored for a specific authentication methods in use today. A. Credential Backup and Restoration Protocol

[0128] FIG. 4 shows a credential backup and restoration protocol. The method illustrated in FIG.4 is independent of the underlying authentication method utilized by the relying party computer. The method illustrated in FIG. 4 includes five phases. A first phase 402 can be a credential backup service account setup phase. A second phase 404 can be a device setup phase. A third phase 406 can be a relying party account registration phase. The fourth phase 408 can be a credential backup phase. The fifth phase 410 can be a credential restoration phase. Tables 4, 5, and 6, below, show various building block procedures utilized during the method illustrated in FIG. 4. Table 4 illustrates an authentication credential encryption method. Table 5 illustrates 79571371V.1a decoy verifier generation method. Table 6 illustrates an authentication credential decryption method.

[0129] In the first phase 402, during credential backup service account setup, the system can perform an initialization process when the user of the user device 102 signs up for a new account at the provider computer 106 (e.g., a credential backup service computer).

[0130] At step 412, the user device 102 can obtain a user credential from the user of the user device 102. For example, the user device 102 can prompt the user to input the user credential into the user device 102. The user credential can be a password, a PIN, a passphrase, an answers to a secret questions, a graphical password, a user biometric, or other secret known to the user.

[0131] At step 414, after obtaining the user credential , the user device 102 can generate a detection secret set . The detection secret set can be of size 1, where there are decoy secrets and one real secret (that is to be selected) in the detection secret set . The user device 102 can generate the detection secret set using a randomize decoy generation procedure (GenDetectSecret) as described in reference to Table 1.

[0132] At step 416, after generating the secrets of the detection secret set , the user device 102 can select a secret in the detection secret set to the be real secret . The user device 102 can utilize a deterministic detection secret selection procedure (SelectRealSecret) to determine the real secret . The real secretcan be determined based on the detection secret set and the user credentialAs such, the real secret can be associated with the user credential . The user device 102 can generate the real secretusing the process described in reference to Table 2.

[0133] With these methods, the user device 102 can generate the detection secret set of size + 1 and the real secret. The real secretis never sent to either the relying party computer 104 or the provider computer 106 for improved security. The real secret can be saved locally on the user device 102.

[0134] At step 418, to identify the user account at the provider computer 106, the user device 102 can generate a uniformly randomly chosen backup account identifier of length based on the user credential . In some embodiments, the backup 79571371V.1account identifier can further be based on other system configuration parameters, such as a length and a dimensionality of a secret space . The backup account identifier can identify an account that the user device 102 has or is establishing with the provider computer 106.

[0135] At step 420, the user device 102 can store the backup account identifier , the real secret, and the detection secret set .

[0136] At step 422, the user device 102 can generate an enrollment request message comprising the backup account identifier and the detection secret set . After generating the enrollment request message, the user device 102 can provide the enrollment request message to the provider computer 106.

[0137] At step 424, after receiving the enrollment request message, the provider computer 106 can enroll the user device 102 into a backup service. The provider computer 106 can store the backup account identifier and the detection secret set into a database.

[0138] In the second phase 404, during device setup, a user that is already associated with a user device (e.g., a previously used user device) that is enrolled with the provider computer 106 can utilize a new user device (e.g., the user device 102) to obtain the backup account identifier and the detection secret set . The user device 102 can communicate with the provider computer 106 to associate the user device 102 with the already created data stored in the provider computer 106 that is associated with the user of the user device 102.

[0139] For example, a user, who already has a credential backup service account, can enable credential synchronization, backup, and restoration service via the provider computer 106 on a new user device (e.g., a phone or a laptop) by registering the user device 102 with the provider computer 106 and completing device setup. In some embodiments, the user device 102 can lose access to the real secret (e.g., the real secret is deleted, the user device 102 is lost or destroyed, etc.). The user can utilize the user device 102 or a new user device to reobtain the real secret

[0140] In some embodiments, the user device 102 can generate a device setup request message. The device setup request message can request for the provider computer 106 to provide backed-up data to the user device 102. 79571371V.1

[0141] In some embodiments, the provider computer 106 can require that the user device 102 and / or the user be authenticated. The user device 102 can include an authentication application that can authenticate the user via user inputs. For example, the user device 102 can prompt the user to input a fingerprint biometric into the user device 102. The user device 102, in conjunction with the authentication application, can compare the fingerprint biometric to a stored user biometric.

[0142] If the fingerprint biometric matches the stored user biometric, then the user device 102, in conjunction with the authentication application, can determine that the user is authentic and can generate data that attests to the user’s authenticity. For example, the authentication application can sign a proof of user authenticity using an authentication application private key, the signature of which can be verified trusted by the provider computer 102. However, it is understood that other authentication methods can be utilized to authenticate the user and / or the user device to the provider computer 102.

[0143] If the fingerprint biometric does not match the stored user biometric, then the user device 102 can terminate the process.

[0144] At step 426, the provider computer 106 can allow the user device 102 to download the previously stored backup account identifier and the detection secret set .

[0145] For example, the provider computer 106 can generate a device setup response message comprising the backup account identifier and the detection secret set . The provider computer 106 can provide the device setup response message to the user device 102.

[0146] At step 428, the user device 102 can prompt the user to input the user credential into the user device 102.

[0147] At step 430, upon receiving the user credential from the user, the user device 102 can execute a deterministic detection secret selection procedure SelectRealSecret( , ) to recover the real secret . Selecting the real secret fromthe detection secret set using the user credential is described above in reference79571371V.1

[0148] At step 432, The user device 102 can then store the backup account identifier ,the detection secret set , and the real secret . After determining the real secretthe user can start using the user device 102 to register new accounts at relyingparty computers during the third phase 406 or to further restore credentials that have been backed up at the provider computer 106 during the fifth phase 410.

[0149] In the third phase 406, during relying party account registration, the user device 102 can register with the relying party computer 104 using the detection secret set and / or data derived therefrom.

[0150] At step 434, the user device 102 can generate a registration request message that includes a request to register with the relying party computer 104. For example, the registration request message can request to register to access a secure webpage maintained by the relying party computer 104. The user device 102 can provide the registration request message to the relying party computer 104.

[0151] At step 436, after receiving the registration request message, the relying party computer 104 can obtain a relying party computer identifier . For example, the relying party computer 104 can retrieve the relying party computer identifier from a memory. The relying party computer identifier can be a unique identifier that identifies the relying party computer 104. Other relying party computers can have different relying party computer identifiers.

[0152] The relying party computer 104 can generate a registration response message that includes the relying party computer identifier . In some embodiments, the registration response message can include a request for further data from the user device 102. For example, the registration response message can request a user account identifier , and a verification key associated with a set of verification keys .

[0153] The relying party computer 104 can provide the registration response message to the user device 102.

[0154] At step 438, after receiving the registration response message, the user device 102 can generate a user account identifier for an account that is to be associated with the relying party computer 104. The user device 102 can randomly generate the user account identifier . For example, the user device 102 can 79571371V.1$generate the user account identifier as follows:0, 1 . The user accountidentifier can identify an account that is being established for the user device 102 with the relying party computer 104.

[0155] At step 440, after generating the user account identifier , the user device 102 can generate a cryptographic credential s . The user device 102 can randomlygenerate the cryptographic credential . For example, the user device 102 can $ generate the cryptographic credential as follows:0, 1 . The cryptographiccredential can be secret data that is to be only known by the user device 102. The cryptographic credential can be a cryptographic private key.

[0156] At step 442, after generating the cryptographic credential , the user device 102 can generate a verification key based on the cryptographic credential. The user device 102 can generate the verification key using a verification generator (VerifierGen) process. The implementation of the verification generator is authentication method-specific in that the verification generator takes, as input, authentication secret(s) (e.g., a signature signing key, an OTP seed, or a password) and outputs an authentication verifier v for the relying party computer 104 (e.g., a public verification key, the same OTP seed, or a salted and hashed password). For example, the cryptographic credential and the verification keycan form a private- public key pair.

[0157] At step 444, after generating the verification key, the user device 102 can encrypt or mask the real secret and the cryptographic credential to obtain a masked cryptographic credential s and a uniformly random value . The user device 102 can encrypt or mask the real secret and the cryptographic credentialusing an authentication credential encryption method described in reference to Table 4,79571371V.1Table 4: Example instantiation of an authentication credential encryption method (EncAuthCred)

[0158] The authentication credential encryption method can allow a device (e.g., the user device 102) to obfuscate (e.g., by masking) the cryptographic credential . To mask the cryptographic credential as a masked cryptographic credential s, the user device 102 can generate a uniformly random value . The uniformly random value can be a random value.

[0159] After generating the uniformly random value , the user device 102 can generate a recovery key using a key derivation function (KDF) based on the real secret and the uniformly random value .

[0160] The user device 102 can then mask the cryptographic credential using the recovery key to obtain the masked cryptographic credential s. Later, during credential backup, the user device 102 can only send the masked cryptographic credential s to the provider computer 106 such that the provider computer 106 neverobserves the cryptographic credential s and the provider computer’s 106 access tothe cryptographic credential s is obfuscated by the verification key .

[0161] By encrypting or masking the real secretand the cryptographic credential , the user device 102 can prepare the cryptographic credential for later credential backup with the provider computer 106 while shielding the cryptographic credentialfrom the provider computer 106.

[0162] At step 446, after obfuscating the cryptographic credential, the user device 102 can generate a set of verification keys V. The user device 102 can generate the set of verification keys V based on the detection secret set , the masked cryptographic credential s, and the uniformly random value . The user device 102 can generate the set of verification keys V using the decoy verifier generation method(DecoyVerifierGen) described in reference to Table 5.79571371V.1Table 5: Example instantiation of decoy verifier generation method (DecoyVerifierGen)

[0163] The decoy verifier generation method can accept the detection secret set , the masked cryptographic credential s, and the uniformly random value as input and can generate 1 verifier keys corresponding to each detection secret in the detection secret set (e.g., ). To do this, for each secret in the detection secret set , a recovery key is generated by a value returned by , — the samekey derivation function used in EncAuthCred. Then each is used to unmask s in the following way: , and VerifierGen procedure generates the verification. The set of verification keys Vis sent to relyingparty.

[0164] At step 448, after generating the set of verification keys V, the user device 102 can store the user account identifier , the relying party computer identifier , the cryptographic credentialthe verification key, the masked cryptographic credential s, and the uniformly random value in association with one another in a memory of the user device 102.

[0165] At step 450, the user device 102 can generate an enrollment completion message comprising the user account identifier , the verification key, the set of verification keys V. The user device 102 can provide the enrollment completion message to the relying party computer 104.

[0166] At step 452, upon receiving the set of verification keys V (also referred to as a decoy verifier set), the relying party computer 104 can select a subset of verification keys V’ from the set of verification keys V. The subset of verification keys V’ can 79571371V.1include decoy verifiers that are considered to be active. An active decoy verifier, if received by the relying party computer 104 at any later point in time, can trigger a compromise detection alarm. The relying party computer 104 can select a fraction of verification keys in the set of verification keys V to include in the subset of verification keys V’. The other verification keys in the set of verification keys V that are not included in the subset of verification keys V' can include the real verification key and any other verification keys that are viewed as valid verification keys for user authentication. Such verification keys that are not in the subset of verification keys V’ can be referred to as inactive verification keys along with the real verification key . The subset of $ verification keys V’ can be determined as: ,\ .

[0167] For example, in some embodiments, there can be one valid and real signing key and a corresponding real verification key. The rest of the decoy verification keys can be divided into two sets: 1) active decoy verification keys (denoted by V’) and 2) inactive decoy verification keys (denoted by \ ). If an attacker device obtains and logs in with the signing key verifiableor with an inactive decoy key, the attacker device logs in without detection. The attacker device can be detected if the attacker device logs in with a key verifiable by an active decoy verification key.

[0168] The use of inactive decoy verification keys can help defend against situations in which a user reuses a same user credential across more than one relying party computer, where the attacker device can leveraged the reused same user credential to narrow down the real index in the set of verification keys. The real index is deterministically produced based on the user credential . If there are no inactive decoy verification keys, a lucky guess by the attacker at a first relying party computer will let the attacker know the real index and use it to avoid detection at a second relying party computer, a third relying party computer, etc. for the same user. However, with inactive decoy verification keys, even if the attacker luckily logs in without detection at a first relying party computer, it is possible that the attacker device’s guess is in fact an inactive decoy verification key (e.g., not the valid real verification key), by continuing to use the same index, the attacker device still risks being detected by the second relying party computer, the third relying party computer, etc. because an index pointing to an inactive decoy at the first relying party computer may point to active 79571371V.1decoys at second relying party computer, the third relying party computer, etc. which increase the overall detection power of the system.

[0169] The size of the subset of verification keys V’ can be adjusted based on cross- relying party threats. If there is no threat of cross-relying party attacks, then the subsetof verification keys V’ can include all of the decoy keys (e.g., ’ / ), meaningthat there are no inactive decoy keys.

[0170] At step 454, the relying party computer 104 can store the user account identifier , the set of verification keys V, and the subset of verification keys V’.

[0171] In some embodiments, the relying party computer 104 can generate a successful registration confirmation message. The relying party computer 104 can provide the successful registration confirmation message to the user device 102.

[0172] In some embodiments, can be referred to as the set of active decoy verifiers for the current relying party because, as illustrated in FIG. 6, an authentication response successfully verified by any of these active decoy verifiers can trigger a credential backup service compromise detection alarm. In contrast, other decoyverifiers in \ ({v } ) are inactive and, together with the real verifier, v , will beviewed as valid verifiers — successful verification by these verifiers will lead to successful logins. FIG. 6 shows detection techniques of credential backup service compromise using embodiments when users attempt to login to relying party using FIDO2 and OTP-based user authentication protocol respectively.

[0173] In the fourth phase 408, during credential backup, after receiving the successful registration confirmation from relying party computer 104, the user device 102 can communicate with the provider computer 106 to securely back up information related to the user account with the relying party computer 104.

[0174] At step 456, the user device 102 can generate a credential backup message comprising the backup account identifier (e.g., that identifies an account with the provider computer 106), the user account identifier (e.g., that identifies an account with the relying party computer 104), the relying party computer identifier , the masked cryptographic credential s, and the uniformly random value . The user device 102 can provide the credential backup message to the provider computer 106. The user device 102 can provide the masked cryptographic credential s, rather than the 79571371V.1cryptographic credential s to the provider computer 106 to further increase security inthe case of a data breach at the provider computer 106.

[0175] At step 458, after receiving the credential backup message, the provider computer can store the backup account identifier , the user account identifier , the relying party computer identifier , the masked cryptographic credential s, and the uniformly random value into a database.

[0176] In the fifth phase 410, during credential restoration, the user device 102 or a different user device operated by the user can communicate with the provider computer 106 to restore a credential. For example, the user may have lost a previous user device and is attempting to restore the credential to the user device 102. The provider computer 106 can allow the user device 102 to restore a credential for a certain account due to the need of credential synchronization across multiple devices or credential recovery to a new device that has gone through a device setup phase.

[0177] The user device 102 can generate a credential restoration request message to submit to the provider computer 106. The credential restoration request message can include a request to obtain the backed-up data. In some embodiments, the credential restoration request message can include authentication data. The user device 102 can provide the credential restoration request message to the provider computer 106. In some embodiments, the credential restoration request message can comprise the backup account identifier that identifies the account maintained by the provider computer 106 on behalf of the user device 102.

[0178] In some embodiments, the provider computer 106 can authenticate the user and / or the user device 102. For example, prior to re-obtaining the masked cryptographic credential from the provider computer 106, the user device 102 can authenticate the user of the user device 102 with an authentication application installed on the user device 102. For example, the authentication application can verify a password, a biometric, etc. input by the user. The user device 102 can provide the authentication results to the provider computer 106 to proceed with obtaining the backed-up data.

[0179] At step 460, the provider computer 106 can provide the backed-up data to the user device 102. The provider computer 106 can generate a credential restoration response message comprising the user account identifier , the relying party 79571371V.1computer identifier , the masked cryptographic credential s, and the uniformly random value . The provider computer 106 can provide the credential restoration response message to the user device 102.

[0180] At step 462, the user device 102 can obtain the real secret from memory. The real secret can be securely stored in the user device 102. For example, the real secret can be stored in the user device 102 at step 420.

[0181] At step 464, after receiving the credential restoration request message, the user device 102 can utilize the authentication credential decryption methodDecAuthCred( , s, ) to determine the cryptographic credential from the maskedcryptographic credential s, as described in reference to Table 6, below. This method reverses the effects of masking the cryptographic credential with the recovery key . For example, the user device 102 can unmask the masked cryptographiccredential s using the real secret and the uniformly random value .Table 6: Example instantiation of an authentication credential decryption method (DecAuthCred)

[0182] Table 6 illustrates an authentication credential decryption method that can determine the cryptographic credential from the real secret, masked cryptographic credential s, and the uniformly random value . For example, the user device 102 can generate a recovery key using a key derivation function (KDF). The recovery key can be generated using the real secret and the uniformly random value . The recovery key can be the same recovery key used to mask the cryptographic credential. The user device 102 can use the recovery key to unmask the masked cryptographic credential s to obtain the cryptographic credential . 79571371V.1

[0183] At step 466, after determining the cryptographic credential , the user device 102 can recover (e.g., determine) the verification key. The user device 102 can determine the verification key using the cryptographic credential . For example,the user device 102 can perform a VerifierGen(s ) method to recover the verificationkey v that corresponds to the cryptographic credential .

[0184] At step 468, after recovering the verification key , the user device 102 can store the user account identifier , the relying party computer identifier , the masked cryptographic credential s, the uniformly random value , the cryptographiccredential , and the verification key v .

[0185] The user device 102 can utilize the cryptographic credential for future authentication requests with the relying party computer 104 identified by the relying party computer identifier for an account identified by the user account identifier .

[0186] In some embodiments, for correctness, observe that such that =,and = . Thus s = s since s = == s . Moreover sincev VerifierGen(s ) and s = s , it can seen that v becomes the same as v .B. Detection Protocol

[0187] The provider computer 106 compromise detection process can occur between the user device 102 and the relying party computer 104. FIG.5 illustrates an authentication method between a user device and a relying party computer during which, the relying party computer can detect provider computer 106 compromise. The authentication method described in reference to FIG. 5 can include any suitable authentication method. FIG. 6 describes two example authentication methods including FIDO2 and OTP-based user authentication. FIG. 6 includes a detection method for passkeys 600 and a detection method for one-time passwords 650. 1. Detection protocol method

[0188] FIG.5 shows a flow diagram illustrating an authentication method according to embodiments. The method illustrated in FIG. 5 can be performed by a computer such as the relying party computer 104 when the user device 102 is attempting to 79571371V.1access an account maintained by the relying party computer 104 on behalf of the user device 102.

[0189] The relying party computer 104 can being a process to verify that the user device 102 is an authentic user device that should be provided access to the account.

[0190] In some embodiments, the relying party computer 104 can generate authentication data that is a challenge in response to the user account identifier. The relying party computer 104 can provide the challenge to the user device 102. The user device can sign the challenge to form a signed challenge, which can be authentication data that is provided to the relying party computer 104.

[0191] At step 502, the relying party computer 104 can receive a user account identifier and authentication data from the user device 102 that is attempting to access the account. The authentication data includes data modified using a cryptographic credential that is associated with a verification key. For example, the authentication data can include a signed challenge that is signed using the cryptographic credential. As another example, the authentication data can be a one-time password generated based on the cryptographic credential. The type of authentication data can depend upon the type of authentication utilized by the system. For example, the system can utilize FIDO2 passkeys or one-time passwords, as described in further detail below. The system can utilize any other type of authentication process.

[0192] In some embodiments, during verification with the relying party computer 104, the user device 102 can sign a message with the cryptographic credential corresponding to the verification key to produce a signed message. The user device 102 can transmit the signed message to the relying party computer 104. In some embodiments, the user device 102 can also provide the verification key to the relying party computer 104 along with the signed message to aid the relying party computer 104 in identifying which verification key to utilize from verification keys stored at the relying party computer 104.

[0193] At step 504, after receiving authentication data, the relying party computer 104 can determine whether or not the authentication data includes data modified using the cryptographic credential that is associated with a stored verification key in a set of verification keys or in a subset of verification keys stored in the computer. The subset of verification keys include decoy verification keys. 79571371V.1

[0194] For example, the relying party computer 104 can determine whether or not the authentication data is signed authentication data that is signed using the cryptographic credential, which can be verified using a verification key in the set of verification keys or in the subset of verification keys.

[0195] If the authentication data includes data modified using the cryptographic credential that is associated with a stored verification key in the subset of verification keys, then the relying party computer 104 can determine that the current user device 102 is a malicious user device that is using a decoy key to try to access the user’s account. The relying party computer 104 can generate a cryptographic credential compromise message that indicates that a provider computer that stores cryptographic credentials and / or data related thereto or the user device of the user is compromised.

[0196] At step 508, the relying party computer 104 can provide the cryptographic credential compromise message to the user associated with the account using an alternate communication channel. The alternate communication channel can be email, SMS, a message in the webpage hosted by the relying party computer 104 for the user, etc.

[0197] In some embodiments, the relying party computer 104 can lock access to the account upon detecting the use of a decoy key, by a user device, that is in the subset of verification keys stored by the relying party computer 104. 2. Detection for FIDO2 based authentication

[0198] A specific detection method for FIDO2 will be described in reference to the detection method of passkeys 600 in FIG. 6, and in reference to the description of FIDO2 above.

[0199] At step 602, the user device 102 can provide a user account identifier , which identifies an account maintained by the relying party computer 104 on behalf of the user device 102, to the relying party computer 104.

[0200] At step 604, the relying party computer 104 can generate a challenge for the user device 102. The challenge can include a FIDO2 challenge. A FIDO2 can be a message that is to be signed by a private key (e.g., the cryptographic credential ) after a user of the user device 102 is authenticated (e.g., by an authenticator application). 79571371V.1

[0201] The relying party computer 104 can provide the challenge to the user device 102.

[0202] At step 608, after receiving the challenge , the user device 102 can sign the challenge with the cryptographic credential , which can be a private key. By signing the challenge , the user device 102 can obtain a signed challenge .

[0203] In a FIDO2 process, the user device 102 can include an authenticator application (e.g., a FIDO2 authenticator) that can authenticate the user of the user device. The user device 102 can prompt the user to authenticate themselves using the authenticator application prior to signing the challenge with the cryptographic credential . The user device 102 can wait to sign the challenge until the user has been authenticated.

[0204] At step 610, after signing the challenge , the user device 102 can provide the signed challenge and the verification key to the relying party computer 104.

[0205] At step 612, the relying party computer 104 can obtain the signed challenge and the verification key from the user device 102. The relying party computer 104 can perform a set membership test for the received verification keyin the set of verification keys V and / or the subset of verification keys V’. For example, the relying party computer 104 can determine whether or not the verification key isincluded in the set of verification keys V and / or the subset of verification keys V’.

[0206] If the received verification key is not included in the set of verification keys V, then the relying party computer 104 can determine that the login attempt failed. The relying party computer 104 can notify the user device 102 of the failed login attempt.

[0207] If the received verification key is included in the subset of verification keys V’, then the relying party computer 104 can determine that the verification key is a decoy verification key that is currently being used by a malicious party attempting to access the user’s account. The relying party computer 104 can generate a notification that indicates that data associated with the user and / or the user device 102 has been breached from the provider computer 106. The relying party computer 104 can provide the notification to the provider computer 106 and / or to the actual user device 102 associated with the user of the user account. 79571371V.1

[0208] Otherwise, the received verification key is included in the set of verification keys as the correct verification key. The relying party computer 104 can proceed to grant access to the secure webpage (or other reason for authentication) to the user device 102. 3. Detection for one-time password based authentication

[0209] The relying party computer 104 and the user device 102 can also utilize one- time password based authentication methods to authenticate the user when the user attempts to access the account maintained by the relying party computer 104. The one-time password based authentication shares some similarities with the FIDO2- based authentication. However, there are some differences in the authentication method, which are illustrated in the detection method for one-time passwords 650 in FIG.6.

[0210] One-time password-based user authentication is symmetric (e.g., the same cryptographic credential is shared by the user device 102 and the relying party computer 104) and thus the verification generation method described herein takes the cryptographic credentialand outputs the same cryptographic credential ratherthan determining a corresponding public key (e.g., verification key ) (e.g.,).

[0211] At step 652, the user device 102 can generate a one-time passwordgenerated using a hash-based message authentication code function (e.g.,, .

[0212] At step 654, the user device 102 can provide the one-time password and the user account identifier to the relying party computer 104.

[0213] At step 656, after receiving the one-time password and the user account identifier , the relying party computer 104 can generate a one-time password ’ using verification keys in a set of verification keys or in a subset of verification keys. The relying party computer 104 can compare generated one-time passwords ’ to the received one-time password . The relying party computer 104 can determine whether or not there exists a verification key in the subset of verification keys (e.g., such that the one-time passwords match (e.g., , similar to the detection process for passkeys described above. The relying party computer 104 can determine 79571371V.1whether or not the login attempt should lead to a provider computer compromise alarm or a normal successful login based on the user device 102 utilizing the correct cryptographic credential in forming the one-time password, where the cryptographic credential is the same as one of the verification keys in the symmetric key scenario. 4. Detection Notifications

[0214] The framework according to embodiments can include the relying party computer 104 notifying the user device 102 of the potential compromise of their authentication credentials from the provider computer 106. To do so, the relying party computer 104 can notify the user actively through established communication channels (e.g., email, app notifications, SMS, or phone calls). In the case where all communication channels between the user device 102 and the relying party computer 104 are not available, the last resort can be a passive notification: the relying party computer 104 can notify the user device 102 on the webpage or application maintained by the relying party computer 104. When the user device 102 later attempts to log into their account they can view the alert. Due to this, the user could decide to reset their authentication credentials, better secure their credential backup service account, and / or consider switching to a different provider computer 106. C. Flatness Preservation

[0215] It is shown that the flatness of detection secrets used in embodiments is preserved despite the compromise of provider computer cryptographic data storage. Specifically, systems can first capture the attacker’s ability to get a user’s credential backup entries for multiple accounts leaked from provider computer by defining the following provider computer oracle in Table 7, that takes the real secret as inputand outputs a pair ( , ) for each oracle query.79571371V.1Table 7: Credential backup service (CBS) Oracle

[0216] Embodiments consider the following experiment, in Table 8, to characterize how much better a decoy distinguishing adversarycan distinguish the real secret when it additionally has access to such a credential backup service oracle , where the user account identifier and the relying party computer identifier are ignored due to the independence of the detection secret set and the real secret on them:Table 8: Decoy distinguishing adversary evaluation

[0217] The advantage of the decoy distinguishing adversary is defined as:

[0218] where the maximum is taken over all flatness adversaries .

[0219] Proposition 5.1:flt , .

[0220] Proof of proposition 5.1: Given the decoy distinguishing adversary for theexperimenta decoy distinguisher for the experimentExpt ,, defined in the detection secrets section, above. provides withdetection secret set that it receives from the experiment is constructed. For each oracle query made by , chooses and from 0, 1 uniformly at random,and returns ( , ) to . Finally outputs 1 if outputs 1. Since ( , )79571371V.1EncAuthCred( , s ) for any s sampled from 0, 1 at random, ( , ) and ( , ) aredistributed identically for each oracle query simulated by :

[0221] Also, we can construct a decoy distinguishing adversary for the experiment who runs a decoy distinguisher for the experiment Expt , as a subroutine. Withoutquerying its oracle, the decoy distinguishing adversary provides the detection secret set as ’s input and outputs 1 if outputs 1 so:,D. Performance

[0222] Each authentication instance with a relying party computer requires no additional operation on the user device side. The number of additional relying party computer operations for authentication is determined by the specific authentication method in use. For FIDO2-based authentication, since an authentication response is sent along with the verification key to the relying party computer from the user device, the relying party computer only needs to execute one additional – a set membership test to check?. For the one-time password-based authentication, the relying party computer can perform additional verification operations because the relying party computer may be unaware of which seed is used by the user device for generating the incoming one-time password. These verification operations include runningtimes and one-time password comparisons.

[0223] There are three setup procedures of the framework according to embodiments (e.g., EncAuthCred, DecAuthCred, and DecoyVerifierGen), which are intended for infrequent events such as account creation or credential synchronization rather than daily authentication. EncAuthCred and DecAuthCred are specifically for credential synchronization via the provider computer. For each execution of EncAuthCred and DecAuthCred the user device only needs to perform two operations: 79571371V.1a key derivation function and an XOR. DecoyVerifierGen can be used when a user device creates an new relying party computer account or (re)sets their authentication credentials for their relying party computer accounts. The user device can execute a key derivation function, XOR, and VerifierGen operations for + 1 times each, which takes roughly times longer in credential generation and registration than without embodiments. VII. DETECTION EFFECTIVENESS

[0224] Detection effectiveness will now be discussed in reference to true detection and false detection. A. True Detection 1. Modeling detection secrets

[0225] Recall that in the detection secrets section, above, it is specified that the framework can utilize the authentication credential encryption method (GenDetectSecret) that outputs a detection secret set of a given size and flatness. For generality, provided by the true detection analysis here, the formal treatments of password guessing in prior work (e.g.,

[0040] ) are followed and, instead of providing the attacker with a credential secret set with a certain flatness, in a test, a credential secret of size + 1 that is perfectly flat can be provided to the attacker, namely:

[0226] As such, the attacker’s ability to guess the real secretin the analysis can be modeled as a function of , avoiding additional – and possibly inaccurate – assumptions on the probability distribution and flatness of the detection secret set for a specific type of detection secret instantiated in practice (e.g., by user-chosen passwords or PINs).

[0227] Let( )denote the subset of detection secrets corresponding to the subset ofauthentication verifiers that always fall into \ ’ across breached relying partycomputers that adopt the same fraction of verification keys. The probability of the attacker triggering a false alarm when impersonating the user device at an unbreached 79571371V.1relying party computer is the probability of the event that the attacker picks a detection secret from( ), uses it together with a masked cryptographic credential to derive an cryptographic credential , and produces a valid authentication response that can be verified by an active decoy verifier at the unbreached relying party computer. 2. True detection probability

[0228] To capture the attacker’s best strategy for minimizing the true detection probability when attacking multiple relying parties, a Markov decision process is leveraged to model these optimized and realistic attacks. A Markov decision process consists of a set of states and potential transitions between them. When the Markov decision process is in a specific state, the attacker can select one of several available actions, resulting in a probability distribution over the possible next states based on the current state and the action selected. In experiments, the attacker is allowed to learn the detection secret set , the masked cryptographic credential , and the uniformly random value for each relying party computer where the user device has an account. Also the attacker has a passive observation of breached persistentstorage from breached relying party computers, with each snapshot including | |active decoy verifiers. The attacker’s goal here is to impersonate a user device at a specified number of unbreached relying party computers (denoted by ) by choosing the optimal set of actions such that the expected probability of entering the final state corresponding to triggering a breach alarm at least one of the unbreached relying party computers under attack is minimized. More specifically, the Markov decision process models an attacker who does the following.

[0229] The attacker randomly selects a detection secret from( ), derives an authentication signing key using the detection secret set , the masked cryptographic credential , and the uniformly random value , and attempts to authenticate at a first relying party computer.

[0230] If the selected detection secret corresponds to a verifier at the first relying party computer, then the attacker enters a detected state and the experiment is over. Otherwise, this relying party computer is considered compromised without detection, and if 2, the attacker can choose to either 1) reuse the same detection secret used in the last attack or 2) randomly select a different detection secret from (), and then attack the next relying party computer.79571371V.1

[0231] The attacker repeats the above attacks until it either 1) moves to the detected state or 2) completes attacking and compromising all relying party without detection.

[0232] The experiment outputs the minimum expected probability of the attacker entering the detection state over all possible action paths, as reported in FIG.7 and FIG.8.

[0233] In FIG. 7, with set to 32, FIG. 7a-d correspond to four different values of breached relying party computers that vary from 0 to 3. In FIG.7a (e.g., when = 0), a larger results in a higher probability of the attacker triggering a detection alarm because it is more likely that the verifier corresponding to the selected detection secret falls into . Also, attacking more relying party computers exposes the attacker to greater risks in triggering a detection alarm more than one relying party computer. However, as is increased to 1, 2, or 3 as shown in FIG. 7b, FIG. 7c, and FIG.7d respectively, the detection probabilities for a relatively high (e.g., 0.9) drop significantly but almost keep unaffected for a relatively low (e.g., 0.1). This is because a higher leads to a smallerI given a fixed , and, as a result, increase the possibility that the attacker selects the real detection secret at the very first attack.

[0234] FIG.8 shows the minimum expected true detection probabilities as a function of , given a fixed and that the attacker has observed breaches from relying party computers and attempts to compromise the user’s accounts at unbreached relying party computers. An observation here is that when reaches a certain level (e.g., 32) increasing further can hardly provide a significant boost in the minimum expected probability. This observation provides an informative insight for determining an optimal proper that provides a good balance between the framework according to embodiment’s detection accuracy and performance, considering that an unnecessarily larger would negatively affect the overall performance of the framework according to embodiments as well as its false alarm probabilities, described below.

[0235] The results presented here are conservative. The model checking experiments computed the results for the best strategy attacker within the threat model, which serves as the lower bound of the expected true detection probabilities for real world attackers if they have the same level of knowledge as the aforementioned Markov decision process. 79571371V.1B. False Detection

[0236] The effectiveness of detection systems is significantly impacted by the risk of false alarms [25, 38, 57]. A false breach alarm in the framework occurs when someone without access to a compromised masked cryptographic credential manages to obtain and use an authentication credential accepted by the corresponding active decoy verifier(e.g., ). Here two types of false alarms are considered: false alarms triggered by a guessed decoy authentication credential, and those caused by users accidentally entering a detection secret during new device set up. 1. Guessing attacks

[0237] Without knowledge of uncompromised masked cryptographic credentials , a guess by a false alarm attacker can hit one of the active decoy verifiers with aprobability no greater than / 2 which is negligible in terms of the credential length .For example, for 256-bit private signing keys with set to 32, the probability of the attacker guessing one decoy key that can trigger a false alarm is 32 / 2256=2-251which is negligibly small. 2. User errors

[0238] During the device setup phase, a careless user may enter an incorrect usersecret that corresponds to an active decoy verifier at a relying party given ( , )retrieved from credential backup service computer (e.g., the provider computer). However, such an event would be arguably rare. Suppose that the user replaces their user device at least every 40 months [9] and sets up credential recovery with the same frequency. The user is expected to enter their user credential only 32 times during 106.67 years, and to enters a wrong user secret even less frequency especially when some typo-reducing techniques (e.g.,

[0042] ) are adopted or even by simply asking users to enter the secret twice. Furthermore, it is argued that a false alarm caused by user errors is more identifiable to the user themselves because if the user triggers a detection at a relying party computer soon after the user sets up a new user device. It would be highly likely that the user had entered a wrong user credential during device setup for the framework according to embodiments, and they can merely ignore the breach detection alarm and re-run device setup with a corrected user secret. Certainly, a credential backup service breach attacker may leverage such an incident to avoid 79571371V.1detection, but the attacker can do so only if it happens to attack the users’ accounts at the same time, which is unlikely considering that, again, such incidents are rare events. VIII. DISCUSSION A. Achieving Survivability and Flatness for Embodiments

[0239] As shown in Table 9, achieve both survivability and flatness. The framework according to embodiments considers user rememberable secret or user biometrics as the user credential to instantiate the detection secret set .Table 9: Types of detection secrets, and criteria to consider before using them to instantiate .

[0240] User-rememberable secrets for the user credential can be in the forms of passwords, PINs, passphrases, answers to secret questions or graphical passwords, etc., Advantages of user-rememberable secrets is that they can be easily reset if users want, and they are easy to deploy via a simple user interface that takes input from users. Ensuring the flatness depends on whether such secrets are user-chosen or system generated. For the latter case, system could ensure flatness of . For example, the system can generate 1 short passwords, passphrases, pins, and question answers, and use one of these as the real secretsuch that given a detection secret set attacker can not identify the real secret effectively. However, if these rememberable secrets are user-chosen, flatness is could be non-trivial to achieve as user-chosen secrets are prone to be predictable. There are, however, existing techniques that could generate flat secrets from user-given secrets. For example, generative adversarial networks (GAN) could generate honeywords 79571371V.1distinguishable from user chosen passwords

[0034] . However, one should also consider that password breaches could foil honeyword generation approach

[0035] .

[0241] In some embodiments, the detection secret set can be instantiated using a user credential that is a user biometric. However, unlike user rememberable secrets, ensuring deployability and cancelability issues could be achieved, but are not as straightforward. For instance, in many scenarios, user devices many be heterogeneous, and ensuring compatibility of the biometric readers when users login from multiple devices may pose a problem. However, if all of the user devices of a particular user are homogenous and have the same biometric sensors (e.g., the same face sensors, fingerprint sensors, etc.), the user credential can be a biometric captured from the user. Differing sensor types is one of the main obstacles in using user biometrics to instantiate the detection secret set . For ensuring cancelability, existing cancelable biometrics can be utilized. B. False Notifications by Relying Party Computer

[0242] A malicious or error prone relying party computer may falsely notify the user of a breach that did not actually occur. While no existing decoy-based credential detection systems have taken this attack into account, here how the framework can identify this behavior with minimal modification when instantiated for existing cryptography-based authentication methods is discussed.

[0243] When a detection alarm is triggered in FIDO2-based authentication, as shown in FIG. 6, the framework according to some embodiments can additionally require a relying party computer to return to the user device the authentication response that triggers the alarm as proof of detection. After receiving the triggering response, the user device can run DecoyVerifierGen to re-generate the set of verification keys . This allows the user device to detect false breach notifications if none of the verification keys in the set of verification keys can verify the triggering response. In the case of FIDO2-based authentication, this approach can provide a strong guarantee for identifying a false notification because it fails only if the relying party computer can derive the corresponding valid signing key for a decoy verification key that verifies the triggering response, which is difficult if the underlying digital signature scheme is secure. 79571371V.1

[0244] However, detecting such a false alarm notification is more technically difficult in the case of OTP-based authentication methods, or, more broadly, authentication methods based on shared secrets between the user and the relying party. The reason for this is that authentication in this case is based on the fact that both parties can generate the same authentication response from their shared secret, making it difficult to determine whether a triggering authentication response is produced by a credential backup service breaching attacker or a misbehaving relying party itself. To defend against this threat, the user device can select a subset of the detection secret set at random, denoted by detection secret subset , while still using the detection secret set as the input of DecoyVerifierGen to generate the set of verification keys for the relying party. Meanwhile, the framework according to embodiments may require the relying party computer to send back a counter and the triggering OTP (as described in reference to FIG.6). With this setup, the probability of the misbehaving relying party computer producing a with an OTP seed that corresponds to aWhen this happens, the user device can learnthat the relying party computer intentionally sent a false alarm notification. IX. ADVANTAGES

[0245] Embodiments provide for a cryptographic framework that can detect unauthorized use of user’s cryptographic credentials leaked due to credential backup service compromise.

[0246] Embodiments can be seamlessly deployed with little to no negligible performance overhead and compatible with existing credential backup service and authentication protocols widely used today in practice. The efficacy of the framework is analyzed conservatively and find the framework according to embodiments to be effective even for attackers who attempt to avoid detection by leveraging breaches from other websites where users have accounts. The framework according to embodiments does not degrade user experiences including raising only a few false alarms, and not (re)-introducing the account recovery problem.

[0247] Embodiments provide for technical solutions to the technical problem of unauthorized use of users’ cryptographic credentials backed up by credential backup services under a strong, but practical, threat model for the first time. 79571371V.1

[0248] To address this new threat, embodiment provide for a detection framework by developing a new credential backup protocol and detection mechanism. Both can be seamlessly integrated with existing authentication protocols as demonstrated by integration tests of embodiments with two popular authentication protocols namely FIDO2 and OTP.

[0249] Embodiments provide for security guarantees, which have negligible performance overhead.

[0250] The detection effectiveness of embodiments are illustrated by providing conservative true detection analysis by modeling an optimal attacker using model checking, and provide quantitative false detection analysis while navigating different system configurations of embodiments.

[0251] Other embodiments of inventions will be discussed. In some embodiments, a method, during credential backup account setup, comprises: receiving, by a provider computer from a user device, a backup account identifier and a detection secret set, wherein the backup account identifier and the detection secret are generated by the user device; storing, by the provider computer, the backup account identifier and the detection secret set in memory.

[0252] The aforementioned method, where the user device loses access to the real secret, can further comprise: receiving, by the provider computer, a device setup request message from the user device; generating, by the provider computer, a device setup response message comprising the detection secret set and the backup account identifier; transmitting, by the provider computer, the device setup response message to the user device, wherein the user device prompts a user of the user device to input a user credential, receives the user credential from the user, regenerates a real secret based on the detection secret set and the user credential, and stores the real secret.

[0253] The aforementioned method can also include, during credential backup, receiving, by the provider computer from the user device, a credential backup message comprising the backup account identifier, a user account identifier, a relying party computer identifier, a masked cryptographic credential, and a uniformly random value; and storing, by the provider computer, the backup account identifier, the user account identifier, the relying party computer identifier, the masked cryptographic credential, and the uniformly random value. 79571371V.1

[0254] The aforementioned method can also include, during credential restoration, receiving, by the provider computer, a credential restoration request message from the user device, wherein the credential restoration request message includes the backup account identifier; identifying, by the provider computer, the user account identifier, the relying party computer identifier, the masked cryptographic credential, and the uniformly random value using the backup account identifier; generating a credential restoration response message comprising the user account identifier, the relying party computer identifier, the masked cryptographic credential, and the uniformly random value; providing, by the provider computer, the credential restoration response message to the user device, wherein the user device unmasks the masked cryptographic credential to obtain a cryptographic credential. X. REFERENCES

[0255] References: [1] [n. d.]. About the security of passkeys. support.apple.com / en-us / HT213 305l. [2] Available on: 2024-02-22. Apple, Google, and Microsoft commit to expanded support for FIDO standard to accelerate availability of passwordless sign-ins. apple.com / newsroom / 2022 / 05 / apple-google-and-microsoftcommit-to- expanded-support-for-fido-standard / . [3] Available on: 2024-02-22. Apple Plaftorm Security, iCloud Keychain security overview. support.apple.com / guide / security / icloud-keychain- securityoverview-sec1c89c6f3b / 1 / web / 1. [4] Available on: 2024-02-22. Passkeys in Dashlane. support.dashlane.com / h c / en-us / articles / 7888558064274-Passkeys-in- Dashlane [5] Available on: 2024-02-22. Start Your Passwordless Authentication Journey LastPass. lastpass.com / features / passwordless-authentication. [6] Available on: 2024-02-22. Unlock 1Password with a passkey (beta). support.1password.com / passkeys / . 79571371V.1[7] Available on: 2024-03-01. Average number devices and connections per person worldwide in 2018 and 2023. web.archive.org / web / 20240224005007 / statista.com / statistics / 1190270 / number-of-devices-and-connections- per- person-worldwide / . [8] Available on: 2024-03-01. LastPass’ latest data breach exposed some customer information. theverge.com / 2022 / 11 / 30 / 23486902 / lastpass-hackers- customer-information-breach. [9] Available on: 2024-03-01. Smartphone providers await 2H smartphone rebound. bloomberg.com / professional / blog / smartphone-providers-await- 2h- smartphone-rebound.

[0010] Available on: 2024-03-01. Two-Factor Authentication Market. mark etresearchfuture.com / reports / two-factor-authentication-market-3772.

[0011] Available on: 2024-03-01. What is a one-time password (OTP)? A detailed guide with examples. nordvpn.com / blog / one-time-password- explained / .

[0012] Available on: 2024-03-01. Who Supports Passkeys. passkeys.io / who- supports-passkeys / .

[0013] February 2013. FIDO Alliance. The FIDO (“Fast IDentity Online”) Alliance – Industry Association to Promote Authentication Standards. fidoalliance. org / fido2 / .

[0014] June 2023. Passwordless login with passkeys. developers.google.com / id entity / passkeys.

[0015] May 2023. Making authentication faster than ever: passkeys vs. passwords. security.googleblog.com / 2023 / 05 / making-authentication-faster- than- ever.html?utm_source=sproutsocial&blaid=4655725.

[0016] Akshima, D. Chang, A. Goel, S. Mishra, and S. K. Sanadhya. 2019. Generation of secure and reliable honeywords, preventing false detection. IEEE Transactions on Dependable and Secure Computing 16, 5 (2019).

[0017] FIDO Alliance. [n. d.]. FIDO Security References. fidoalliance.org / specs / common-specs / fido-security-ref-v2.1-rd-20210525.html. 79571371V.1

[0018] Arnar Birgisson. [n. d.]. Security of Passkeys in the Google Password Manager. security.googleblog.com / 2022 / 10 / SecurityofPasskeysintheGooglePassw ordManager.html.

[0019] Manuel Barbosa, Alexandra Boldyreva, Shan Chen, and Bogdan Warinschi. 2021. Provable security analysis of FIDO2. In Advances in Cryptology–CRYPTO 2021: 41st Annual International Cryptology Conference, CRYPTO 2021, Virtual Event, August 16–20, 2021, Proceedings, Part III 41. Springer, 125–156.

[0020] Kemal Bicakci and Yusuf Uzunay. 2022. Is FIDO2 Passwordless Authentication a Hype or for Real?: A Position Paper. In 202215th International Conference on Information Security and Cryptography (ISCTURKEY). IEEE, 68–73.

[0021] Nina Bindel, Cas Cremers, and Mang Zhao. 2023. FIDO2, CTAP 2.1, and WebAuthn 2: Provable security and post-quantum instantiation. In 2023 IEEE Symposium on Security and Privacy (SP). IEEE, 1471–1490.

[0022] Panagiotis Chatzigiannis, Konstantinos Chalkias, Aniket Kate, Easwar Vivek Mangipudi, Mohsen Minaei, and Mainack Mondal. 2023. SoK: Web3 Recovery Mechanisms. Cryptology ePrint Archive (2023).

[0023] Christiaan Brand. Published on: 2023-05-24. Google Authenticator now supports Google Account synchronization. security.googleblog.com / 2023 / 04 / goog le-authenticator-now-supports.html.

[0024] Emma Dauterman, Henry Corrigan-Gibbs, and David Mazières. 2020. {SafetyPin}: Encrypted backups with {Human-Memorable} secrets. In 14th USENIX Symposium on Operating Systems Design and Implementation (OSDI 20).1121–1138.

[0025] J. DeBlasio, S. Savage, G. M. Voelker, and A. C. Snoeren. 2017. Tripwire: Inferring internet site compromise. In 17th Internet Measurement Conference. 79571371V.1

[0026] Wang Ding, Cheng Haibo, Wang Ping, Yan Jeff, and Huang Xinyi.2018. A Security Analysis of Honeywords. In NDSS.

[0027] Antreas Dionysiou and Elias Athanasopoulos. 2022. Lethe: Practical data breach detection with zero persistent secret state. In 2022 IEEE 7th European Symposium on Security and Privacy (EuroS&P). IEEE, 223–235.

[0028] Jayesh Doolani, Matthew Wright, Rajesh Setty, and SM Taiabul Haque. 2021. Locimotion: Towards learning a strong authentication secret in a single session. In Proceedings of the 2021 CHI Conference on Human Factors in Computing Systems.1–13.

[0029] I. Erguler. 2016. Achieving flatness: Selecting the honeywords from existing user passwords. IEEE Transactions on Parallel and Distributed Systems 13, 2 (2016).

[0030] Florian M Farke, Lennart Lorenz, Theodor Schnitzler, Philipp Markert, and Markus Dürmuth.2020. {“You} still use the password after {all”}–Exploring {FIDO2} Security Keys in a Small Company. In Sixteenth Symposium on Usable Privacy and Security (SOUPS 2020).19–35.

[0031] Conor Gilsenan, Fuzail Shakir, Noura Alomar, and Serge Egelman. 2023. Security and Privacy Failures in Popular 2FA Apps. In 32nd USENIX Security Symposium (USENIX Security 23).

[0032] Maximilian Golla and Markus Dürmuth. 2018. On the accuracy of password strength meters. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security.1567–1582.

[0033] Jingjing Guan, Hui Li, Haisong Ye, and Ziming Zhao. 2022. A Formal Analysis of the FIDO2 Protocols. In European Symposium on Research in Computer Security. Springer, 3–21.

[0034] Briland Hitaj, Paolo Gasti, Giuseppe Ateniese, and Fernando Perez- Cruz. 2019. Passgan: A deep learning approach for password guessing. In Applied Cryptography and Network Security: 17th International Conference, ACNS 2019, Bogota, Colombia, June 5–7, 2019, Proceedings 17. Springer,79571371V.1

[0035] Zonghao Huang, Lujo Bauer, and Michael K Reiter.2023. The impact of exposed passwords on honeyword efficacy. arXiv preprint arXiv:2309.10323 (2023).

[0036] Z. Huang, L. Bauer, and M. K. Reiter. 2024. The impact of exposed passwords on honeyword efficacy. 33rd USENIX Security Symposium (USENIX Security 24) (Aug.2024).

[0037] Mazharul Islam, Marina Sanusi Bohuk, Paul Chung, Thomas Ristenpart, and Rahul Chatterjee.2023. Araña: Discovering and Characterizing Password Guessing Attacks in Practice. In 32nd USENIX Security Symposium (USENIX Security 23). USENIX Association, Anaheim, CA, 1019–1036. usenix.org / confe rence / usenixsecurity23 / presentation / islam

[0038] Ari Juels and Ronald L Rivest. 2013. Honeywords: Making password- cracking detectable. In Proceedings of the 2013 ACM SIGSAC conference on Computer & communications security.145–160.

[0039] Karim Toubba. Published on: 2022-12-22. Notice of Recent Security Incident. blog.lastpass.com / 2022 / 12 / notice-of-recent-security-incident / .

[0040] Jonathan Katz, Rafail Ostrovsky, and Moti Yung. 2009. Efficient and secure authenticated key exchange using weak passwords. Journal of the ACM (JACM) 57, 1 (2009), 1–39.

[0041] Michal Kepkowski, Maciej Machulak, Ian Wood, and Dali Kaafar.2023. Challenges with Passwordless FIDO2 in an Enterprise Setting: A Usability Study. In 2023 IEEE Secure Development Conference (SecDev). IEEE, 37–48.

[0042] Mohamed Khamis, Tobias Seitz, Leonhard Mertl, Alice Nguyen, Mario Schneller, and Zhe Li. 2019. Passquerade: Improving error correction of text passwords on mobile devices by using graphic filters for password masking. In Proceedings of the 2019 CHI Conference on Human Factors in Computing Systems.1–8.

[0043] Dhruv Kuchhal, Muhammad Saad, Adam Oest, and Frank Li. 2023. Evaluating the Security Posture of Real-World FIDO2 Deployments. In 79571371V.1Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security.2381–2395.

[0044] Leona Lassak, Annika Hildebrandt, Maximilian Golla, and Blase Ur. 2021. " It’s Stored, Hopefully, on an Encrypted Server”: Mitigating Users’ Misconceptions About {FIDO2} Biometric {WebAuthn}. In 30th USENIX Security Symposium (USENIX Security 21).91–108.

[0045] Leona Lassak, Elleen Pan, Blase Ur, and Maximilian Golla.2024. Why Aren’t We Using Passkeys? Obstacles Companies Face Deploying FIDO2 Passwordless Authentication. In Proceedings of the 33rd USENIX Security Symposium. Philadelphia, PA, August 2024.

[0046] Bo Lu, Xiaokuan Zhang, Ziman Ling, Yinqian Zhang, and Zhiqiang Lin. 2018. A measurement study of authentication rate-limiting mechanisms of modern websites. In Proceedings of the 34th annual computer security applications conference.89–100.

[0047] Sanam Ghorbani Lyastani, Michael Schilling, Michaela Neumayr, Michael Backes, and Sven Bugiel. 2020. Is FIDO2 the kingslayer of user authentication? A comparative usability study of FIDO2 passwordless authentication. In 2020 IEEE Symposium on Security and Privacy (SP). IEEE, 268–285.

[0048] Kathleen Moriarty, Burt Kaliski, and Andreas Rusch. 2017. Pkcs# 5: Password-based cryptography specification version 2.1. Technical Report.

[0049] D M’raihi, M Bellare, F Hoornaert, D Naccache, and O Ranen. 2005. RFC 4226: HOTP: An HMAC-based one-time password algorithm.

[0050] David M’Raihi, Salah Machani, Mingliang Pei, and Johan Rydell.2011. RFC 6238: TOTP: Time-Based One-Time Password Algorithm.

[0051] National Vulnerability Database. Published on: 2023-10-25. CVE-2023- 42847. nvd.nist.gov / vuln / detail / CVE-2023-42847.

[0052] Kentrell Owens, Olabode Anise, Amanda Krauss, and Blase Ur. 2021. User Perceptions of the Usability and Security of Smartphones as FIDO2 Roaming Authenticators.. In SOUPS USENIX Security Symposium.57–76. 79571371V.1

[0053] Enis Ulqinaku, Hala Assal, Abdou AbdelRahman, Sonia Chiasson, and Srdjan Capkun. 2021. Is Real-time Phishing Eliminated with FIDO? Social Engineering Downgrade Attacks against FIDO Protocols. In Proceedings of the 30th USENIX Security Symposium (USENIX Security 21). USENIX Association, 3811–3828.

[0054] Ding Wang, Xuan Shan, Qiying Dong, Yaosheng Shen, and Chunfu Jia. 2023. No single silver bullet: Measuring the accuracy of password strength meters. In 32nd USENIX Security Symposium (USENIX Security 23).947–964.

[0055] D. Wang, Y. Zou, Q. Dong, Y. Song, and X. Huang.2022. How to attack and generate honeywords. In 43rd IEEE Symposium on Security and Privacy.

[0056] Ke Coby Wang and Michael K Reiter. 2021. Using amnesia to detect credential database breaches. In 30th USENIX Security Symposium (USENIX Security 21).839–855.

[0057] K. C. Wang and M. K. Reiter.2024. Bernoulli honeywords. In 31st ISOC Network and Distributed System Security Symposium.

[0058] Leon Würsching, Florentin Putz, Steffen Haesler, and Matthias Hollick. 2023. FIDO2 the Rescue? Platform vs. Roaming Authentication on Smartphones. In Proceedings of the 2023 CHI Conference on Human Factors in Computing Systems.1–16.

[0256] Although the steps in the flowcharts and process flows described above are illustrated or described in a specific order, it is understood that embodiments of the invention may include methods that have the steps in different orders. In addition, steps may be omitted or added and may still be within embodiments of the invention.

[0257] Any of the software components or functions described in this application may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C, C++, C#, Objective-C, Swift, or scripting language such as Perl or Python using, for example, conventional or object- oriented techniques. The software code may be stored as a series of instructions or commands on a computer readable medium for storage and / or transmission, suitable media include random access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a compact 79571371V.1disk (CD) or DVD (digital versatile disk), flash memory, and the like. The computer readable medium may be any combination of such storage or transmission devices.

[0258] Such programs may also be encoded and transmitted using carrier signals adapted for transmission via wired, optical, and / or wireless networks conforming to a variety of protocols, including the Internet. As such, a computer readable medium according to an embodiment of the present invention may be created using a data signal encoded with such programs. Computer readable media encoded with the program code may be packaged with a compatible device or provided separately from other devices (e.g., via Internet download). Any such computer readable medium may reside on or within a single computer product (e.g., a hard drive, a CD, or an entire computer system), and may be present on or within different computer products within a system or network. A computer system may include a monitor, printer, or other suitable display for providing any of the results mentioned herein to a user.

[0259] The above description is illustrative and is not restrictive. Many variations of the invention will become apparent to those skilled in the art upon review of the disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.

[0260] One or more features from any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the invention.

[0261] As used herein, the use of "a," "an," or "the" is intended to mean "at least one," unless specifically indicated to the contrary. 79571371V.1

Claims

WHAT IS CLAIMED IS:

1. A method comprising: generating, by a user device, a detection secret set; obtaining, by the user device, a user credential from a user of the user device; determining, by the user device, a real secret based on the detection secret set and the user credential; storing, by the user device, the real secret; and providing, by the user device, the detection secret set and a backup account identifier for an account associated with the user to a server computer.

2. The method of claim 1, wherein during account registration with a relying party computer, the method further comprises: receiving, by the user device, a relying party computer identifier from the relying party computer; generating, by the user device, a user account identifier and a cryptographic credential; generating, by the user device, a verification key based on the cryptographic credential; generating, by the user device, a masked cryptographic credential and a uniformly random value based on the real secret and the cryptographic credential; generating, by the user device, a set of verification keys based on the detection secret set, the masked cryptographic credential, and the uniformly random value; and providing, by the user device, the set of verification keys to the relying party computer.

3. The method of claim 2 further comprising, during credential backup: generating, by the user device, a credential backup message comprising the backup account identifier, the user account identifier, the relying party computer identifier, the masked cryptographic credential, and the uniformly random value; and 79571371V.1providing, by the user device, the credential backup message to the server computer, wherein the server computer stores the credential backup message or data therein.

4. The method of claim 3 further comprising, during credential restoration: re-obtaining, by the user device, the masked cryptographic credential from the server computer; and unmasking, by the user device, the masked cryptographic credential to obtain the cryptographic credential.

5. The method of claim 4, wherein prior to re-obtaining the masked cryptographic credential from the server computer the method further comprises: authenticating, by the user device, the user of the user device with an authentication application installed on the user device; and providing, by the user device, authentication results to the server computer.

6. The method of claim 3 further comprising, during relying party computer verification: signing, by the user device, a message with the cryptographic credential corresponding to the verification key to produce a signed message; and transmitting, by the user device, the signed message and the verification key to the relying party computer.

7. The method of claim 6, wherein the relying party computer verifies that the signed message is signed with the cryptographic credential using the verification key and determines whether or not the verification key is in a subset of verification keys of the set of verification keys, wherein the subset of verification keys include decoy verification keys.

8. The method of claim 1, wherein the user credential is a password, a PIN, a passphrase, an answers to a secret questions, a graphical passwords, or a user biometric. 79571371V.

19. The method of claim 1, wherein the detection secret set comprises a plurality of decoy secrets and the real secret.

10. The method of claim 1, wherein prior to providing the detection secret set and the backup account identifier to the server computer, the method further comprises: generating, by the user device, the backup account identifier; and storing, by the user device, the backup account identifier in association with the real secret and the detection secret set.

11. The method of claim 1, wherein the user device loses access to the real secret, wherein the method further comprises: generating, by the user device, a device setup request message; providing, by the user device, the device setup request message to the server computer; receiving, by the user device, a device setup response message comprising the detection secret set and the backup account identifier from the server computer; prompting, by the user device, a user of the user device to input the user credential; receiving, by the user device, the user credential; regenerating, by the user device, the real secret based on the detection secret set and the user credential; and storing, by the user device, the real secret.

12. The method of claim 1, wherein the server computer is a credential backup service computer.

13. A user device comprising: a processor; and a computer-readable medium coupled to the processor, the computer- readable medium comprising code executable by the processor for implementing a method comprising: generating a detection secret set; obtaining a user credential from a user of the user device; 79571371V.1determining a real secret based on the detection secret set and the user credential; storing the real secret; and providing the detection secret set and a backup account identifier for an account associated with the user to a server computer.

14. The user device of claim 13 further comprising: an authentication application configured to authenticate the user of the user device.

15. The user device of claim 13, wherein the detection secret set comprises a plurality of secrets that include a plurality of decoy secrets and the real secret, wherein generating the detection secret set comprises: for number of iterations: randomly generating, by the user device, a secret; and including, by the user device, the secret in the detection secret set.

16. The user device of claim 13, wherein the method further comprises: generating, by the user device, the backup account identifier; and storing, by the user device, the backup account identifier in association with the real secret.

17. A method comprising: receiving, by a computer, a user account identifier and authentication data from a user device attempting to access an account maintained by the computer on behalf of the user device, wherein the authentication data includes data modified using a cryptographic credential that is associated with a verification key; determining, by the computer, whether or not the authentication data includes data modified using the cryptographic credential that is associated with a stored verification key in a set of verification keys or in a subset of verification keys stored in the computer, wherein the subset of verification keys include decoy keys; if the authentication data includes data modified using the cryptographic credential that is associated with a stored verification key in the subset 79571371V.1of verification keys, generating, by the computer, a cryptographic credential compromise message; and providing, by the computer, the cryptographic credential compromise message to a user associated with the account using an alternate communication channel.

18. The method of claim 17 further comprising: receiving, by the computer, a registration request message from a user device requesting to create the account with the computer; providing, by the computer, a registration response message comprising a computer identifier to the user device, wherein the user device generates the user account identifier, the cryptographic credential, the verification key, a masked cryptographic credential, and a set of verification keys; receiving, by the computer, the user account identifier, the verification key, and the set of verification keys; generating, by the computer, a subset of verification keys based on the set of verification keys; and storing, by the computer, the user account identifier, the verification key, the set of verification keys, and the subset of verification keys.

19. The method of claim 17, wherein the user device modifies the authentication data by signing the authentication data with the cryptographic credential, and wherein the authentication data is signed authentication data.

20. The method of claim 18, wherein the computer is a relying party computer and wherein the computer identifier is a relying party computer identifier. 79571371V.1

Images