If you're ok with not allowing a lot of valid passwords, than this approach has some merit, but user beware.
You could also use this is a pre-check before querying the real haveibeenpwned api.
Yeah, bloom filters are a fantastic pseudo-caching layer.
A bloom filter will return whether something is in a set with potential false positives but never false negatives.
A cache will return whether something is in a set but with potential false negatives but never false positives (i.e. item is not currently in the cache but exists in the set).
So kind of a caching layer caching every password that has definitely not been breached.
i'd name this sort of thing a filter, rather than a cache.
Say example.com/.well-known/password-check
You provide a username or email and a password and if you get it right it will let you know and lock their account and require a reset when they log on next.
The someone like haveibeenpwned can run a meta service to check every service that registers with them.
I haven't thought through the security implications of this but it seems pretty mild on the surface. I mean there's denial of service potential but only when their password has been compromised so... good?
Also, doesn't that just hand over the user's password to the site hosting major.service//password-check? Maybe the user is security conscious already, now their strong password is sitting in plaintext on major.service's misconfigured logs.
This just doesn't seem like a good idea to me.
Edit: Or a hacker gets into linkedin, now he's literally being fed the actual username/password combinations of every single person that signs up to any website anywhere. This just gets worse the more I think about it.
If it's rate limited more aggressively than the normal login endpoint, I don't see how it could be any more dangerous.
Anyone on the internet can already query any site with a guess for your username/password - if they're right, the request will succeed. How is that different?
Either everyone would use the same unsalted hashes (bad practice) or everyone would use the same salts (bad practice). In either case, this requires widespread use known bad practices.
If you're not familiar, these are considered bad practices because they allow for the construction of rainbow tables - https://en.wikipedia.org/wiki/Rainbow_table These are bad because they allow hashes to be reversed.
> If it's rate limited more aggressively than the normal login endpoint, I don't see how it could be any more dangerous.
Given a little bit of time, rate limiting isn't actually that big of an obstacle. Especially if you don't need to compromise a given account and can use a botnet to trawl for accounts in general.
> Anyone on the internet can already query any site with a guess for your username/password - if they're right, the request will succeed. How is that different?
This imagines a central service querying N others with credentials to see if each service knows them.
Imagine compromising one service. Then people are sending you usernames and passwords for hundreds of other services. You won't need to query any other service, the credentials will come to you and the user will have no indication!
However, there might be some complexities. This is basically poor-password-handling as a well-intentioned service. It means anyone breaching any of the services the hub knows about would let you see a great many username/password pairings being checked. It would take make passwords as safe as the weakest link across all the services being checked. The odds of N services all being absolutely safe all at once aren't as good as those of a single service. This is why people shouldn't re-use passwords, right?
I can see your heart is in the right place. You're looking to protect users from themselves! That's a wonderful thing, and I'm so glad that there are people like you who care. But the above outcome might not be maximally desirable, you know?
See my other comment: https://news.ycombinator.com/item?id=17323068