Ask HN: Thoughts on a website-embeddable, credential validating service?

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.

Why do you think this would need a service?

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.

Why not a javascript library instead of a service?

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.

My personal feeling is that signup of a new user is too critical of a function to depend upon an external service. I would very much prefer a client-side library as others have stated.

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.

Why are you calling this a "credential validating service" rather than a "password validating service"? Credentials don't have to be passwords, instead they could be tokens or signed data. Passwords are the worst credentials, and they should only be considered when nothing else would work. The form of validation you propose is not exhaustive either. "a" repeated 57 times might not be on any of the lists, but it's still a bad passphrase.

If you’re going to need a service like this to validate your passwords, it’s probably easier for you to use an oAuth provider (eg Facebook) or mangaged auth provider like auth0, firebase etc. And let them handle it.

blockchain-certificates/cert-verifier-js: https://github.com/blockchain-certificates/cert-verifier-js

> 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.