I’d say for your email that yes, you’re being overly cautious. For Troy’s recently launched https://haveibeenpwned.com/Passwords I probably wouldn’t use that myself, but he makes a reasonable case for why it’s secure.
I consider the security of the 5 char API acceptable, but it still leaks 20 bits of information about the password to HIBP, so it's certainly not 100% safe.
It depends on whether the hash is actually in the database or not. If it is, then one of the hashes returned corresponds to your password. But the hashing is done by HIBP itself, so a hypothetical evil Troy could determine the actual values of those passwords. If he determined who you are, perhaps by correlating requests with email submissions on the main HIBP site, he could then try to access your account on another site with each of those passwords, in the hope that you reused the same password on multiple sites. The docs say:
> On average, a range search returns 478 hash suffixes
which is low enough that one could potentially try them all in a reasonable amount of time, even taking rate limiting into account.
...However, the leaks that go into the database typically contain username/password pairs, not just passwords. So if your password is in the database because your account was pwned (as opposed to the account of someone who happened to pick the same password as you), and the username is reasonably identifiable, anyone who downloaded the original leak could do the same thing, except knowing exactly which password to try rather than having to go through 478 of them!
And of course, the whole point of the password lookup is to inform you that your password is compromised and you need to stop using it. If you’re diligent, evil-Troy would only have a rather limited window to attack you before you changed your password on the relevant sites following a positive result. That is, assuming the API is honest and returns all the hashes it knows… In theory it could hold some back.
A device of any kind isn't good enough (eg. at border crossings or when lost otherwise). Biometrics can be a substitute for a user name but never for a password.
I did write a Whitepaper and Demo: UX for Authenticated & Verified ERC20 Payments Using MetaMask and EthSigUtil.
This can be applied to identity and digital ownership of any property. This solution moves security to the edges; that is, the sole owner of the property holds the keys to sign away their rights to the data through digital signatures.
This removes the need for a central authority entirely.
Most sites are either high enough value that they should do the hard things, or they should outsource identification in some way. It is ridiculous that low-value sites use passwords, especially where cookies by themselves would suffice.
Sure, outsourcing is tricky, but apparently so are passwords? One failure mode it doesn't have is "a bunch of passwords got pwned and my company is at fault".
I do agree that the current schemes such as OAuth2 have odious implications. I don't think that the design space is completely explored, however. By relying solely on emailed and browser-stored tokens with judicious lifetimes, a site could outsource to email providers in a pretty secure way.
