Thread by @LeaKissner

Next up at #usesec19: "Protecting accounts from credential stuffing with password breach alerting", Kurt Thomas speaking

Want to test this technology live? Download the Google password check extension from the Chrome store

Billions of credentials have become widely available. This makes trivial for attackers to access user accounts.

How do you protect the long-tail of sites across the web? Attackers have access to billions of usernames of passwords. User don't have resources to address this.

Bridging the knowledge gap, like "have I been pwned" site.
* But may not be accurate because only uses username.
* Privacy risk, even if sharing only SHA-1 hash of password -- what if the site is an attacker?

This work aims to fix that.

A note on ethics: they're only looking at this to re-secure user accounts. But any protocol they build to help users has to protect privacy as a ground principle.

Design principles:
1. Accessible to all users, sites
2. Actionable, not informational -- only tell passwords breached to tell you to reset
3. Breached not weak -- tell you only when your username/password is exposed
4. Near real-time -- fast enough to integrate with login flow

Read the paper for full construction, but basically: user queries the server, gets back "breached y/n"

What if the client is adversarial? What if the server is?

Adversarial client: use proof-of-work to slow down the client. Argon2 has the advantage that breach of server state doesn't make it easier.

Adversarial server: basically it's like Diffie-Helman... see the paper for details on how they do a secret lookup without showing what they're looking up

But that would mean you'd need to return billions of records! That's too much.

If you are willing to leak 2 bytes of username prefix, you can get k-anonymity ~60k and only need to download 1-2MB.

Static serving of hashed, encrypted database. Client handles majority of work. That scales nicely for the server.

chrome extension monitors login forms, hits cloud service to get the appropriate data as described

They have a CCS paper from a few years ago on how they get the data breach information they use to back the service.

When you log in with a breached account, a warning pops up. You can tell the warning to go away.

Telemetry:
on login: domain, timestamp, breach status, hashing perf
on ignore: domain, timestamp
on password change: timestamp [missed the rest of list, but I assume domain, breach status]

This helps understand whether they're nudging appropriately and helpfully

20 QPS at peak usage

8.5 seconds to get an answer (1/2 in proof of work)

21 million logins scanned first month:
~1/2 of users saw a warning
>1.5% logins on the web are breached

Where is this threat most prominent?
Government: .2%
Finance: .3%
Email: .5%

Shopping 1.2%
News 1.9%
Entertainment ~6%

... over a lot of people that's a lot of insecurity

User response to warnings: 26% of people warned changed password
* we can't know where to send people to change their password
* not everyone can change password

... so that's good and want to keep working

94% of password as strong or stronger than original

You can help!
* share breaches to increase coverage
* improve protocol for low-end devices
* improve UX for account recovery

Q: what if I use a password manager like 1password. Could they do something like this? Which service is better?

A: the API is open -- they could integrate this service!

Q: because you implemented with a browser extension, can the site learn something? like whether the user was compromised?

A: we thought this was OK because the site already has username/password, so the risk of adding more detail is quite small

Q: why breach not leak?

A: because user attention is precious and credential-stuffing is such a big problem that we wanted to start there

Q: did you do any UX research? what were the results? how did they vary across different populations?

A: we didn't have that expertise, but we modeled after everything SafeBrowsing has learned

Q: if you're collecting telemetry, why do this on the client at all?

A: because we don't want to send the username/password up to the server -- if we do it on the server we need username/password