
Ask HN: Thoughts on a website-embeddable, credential validating service? - estroz
Reading Troy Hunt&#x27;s password release V2 blog post [0], I came across the NIST recommendation to prevent users from creating accounts with passwords discovered in data breaches. This got me thinking: would a website admin (ex. small business owner with a custom website) benefit from a service that validates user passwords? The idea is to create a registration iframe with forms for email, password, etc., which would check hashed credentials against a database of data from breaches. Additionally, client-side validation would enforce rules recommended by the NIST&#x27;s Digital Identity Guidelines [1], which would relieve admins from implementing their own rules. I&#x27;m sure there are additional security features that can be added.<p>1. Have you seen a need for this type of service, and could you see this being adopted at all?<p>2. Do you know of a service like this? I&#x27;ve looked, no hits so far.<p>3. Does the architecture seem sound?<p>[0]: https:&#x2F;&#x2F;www.troyhunt.com&#x2F;ive-just-launched-pwned-passwords-version-2&#x2F;<p>[1]: https:&#x2F;&#x2F;www.nist.gov&#x2F;itl&#x2F;tig&#x2F;projects&#x2F;special-publication-800-63
======
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.

------
bgdkbtv
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](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.

~~~
estroz
Unsophisticated users are exactly who I would be targeting. I would likely
have to make widgets to integrate with common site building services like WP.
An iframe is likely the simplest solution if they're building a site from
scratch though.

~~~
bgdkbtv
If you’re thinking of going with the iFrame path, you’ll have to make the
whole iFrame a form. You’ll be competing directly with Gravity Forms. And they
are huge, while your only competitive advantage is a feature they can
implement in less than 5 minutes.

I’d love to see you make it work and make you money, but I’m not convinced
yet.

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

~~~
estroz
There is no reason to trust this service over Troy Hunt's API. In fact I would
use his API if I could guarantee that I wouldn't hit the rate limit too
easily, as I'd rather not come across as a spammer. I would reach out to him
if I did end up using his API. A library seems to be a good (and more secure)
alternative to a service, and is a path I will consider if I decide to start
this project.

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

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

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

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

~~~
estroz
Ideally that's what site owners should lean towards. However OAuth is a
problem for users who don't have accounts with offered providers.

------
westurner
blockchain-certificates/cert-verifier-js: [https://github.com/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](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.

~~~
jlgaddis
Exactly what part of such a service would benefit from anything related to a
blockchain?

~~~
westurner
Are you asking me why blockcerts stores certs 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?

~~~
brooklyn_ashey
I was just reading about a company trying to make self-sovereign identity
including actual certs (like degrees and such) an accessible and widely
applicable/acceptable technology using Ethereum blockchain. I thought it
showed some real practicality and promise. I believe it begins with U- forgot
the name.Perhaps UPort? Anyhow, I'd be interested in hearing from anyone here
about why that might be a bad or good idea. I don't personally have the skill
in that tech to know.

~~~
westurner
Known Traveler Digital Identity system is a "new model for airport screening
and security that uses biometrics, cryptography and distributed ledger
technologies."

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.

~~~
brooklyn_ashey
Thank you. I looked into "clear", one of the airport known traveler ID
systems. (I'm assuming there are others) It's pretty cool/concerning. Takes ~
8 min to load a traveler into its system. Thanks for reminding me of TPS---the
info on read vs write.

