Protocols for Checking Compromised Credentials

Abstract

To prevent credential stuffing attacks, industry best practice now proactively checks if user credentials are present in known data breaches. Recently, some web services, such as HaveIBeenPwned (HIBP) and Google Password Checkup (GPC), have started providing APIs to check for breached passwords. We refer to such services as compromised credential checking (C3) services. We give the first formal description of C3 services, detailing different settings and operational requirements, and we give relevant threat models.One key security requirement is the secrecy of a user's passwords that are being checked. Current widely deployed C3 services have the user share a small prefix of a hash computed over the user's password. We provide a framework for empirically analyzing the leakage of such protocols, showing that in some contexts knowing the hash prefixes leads to a 12x increase in the efficacy of remote guessing attacks. We propose two new protocols that provide stronger protection for users' passwords, implement them, and show experimentally that they remain practical to deploy.

Cross Hashing: Anonymizing encounters in Decentralised Contact Tracing Protocols

“…There is a trade-off to this approach; to ensure both communication overhead remains low and prevent re-identification attacks, the user must disclose the first few bits of two hashed Rolling Proximity Identifiers. The risk associated to such a protocol is well documented in [12] and formal analysis of the properties of anonymised hashes can be found in [15]. Such protocols have been used widely in compromised credential checking systems, a privacy sensitive context.…”

“…Our prior work in [12] provides an empirical comparison of compromised credential checking (C3) protocols and defines novel protocols for minimising information loss. Whilst pure Private Set Intersection has a heavy computational and communication overhead, [13] has combined k-Anonymous protocols with Private Set Intersection to reduce this burden.…”

“…We seek to allow a user to query CCIs whilst minimising the privacy loss both on the server and for the client. Fortunately, this is a well explored problem in [10], [12], [13].…”

“…The client simply needs to truncate the CCI hash to a desired number of bits such to grant anonymity (we provide both formal definitions and empirical analysis for applying k-Anonymity to hash based data sets in [15]). As such buckets are queried on the basis of CCI hashes instead of the RPIs or Temporary Exposure Keys, no additional information is leaked (for more information on data leakage risks see the section on "Identifier-Based Bucketization" in [12]).…”

Might I Get Pwned: A Second Generation Compromised Credential Checking Service

“…Here an adversary uses exposed passwords to try to log into user accounts on various web services, which succeeds frequently because of password reuse [22,36]. In response, practitioners have set up third-party services such as Have I Been Pwned (HIBP) [3,31] and Google Password Checkup (GPC) [38,41] that provide public APIs to check if a user's password has been exposed in known breaches. These breach-alerting services, also called compromised credential checking (C3) services, can help prevent credential stuffing attacks by alerting users to change their passwords.…”