The new password check function in Google Chrome aims to help keep your accounts safe by notifying you at login to a site if the username+password combo entered has been compromised. I have to admit that I was initially skeptical of this feature as the first steps taken by the privacy-conscious when securing a browser are 1. Don’t use Chrome 2. Disable any and all “call-home” functions. However, that was before I read this article and the accompanying paper, which you can find here: https://security.googleblog.com/2019/12/better-password-protections-in-chrome.html
Given that data breaches are becoming a daily occurrence a service like this is
not a bad great idea. Several password managers and identity protection services currently offer a similar check, but most are limited to alerting if your email address or username is floating out there in the darkweb or some pastebin dump, but not confirmation that the specific username+password for a site was leaked. For example, the Firefox Lockwise function leverages the Have I Been Pwned (https://haveibeenpwned.com/) database to alert you to the possibility of a breach based on the relative dates of when you saved the password and when the breach occurred.
The paper outlines how the username+password data is encrypted using a private key known only by the browser, hashed, and along with some other material sent as a request to the service for validation. I assume this feature will also be implemented in the core Chromium repo so that others can take a look at the code to ensure the implementation doesn’t leak data locally or is otherwise susceptible to being grabbed from memory.
To check for matches, a method dubbed “private set intersection with blinding” (https://storage.googleapis.com/pub-tools-public-publication-data/pdf/33bc2203e7bcb5c0abe289f7432e11563fb2a238.pdf) is used to partition and reduce the search space to compare the request to the massive database of known breached data gathered from across the ether. If I understand the method correctly, it’s essentially testing for a hash collision or element that exists in the intersection of the sets of data from the client and the result from the server. Computing this intersection reminds of a research paper I was a small part of in college titled “On The intersection of N-th degree Polynomial Curves”, so now I’m wondering what other applications there are for this type of search.
The paper further outlines how the protocol is resistant to adversarial uses (e.g. using the service to build or validate a password dictionary or farm email addresses) through the use of k-anonymity (think clustering, but in reverse) computationally-expensive hashing and elliptical curve crypto. It will be interesting to see how this develops over the next few years.