1. Have you seen a need for this type of service, and could you see this being adopted at all?
2. Do you know of a service like this? I've looked, no hits so far.
3. Does the architecture seem sound?
[0]: https://www.troyhunt.com/ive-just-launched-pwned-passwords-version-2/
[1]: https://www.nist.gov/itl/tig/projects/special-publication-800-63
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.
Perhaps encrypting hashed passwords with a session key and matching against hashes encrypted with that key server-side would solve the issue you mention.
It’s really easy to make as a dev using Have I Been Pwned Password API: https://twitter.com/noncototient/status/966628069048950784
Unless you’re talking about users whose dev skills only go as far as posting Wordpress articles. Then it might work, but integration would have to be super simple, I frame might not be the easiest solution for them.
I’d love to see you make it work and make you money, but I’m not convinced yet.
This allows clients to self-host the javascript (so it can't be modified to log the plain text password somewhere), and probably can plug into existing form validation with little hassle.
I guess the question is why should I trust your service more than using Troy Hunt's API directly. If you're sending hashed credentials anyways, all the verification of NIST recommendations needs to be done client side anyways.
On your comment about sending hashed creds: credentials would have to be sent to some server hosting the database, as the database would be quite large (for example, there are ~500 million password hashes in Troy Hunt's V2 release). That is the only networked component of the proposed service. Everything else would indeed be done client-side (with the current feature set).
This said, I can see a ton of potential for a plug & play solution, for example (but not limited to) a signup form for wordpress, a react input password component with a strength bar, etc.
If you create "a product that people love", I don't think it does really matter whether you verify on the client side, or securely via a remote service. You may explain pros and cons, and let the admin decide.
But I'd focus on the final solution, rather than just the service itself.
> A library to enable parsing and verifying a Blockcert. This can be used as a node package or in a browser. The browserified script is available as verifier.js.
https://github.com/blockchain-certificates/cert-issuer
> The cert-issuer project issues blockchain certificates by creating a transaction from the issuing institution to the recipient on the Bitcoin blockchain that includes the hash of the certificate itself.
... We could/should also store X.509 cert hashes in a blockchain.
Or whether using certs (really long passwords) is a better option than submitting unhashed passwords on a given datetime to a third-party in order to make sure they're not in the pwned passwords tables?
Blockcerts are for academic credentials, AFAIU.
[EDIT]
Existing blockchains have a limited TPS (transactions per second) for writes; but not for reads. Sharding and layer-2 (sidechains) do not have the same assurances. I'm sure we all remember how cryptokitties congested the txpool during the Bitcoin futures launch.