Am I being overly cautious?
Am I being overly cautious?
Don't expect it to be even semi-secret.
What if the address was only used to receive mail, not to send it?
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.
Even if you don't trust that form to behave as promised, you can do the query yourself.
https://haveibeenpwned.com/API/v2#SearchingPwnedPasswordsByR...
> 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 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.
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.
https://steemit.com/ethereum/@emmonspired/whitepaper-and-dem...