I have seen similar comments here before that suggest all email addresses are "public information". I am not sure I understand or agree with this perspective.
What if the address was only used to receive mail, not to send it?
If you can receive email to an address, then the sender knows your address. Either you had a"blonde moment" or else I'm misunderstanding what you mean wrt sending vs receiving.
The parent comment referred to "every" recipient knowing ones email address and "anyone who has hacked those recipients". The idea seems to be that all email addresses become "public". But this seems to assume things about the user and how they use the email address.
What if a user has an email address that she does not use to send mail? She does not use this account to send mail. She does not need to send reply mail. She has other email accounts she can use if she needs to send mail. If she only shares this address with one sender, then is this not at least a "semi-private" email address?
Back in the early 1990s when email accounts started to become easy to obtain, I routinely had accounts where I only received mail. I only gave these addresses to one or a few senders. I did not use these accounts to send mail.
I do not use email as avidly as I did back then, and maybe things have changed, but I would be a little surprised if today when a user sets up a new email account she starts immediately getting email1 because "all email addresses are public", before she has given this address to anyone. The address is "semi-private" unless and until the user decides to disclose it widely. She may choose not to do that.
1 Except maybe a welcome email from an email provider.
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.
Yeah. It's an email address, not a credit card number. Don't give the site your password(s) of course, but email address I wouldn't consider something that needs keeping safe and hidden
Am I being overly cautious?