[jimrandomh]

It sounds like this architecture (particularly the iframe bit) involves submitting the users' passwords to a third-party service to be validated. Developers and admins are likely to be hesitant about that, because the service host will end up being a significant target and a potential point of failure. This is partially avoidable; you can hash the password on the client and send the hash, and compare against the hashes of passwords from data breaches. Unfortunately, this doesn't work if you use a properly salted hash, which means that, with a reasonable amount of computational power, you'll be able to break all the password hashes submitted this way in bulk with a rainbow table. This would make your service a target, and make potential users of your service hesitate to adopt it.

A better architecture might be to distribute a library which downloads the publicly-leaked-password database so that new passwords can be checked without sending them to a third party. I can see this being a successful open source project or a side project of a large company, but I can't see site operators paying enough for that to build a business around it.

[estroz]

The library alternative was suggested in another comment and is definitely a path I'll consider over a service. The goal of this project wouldn't necessarily be to start a business, but to help standardise how websites interact with sensitive user data.

Perhaps encrypting hashed passwords with a session key and matching against hashes encrypted with that key server-side would solve the issue you mention.

[jimrandomh]

In order to do that you'd have to re-hash each of the data-dumped passwords with a new salt, each time you wanted to do a comparison. But a good password-hash algorithm is specifically designed to be slow, so re-hashing the whole database will take quite a lot of computational power, likely enough to make that strategy infeasible.