Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why don’t we do email verification in reverse?

blog.yossarian.net

Post reply on HN
Print view View original

111–120 of 329 posts

Re: Why don’t we do email verification in reverse?

#111

Post by zimpenfish »

weird-eye-issue wrote: post #80
bombcar wrote: post #74

Earlier quoted context omitted.

I hate the email login link stuff, and any site that has it as the only option, I move on unless absolutely forced to use it. Especially a pain if I'm trying to login on a device without my email.

You don't need to have email on the device you are logging in from Can take out phone and click link

> Can take out phone and click link

That assumes you have that email account on your phone. Also that you have your phone with you, that your phone has signal / wifi, there's no delays, no greylisting, no spam filtering that might catch the email, ...

There's just too many simple ways it can break down for it to be a good system.

Re: Why don’t we do email verification in reverse?

#112

Post by OJFord »

peterkelly wrote: post #46

The whole point of email verification is to verify that the user is able to receive email at the given address. Aside from the other issues mentioned here, the proposed solution does not achieve this.

I can't think of anything I've signed up for that would care about the distinction personally, any examples?

Re: Why don’t we do email verification in reverse?

#113

Post by x62Bh7948f »

a common account registration pattern in Japan involves presenting a QR code containing a mailto link. The user scans it, sends an empty mail (the details for the subject are already in the mailto link) and a reply comes up with a temporary user. The user can then define a username or password. Sometimes this pattern creates the username and password randomly.

Re: Why don’t we do email verification in reverse?

#114

Post by samus »

simonw wrote: post #5

A general rule of thumb I've built up over the years: resist the temptation to innovate around login! Look at the most commonly used flows that are not obviously terrible and try to implement as close a match to them as possible. When I've tried to innovate around login in the past I've found that any clever ideas I come up with inevitably run into road blocks pretty quickly. Here's one example: why have a separate l…

Indeed; as soon as the article stated that SPF and DMARC are required, it stopped sounding like a good idea.

Re: Why don’t we do email verification in reverse?

#115

Post by shakna »

pvorb wrote: post #84
pmontra wrote: post #76

Earlier quoted context omitted.

I do and tell people to do the same. Unfortunately we can't force people to actually do it.

Unpopular take: users should be free to use bad and insecure passwords for services they don't care about.

That turns all users into a greater threat in the case of any bugs in the server. Makes it easier for the service to get DOS'd by authenticated users, and so on. Allowing on user to be more insecure, makes all users more insecure.

Re: Why don’t we do email verification in reverse?

#117

Post by woodruffw »

mdmglr wrote: post #110

> Plaintext alternatives are the solution, but support is spotty. Very few people use plaintext email clients. According to campaign monitor [1] 67% of users are using graphical email clients. > Takeaway: Inbox delivery can be fickle, unreliable, or outright impossible. The proposed solution to use `mailto:` is also fickle. Users may not have their email client setup or the right client configured in the browser. Als…

There are probably two sampling errors here: users with accessibility requirements (such as screen readers) might not represented in the survey, and "graphical email clients" run a wide range of functionality (including very, very broken HTML and CSS rendering).

Even if 2/3rds of users run a graphical email client, that's still 1 out of every 3 who don't. That's a lot!

I agree about `mailto:` and multiple accounts having poor UX, however. It'd be nice if there was some way to specify the "intended" outgoing email identity via `mailto:`, but I don't know if that's possible.

Re: Why don’t we do email verification in reverse?

#118

Post by prionic6 »

So having built a few services that offer a signup, it's typically simple to make the service _send_ emails and receive the token through the browser for validation. It's all synchronous with actions that the user initiates. To build something like this you'd need an email inbox, which services typically don't have.

Re: Why don’t we do email verification in reverse?

#119

Post by woodruffw »

OJFord wrote: post #109

It's a nice idea, and I don't think it needs DKIM either, just SPF? (If the token in the body was maliciously changed to the correct value.. they're too short? All that matters is whether it's correct or not?) But I suppose there'd be many legitimate SPF fails - I see them on email from companies all the time, like they followed half the instructions to bring their own domain to MS/Gmail, and stopped when it 'worked'…

OP here. I think you're right that SPF is all that's strictly required; DKIM is technically just "nice to have," since all we need is envelope authenticity + the shared secret.

You're also right about SPF (and DKIM) fails, which is why this really isn't all that practical -- it's too easy to misconfigure both and both "fail open," meaning that any service that actually does email verification this way would either need to accept the risk of spoofing from non-major email providers or perform strict SPF/DKIM enforcement (e.g. rejecting email from domains with open IP ranges, even if the domain says it's okay). And that's very hard to do in the general case.

Re: Why don’t we do email verification in reverse?

#120

Post by infensus »

radu_floricica wrote: post #82

I... don't particularly get it. He mentions spoofing, he writes a page about how spoofing works... but says a lot less about how it actually impacts his solution or how to fix it. Besides the fact that implementing a new security scheme means you have to think through every possible path and can be sure you're still missing a few, there are two major issues: - not everybody has SPF or DKIM, and definitely not everybo…

When opening for the first time, Gmail asks to be registered as the mailto handler, but I guess people just hit "no" not knowing what's that about.

And there's probably a lot of web-based clients that didn't care to implement this, so yeah, if you want to use mailto links, you better have a big and patient customer support team at hand

Post reply on HN