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

31–40 of 329 posts

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

#31

Post by dcow »

mgarciaisaia wrote: post #20
IncRnd wrote: post #10

This is not well reasoned. Sending emails can be easily spoofed, because sending doesn't fully check the identity of the sender as being in control of the email account. There is discussion of various technologies like SPF or DKIM, but those are not universally applied. When they are applied, there isn't universal quality in their application. The crux of verification using an email account is that the person _contro…

I'd argue the crux is about proving that Me The Service can send You The User whatever info is needed (password reset, notification of planned downtimes, pricing changes, warnings about service abuse) to this address - and you'll get it. I don't care about you "controlling" an email address - you can easily get fake ones for free. It's about both parties having agreed _at least once_ on a way for the service to commu…

Ownership over the email shortname is exactly what is being proven. It’s your identity as far as the service is concerned. I can block emails from a service right after verifying so verifying does not guarantee that I will receive emails from the service at any point in the future.

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

#32

Post by weird-eye-issue »

LudwigNagasena wrote: post #21

>…and here it is in neomutt, which helpfully “renders” the HTML with lynx: >… >But that’s a solution born from practice: the fact remains that HTML email doesn’t generally degrade gracefully in clients that don’t support images or CSS. I hope that companies don’t waste their time at such edge cases that are irrelevant for 99.9% of users such as Lynx graceful degradation. It reminds me of the stories about clients tha…

Well there was a time when IE6 compatibility did matter

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

#33

Post by weird-eye-issue »

mgarciaisaia wrote: post #20
IncRnd wrote: post #10

This is not well reasoned. Sending emails can be easily spoofed, because sending doesn't fully check the identity of the sender as being in control of the email account. There is discussion of various technologies like SPF or DKIM, but those are not universally applied. When they are applied, there isn't universal quality in their application. The crux of verification using an email account is that the person _contro…

I'd argue the crux is about proving that Me The Service can send You The User whatever info is needed (password reset, notification of planned downtimes, pricing changes, warnings about service abuse) to this address - and you'll get it. I don't care about you "controlling" an email address - you can easily get fake ones for free. It's about both parties having agreed _at least once_ on a way for the service to commu…

What's a "fake" email address? If you can get emails to an email address then it isn't fake and you are in control of it, at least for the time being

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

#34

Post by irjustin »

This doesn't work for creation because it's too easy to spoof where the email came from.

In the OP's diagram this really hinges on the Mail Transfer Agent (MTA) needs the ability to verify that Mail User Agent (MUA) is legit, and that is quite hard.

Realistically MTA would need to go to a known MUA address to verify do you actually own this account?

But not all is lost!

This does work great for 2FA. Where the contents itself is is the only requirement of trust. Just make the contents unrealistic to copy/spoof and then it doesn't matter who sent it.

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

#35

Post by 9935c101ab17a66 »

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?

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

#36

Post by jcelerier »

melvinmelih wrote: post #14
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…

When I started on my first project as a junior engineer I thought I was being clever to build an app without any passwords: every time you wanted to login you received a new email with a link to log you in. Technically, this worked great but after a while I received many complaints from frustrated users who kept looking for the “signup form”…

Oh the few websites that do this drive me absolutely crazy. It makes me immediately look for alternatives, it's unbearable

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

#37

Post by m00x »

nsgi wrote: post #29
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…

The standard login/sign up form is broken, though. People will just use the same password across websites or write it down. You can't win

Use a password manager. Problem solved.

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

#38

Post by throwaway892238 »

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?

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 reset form, it has no bearing whatsoever on security.

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

#39

Post by hericium »

LudwigNagasena wrote: post #21

>…and here it is in neomutt, which helpfully “renders” the HTML with lynx: >… >But that’s a solution born from practice: the fact remains that HTML email doesn’t generally degrade gracefully in clients that don’t support images or CSS. I hope that companies don’t waste their time at such edge cases that are irrelevant for 99.9% of users such as Lynx graceful degradation. It reminds me of the stories about clients tha…

Multi-part MIME emails with both plain text and HTML content used to be a standard[1] or at least a good and common practice. Not including plain text version or making it "can't see newsletter? click here for web article" is an ongoing process of moving users from unsnoopable email to invigilated web. It's invisible to dumbed-down users, possibly saves corpos some money: devs can learn something that benefits business more and, depending on email volume, business may decrease spending a bit by removing few kilobytes of text from each message sent.

Imo a standard of sorts, being removed due to lack of knowledge or for money (savings on data transfer or profit from data gained from users reading "web version of email" and email clients loading remote content) doesn't make it an "edge case". The edge case here (necessity to parse and read HTML in pure email client) is an effect of businesses and developers not following standards in the first place.

Also, IE6 overstayed its welcome not due to edge user cases but due to corporate savings as well.

[1] https://www.rfc-editor.org/rfc/rfc2046.html#section-5.1

Post reply on HN