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

231–240 of 329 posts

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

#231

Post by remram »

OJFord wrote: post #112
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?

I use email aliases that I can't send email from. It's also possible that email from your domain is blocked by mine, and I would never receive that invoice or password reset link. In reverse, there are addresses on my company's domain I can send from but not receive at, and I shouldn't be allowed to sign up with those.

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

#233

Post by remram »

nickjj wrote: post #224
scrollaway wrote: post #215

Earlier quoted context omitted.

With magic links it happens every single login. Confirmation email only needs to be done once per email. I thought this was obvious? And most websites don’t require confirmation email to log in, they require it to unlock certain features.

> With magic links it happens every single login. Confirmation email only needs to be done once per email. I thought this was obvious? You don't have to do it on every single login. Check my previous reply's comment: > I really don't understand why so many folks hate magic links. They solve a number of problems in a pretty reasonable way at the cost of having to wait 5 seconds for 1 email to verify your email at whic…

"Logging in" typically refers to the situation where you don't have the cookie and need to get it. Having the cookie is typically referred to as "being logged in" already.

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

#234

Post by Ayesh »

The massive inconveniences others have pointed aside, it will be a technical nightmare to implement too. Incoming email takes a _lot_ of moving parts to process. What could have been a simple http get/post/redirect forms now need a process to accept and parse incoming emails, and someone inform the page about verification status. There are plenty of existing libraries and software to do it, but it's really difficult to get right.

Incoming emails in qprint, plain and html emails with boundaries, spoofed emails, separating verification emails from regular emails, etc there are so many complexities involved. In addition, it is difficult to write unit tests for them, and integration tests wouldn't be solid either.

All of these technical complexities to beat a paradigm that billions of users are used to, with no obvious improvement.

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

#235

Post by remram »

9935c101ab17a66 wrote: post #35
throwaway892238 wrote: post #19

1. Attacker goes to website, initiates signup up for an account 2. Website generates mail link for attacker to send 3. Attacker uses mail link to spoof email 4. Account is opened for the attacker using email address This spoof attack works for both account creation and password reset (account takeover). This attack is impossible if the website sends a verification email to the user's inbox which only the person who c…

The article has a section on security where they address the problem you describe and several others. Do you find their reasoning unsound?

Having to tell an ordinary user that their domain didn't configure DKIM properly so sign up didn't work and they now have to go through an alternate flow sounds like a nightmare. The article does not mention what to do with the many users who don't already have the mentioned security mechanisms, just that they are "commonly deployed".

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

#236

Post by remram »

_8j50 wrote: post #209

Guys,it's 2022! You shouldn't be requires to give out your email right along for verifying anything. Please allow the old dog to die. Site generated communication should be entirely optional, and even then why not support signal,whatsapp, slack,discord,etc... (as a library of course). Fight spam? Use captchas. What I found out is email registration is very difficult without a phone number which in turn requires a gov…

People forget their passwords. If you do more than sell stuff one time and the user really need to get their account back, you need a way to send them a reset link or code. No way around it.

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

#237

Post by remram »

longrod wrote: post #169

I think this is a good idea ONLY as a fallback. Email deliverability is a very real problem even if it happens to only 1% out of 99% of your users. What happens when a customer emails saying they can't verify their account because they didn't receive any email? It'd be quite seamless to offer this as a secondary option.

When you get an email without DKIM or SPF, how do you explain to them that they need to change to a supported email provider even though yes you did receive the requested sign-up email?

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

#238

Post by fomine3 »

grose wrote: post #91

Before smartphones in Japan, this is how mobile websites did signups. Every phone had an email address and you verified it by sending a blank email via a mailto link. Restaurants and Karaoke places had QR codes on their menus for this. Seems like this practice died out when messaging apps (LINE) displaced mobile email. I thought it was kind of cool but managing spam filters was a pain.

Why this methods was popular is because it's hard for user to input their own (and correct!) email address. Mailto link is far easier way to tell the valid email address to a service. Perhaps now is OAuth/OIDC era.

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

#240

Post by remram »

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'…

My domain's SPF says "email from sendgrid is allowed", which allows anyone with a sendgrid account to spoof me.

I didn't set up DKIM because I don't particularly care about the security of that particular domain. But the point is that you can't know how secure the domain is just because it has some security feature present like SPF.

Post reply on HN