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

101–110 of 329 posts

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

#101

Post by rocqua »

netheril96 wrote: post #83
melvinmelih wrote: post #14

Earlier quoted context omitted.

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

Email is not a secure method of communication.

Email os how all password recovery flows work. So your accounts are generally as secure as your Email.

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

#102

Post by chunkyguy »

perlgeek wrote: post #92
chunkyguy wrote: post #86

I like the idea but instead of mailto which I find annoying why not simply ask the user to send us an email with a hello message? The email address we provide can be unique per sign up if required. So no copy pasting of codes, or having a specific format of the email. We just need to check the sender and recipient.

Without a code, there is a pretty high risk of an attacker social engineering an account holder into sending an email. I haven't really thought this through (what an attacker would gain), just want to point out the general risk.

But the code is already part of generated email, the one that the user needs to send hello to.

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

#103

Post by woodruffw »

cwilkes wrote: post #87
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…

Yeah I don’t get it. Is this the reasoning? Email is slow to get to me I use neomutt (there are dozens of us, dozens!) and so links sometimes are wonky. So let’s use SPF and DMARC, something totally outside of a regular email user’s control, to do this task. And hope that it works.

> I use neomutt (there are dozens of us, dozens!) and so links sometimes are wonky.

I used neomutt for that one example, but the other error modes happen to me regularly on macOS with the system mail client. For example, I regularly (~1/week) run into services that expect the verification email to be opened in the same browsing session, but Chrome "helpfully" picks a different profile.

(The point about neomutt was not that services should support my particular pathological case, but that graceful degradation is important everywhere. It used to be common to send multipart emails for exactly this case, but I've seen more and more services choose not to.)

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

#104

Post by ozim »

gingerlime wrote: post #30

Besides the security and usability problems others mentioned, I also highly doubt it will improve confirmation conversions. One thing that helped us improve confirmations -- we A/B tested it and confirmation rates increased ~8%: send a 4-digit confirmation code rather than just a link. It's easier and more familiar on mobile, especially if you see the code on the push notification, so don't even need to open the emai…

Not having a link in email is important. I believe most of the times email from my systems go to spam because there is a link in it.

I don't have any hard data but I can imagine that if email contains link it will be checked by more rules in heuristic checks. If there are no links - most likely it is not spam.

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

#105

Post by perlgeek »

chunkyguy wrote: post #102
perlgeek wrote: post #92

Earlier quoted context omitted.

Without a code, there is a pretty high risk of an attacker social engineering an account holder into sending an email. I haven't really thought this through (what an attacker would gain), just want to point out the general risk.

But the code is already part of generated email, the one that the user needs to send hello to.

Ah, I think I misunderstood your proposal.

Do you want to put the code into the recipient email address?

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

#106

Post by woodruffw »

r_hoods_ghost wrote: post #25
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…

Yep. I read this and thought PEBKAC. Optimise for the base case, be inclusive of those using screen readers, ignore the masochists who insist on making life difficult for themselves by refusing to use technologies that have been around for decades. The author's other issue - multiple browser sessions open and logged in to different accounts and tabs opening in the last active one - this is a more common annoyance. Bu…

I'll say as the PEBKAC'd author: I try to remember to focus the right browser session! But I still load the wrong one about once a week, and whether it works with a particular site is a crapshoot.

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

#107

Post by speedgoose »

eastbound wrote: post #95
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.

Password managers are a single point of huge vulnerability. Unless password managers have a bug bounty of 3m$, then it’s less than the assets I’m protecting with it. Also, Chrome itself is a password manager.

It’s still better than using the same few passwords everywhere or having a system with the site name. Because you need only on website vulnerability, which is quite common, to compromise your passwords. It’s better to have a single unlikely point of failure than many guaranteed points of failure in my opinion.

Chrome has a password manager but the key is stored for you, which is less secure because it’s not using a HSM (hardware security module) as far as I know.

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

#108

Post by ghayes »

ozim wrote: post #94
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…

Super typical developer thinking :) two pieces of code look the same but are not doing the same things. I usually see it when people implement add/edit for some entity, that should be separate forms but are crammed into one to be "DRY".

PUT versus POST

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

#109

Post by OJFord »

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 sounds like the mailto link is going to somehow include SPF & DKIM configuration to solve that? I don't get that bit.

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

#110

Post by mdmglr »

> 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.

Also what about users with multiple email accounts setup on the email client. Those users will need to remember to select the desired from email.

[1] https://www.campaignmonitor.com/resources/guides/most-popula...

Post reply on HN