How to End Password Reuse on the Web

Abstract

We present a framework by which websites can coordinate to make it difficult for users to set similar passwords at these websites, in an effort to break the culture of password reuse on the web today. Though the design of such a framework is fraught with risks to users' security and privacy, we show that these risks can be effectively mitigated through careful scoping of the goals for such a framework and through principled design. At the core of our framework is a private set-membershiptest protocol that enables one website to determine, upon a user setting a password for use at it, whether that user has already set a similar password at another website, but with neither side disclosing to the other the password(s) it employs in the protocol. Our framework then layers over this protocol a collection of techniques to mitigate the leakage necessitated by such a test. These mechanisms are consistent with common user experience today, and so our framework should be unobtrusive to users who do not reuse similar passwords across websites (e.g., due to having adopted a password manager). Through a working implementation of our framework and optimization of its parameters based on insights of how passwords tend to be reused, we show that our design can meet the scalability challenges facing such a service.

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

“…To prevent users from reusing their password across web services, Wang and Reiter [45,46] propose two protocols for a group of web services to check if a user is using the same password in multiple of the participating web services. The efficacy of this protocol relies on the coordination of many web services, making it harder to deploy.…”

“…We measure and compare the latency and bandwidth requirements for running different compromised credential checking services: MIGP (ours), GPC [41], IDB [31], WR19-Bloom [45] and WR20-Cuckoo [46]. Although WR19-Bloom [45] and WR20-Cuckoo [46] were designed to check user's passwords in multiple web services, these protocols can be easily used for checking user's leaked passwords, as well. WR19-Bloom and WR20-Cuckoo protocols rely on partial homomorphic encryption technique to build private membership test (PMT) protocols.…”

“…The server and the client are executed in two different EC2 11. Average latency (in milliseconds) for checking one password via GPC [41], IDB [31], WR19-Bloom [45], WR20-Cuckoo [46] and MIGP (ours) with different parameters. WR19-Bloom and MIGP-Bloom use Bloom filter to reduce the b/w requirement.…”

How to End Password Reuse on the Web

“…III; account location privacy will be discussed in Sec. V. Proofs for all propositions in this section can be found in our technical report [72].…”

Experiments and Proofs in Web-service Security

“…After this defect was corrected, by removing the display of the valid ticket in the error report web page, another experiment was carried out. In some cases the algorithm used to generate tickets is known by attackers because the source code for the server may be available or the attackers may be able to guess the ticket algorithm [17]. In the revised Netml system, tickets were calculated as: hexsha(username+Calendar.getInstance() .get(Calendar.DAY_OF_YEAR)) In the present case this algorithm was deliberately revealed to the attacker.…”