Guy calls current flow clumsy. Comes up with alternative reliant on mailto :)
One man’s hack is another man’s bodge!
Why don’t we do email verification in reverse?
251–260 of 329 posts
Re: Why don’t we do email verification in reverse?
#252The flow diagrams leave out the "treat the account as verified and start sending messages anyway" that lots of companies do.
Then you ask them to remove your email address from some other persons account and instead they delete the account. Fun times.
Re: Why don’t we do email verification in reverse?
#253I A/B tested this exact flow at my last employer, and it lost. I didn’t follow up with user interviews or surveys, but my guess is people were creeped out by their email client opening out of nowhere.
This is something I hadn’t considered! I could definitely see that spooking less technical users.
Re: Why don’t we do email verification in reverse?
#254The scheme supposes mailto: scheme works (by web browser starting MUA after click to mailto: scheme link). I cannot imagine that is true for majority of people. Perhaps it worked in the past where people used real MUA application, and such MUA is configured as default handled for mailto: in their OS, but today when people mostly use web-based MUA and browser/OS has no idea about it, i would expect it mostly does not work.
Re: Why don’t we do email verification in reverse?
#255I've had family members fall prey to phishing scams. I would be concerned if legitimate sites trained their users to send odd content to odd addresses as part of normal net usage. How can an ordinary person understand the difference between sending a token to real.com and sending a threat to another user on behalf of fake.com?
Quoted post unavailable.
I wasn’t aware that my random blog post thoughts were that influential!
Re: Why don’t we do email verification in reverse?
#256Re: Why don’t we do email verification in reverse?
#257I run a product using email verification that's currently failing in all the ways on the list
I chose it because it's less complex than oauth, and (slightly, in theory) more convenient than user-password.
My wishlist version of oauth is for a slightly different protocol that 1) doesn't require the product to create an account with the id provider, 2) doesn't allow the id provider to block sites, 3) doesn't let the id provider see where the user is logging in
Re: Why don’t we do email verification in reverse?
#258The scheme supposes mailto: scheme works (by web browser starting MUA after click to mailto: scheme link). I cannot imagine that is true for majority of people. Perhaps it worked in the past where people used real MUA application, and such MUA is configured as default handled for mailto: in their OS, but today when people mostly use web-based MUA and browser/OS has no idea about it, i would expect it mostly does not…
It does work. Gmail has been popular enough for long enough that everyone makes sure this works.
Re: Why don’t we do email verification in reverse?
#259Earlier quoted context omitted.
> Thats a crazy level of risk assessment for an average user. It really isn't. Think about it for a second: how hard is it to spot phishing attempts when they are sent to an email address you know for a fact you're not using with a service? And how vulnerable are you to phishing if your special-purpose email address that you only use for one specific purpose receives zero spam? To claim that the most basic and easy i…
Do you think youre going to get scammed and send a fraudulent Western Union transfer? What do you think the venn diagram overlap between "uses a specific email for each service" and "gets phished" is? The people that even have the capacity to do the first aren't going to fall into the second. If someone is sending fraudelent transfers to scammers, they're not going to be smart enough to create multiple emails.
> Do you think youre going to get scammed and send a fraudulent Western Union transfer?
I know for a fact that there are targeted phishing campaigns aimed at users of specific services such as LinkedIn and GitHub and Twitter and etc, primarily because I've been targeted by them.
> What do you think the venn diagram overlap between "uses a specific email for each service" and "gets phished" is?
I know for a fact that the Venn diagram of phishing attempts sent to email accounts that are not used by those services is practically zero.
Do you understand how trivial it is to identify and filter out these attacks when they are sent to addresses that are already known beforehand that are not used for that purpose?
Re: Why don’t we do email verification in reverse?
#260Earlier quoted context omitted.
The article has a section on security where they address the problem you describe and several others. Do you find their reasoning unsound?
Yes. 1) DKIM, SPF and DMARC do not prevent spoofing, they simply make it less easy. A compromise of those methods, or an attack on DNS or BGP, or any other novel spoofing attack, gives the attacker a successful attack vector that would not exist if the website simply sent the user an email to verify. 2) The unique token and timeout is simply given to the attacker when the attacker initiates the new account/password r…
The same attacks can likely also be used to capture verification emails. E.g. for DNS if you can spoof TXT records for Gmail using some malicious server, chances are you can also spoof MX records. And I can't think of shenanigans with BGP that allow you sending spoofed emails that pass DKIM, SPF and DMARC (ultimately routing traffic to your malicious server again), but not allow capturing of mails.
I think the suggested flow is a valid idea to discuss, even though at the end of the day it's still a bad idea (others have formulated a lot of valid criticism that I agree with). But I find your criticism to be unfair, as it also applies to the traditional flow and should rather be a reason not to use email at all (begging the question: What secure alternative should be used?).