Why don’t we do email verification in reverse?
blog.yossarian.net
blog.yossarian.net
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 login form from a signup form? They both involve asking the user for an email and password, why not have one form that can do either depending on if the user's account already exists?
I quickly learned why: if you don't understand the user's intent when they submitted that form, you can't show them error messages that match their mental model as to what is going on. This makes for an incredibly confusing experience the moment you step off the happy path.
----
That's not to say it's not interesting and valuable to think through new login mechanisms. They're very interesting design challenges! But its good to be prepared to find out that vanishingly few innovative ideas will work out as genuine improvements.
Just give the user two links: sign up and log in. Both ask for email address first. The next screen tells them to check their email.
You can use unusual flows without confusing users as long as you give them cues about how to do what they're trying to do.
Need to check something attached to a work email (hello Slack) but purposefully not got work email set up on your personal device? Good luck
... and it just doesn't work.
Ha. Good luck with that. Your email provider probably only supports Chrome.
This isn't worse or different than SSO, which your work should be enforcing anyway.
Especially a pain if I'm trying to login on a device without my email.
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.
We're used to one way of working and have our setups for that. We don't want something different but not because it's worse. It's just different.
And even more, when you have a problem with your password, what do you have to do, yes, email for the most part.
Plus I don't know who's using that to help adtech build their cross device mappings
We did, tried something "original" in the login part, by offering a "one time login link" to our users instead of the standard flow. To be honest, we believe this was a bad idea.
The flow in itself is good and works fine (supposing email delivery works), but as @simonw perfectly said it, "resist the temptation to innovate around login!".
Offering that original "one time login link" is a frequent cause of support request because some users doesn't receive it, doesn't know what to do or how. They are not used to a change on login and this causes more troubles down the road than a standard flow.
That's why we later on decided to add the standard "password" login and tried to reverse that original flow. We still have users that have accounts with no password set though (still connecting via the original "one time login link").
But I deliberately keep email off my phone, so I don't look at email on my phone.
So yes, I hate 'passwordless login'. I have a password manager, I can do it myself thanks very much.
If you are not using dedicated special-purpose email addresses with specific services, you're already grossly mismanaging your online safety.
Think about it for a second: how does your password manager help you if your email password gets leaked?
> how does your password manager help you if your email password gets leaked?
You still need my TOTP codes in my case at least, which conveniently are stored in my password manager. Is it perfectly secure? No, of course it's not, but frankly my risk profile isn't worrying about a targeted attack on me and my password manager, it's worrying about leaked shared credentials.
Side note, I also get a push notification on my phone whenever a new device logs on, so unless the attack is _extremely_ targeted, well timed and they know what they want, Its not a risk for me.
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 internet security precautions are at a "crazy level", first you need to somehow believe that no one is targeted by these schemes. But somehow there's a whole international industry that thrives on stuff like Western Union transfers. Why is that?
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?
Basic and easy internet precautions are not "register and run a domain and host your mail yourself". Basic and easy precautions are don't reuse passwords/use a password manager, use a reputable email provider, enable 2fa with totp, and dont click links from your emails
> first you need to somehow believe that no one is targeted by these schemes.
I don't see how you come to that conclusion at all. The assumption is that _everyone_ is targeted by those schemes.
> But somehow there's a whole international industry that thrives on stuff like Western Union transfers. Why is that?
Because they're low risk high reward, easy to set up, and you only need to make one mistake.
Perhaps instead of telling everyone to think on things for a second, you should think on things for longer than a second?
>And how vulnerable are you to phishing if your special-purpose email address that you only use for one specific purpose receives zero spam?
This would depend on how you setup the email address, if it truly a separate email address i.e a separate account not just an alias then phishing is not the concern but management of the accounts becomes a huge problem
I use separate alias's for every service against my own custom domain that has a single email account. This is not to prevent phishing but to detect when a breach occurred or when my info is sold, you assume that when you sign up for a service only that service will ever have access to your info, many many many companies and service sell your email address to marketers.
If nothing else, the idea of having a separate e-mail account/inbox per use case is an interesting one!
Much like those people that use aliases or something of the sort to be able to tell where who sent then a particular email, like if suddenly some shop+my.account@gmail.com started getting random marketing mails.
> If anybody, it's the sites having the problem of missing users.
I mean, isn't that just the consequence of websites optimizing for whatever seems to work for them and forgetting about the minority of users? It might be missed profit, sure, but that depends on just what portion of the users view this as a dealbreaker.
Maybe there could be an app like Google Authenticator that would offer login to multiple websites through one's phone? We already have that in Latvia somewhat, for banking - you enter your user details in the web form and get a prompt on your phone for your PIN to log in with in the web app: https://www.smart-id.com/
i'm not talking about unselecting all other types of communication, but rather having the service store 2 different emails for you. one for logging in and one for communication.
Here's the truth ; nothing is "secure".
Now... is email more secure than SMS, or less? What about other 2-factor auth things? Is email secure with 2-factor auth?
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.
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.
A password manager with multiple factor authentication sounds better to me.
Until the day Google locks your Google Account.
It's not new tech, but now that two huge players have put it in the hands of millions of users, it should pick up speed.
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".
Users doing "clever" stuff like a random email each time, will also probably understand the situation when they go write down which email for which domain they used and see another entry next to it.
There will be some numbers of users that can't be caught and will create many new accounts, but if thwy use your seevice that much, it will probably stop at one point.
Nothing is foolproof, but there can be many ways to mitigate the issue.
So when I log in with sitename@domain.tld it thinks it's new account and just signs you up as a new user rather than saying you don't have an account.
Now imagine having a bad day and you try and sign in with 5 different emails because you forgot wha one it was and snow you have 5 different "new account" flows with all the bullshit +12+24+48 hour onboarding/retention/marketing emails for all 5 email addresses.
My fault entirely obviously but it is a little mad.
I worked on one site (a chat service for Brazil) that had a 20% success rate for the login flow at first that we got up to the high 80s by tweaking this and that. Later I worked on one aimed at scientists that was in the low 80s before optimization.
Some tweaks from a long time ago are:
1. Put something like ‘we sent a message to <b>your.email@somewhere.net</b>‘ on the post-registration form where they are likely to see it if they make a mistake. Today forms are likely to ask for your email twice to catch this, annoying as it is.
2. Put a form field for the registration code on that form, we found that oriented people towards looking for a registration code. We still sent a link to click on but we found that users preferred to type the code into the form which was fine with us because they succeeeded.
3. Always store the current URL that the person clicked ‘register’ on and store it in the database so they end up where they started after the process is complete.
There was a lot more leak in the signup funnel as people would just leave once asked to do something besides giving their (usually auto filled) info.
So I tend to believe trying to generally match the flow they are accustomed to is the best way, even if you think it’s not the best way.
Either that or you are throwing roadblocks in your user's way. Even if there is no reason for the most common UX to be the way they are, it is what users are used to, and know how to deal with.
Been using this passwordless login recipe by supertokens for my recent projects: https://supertokens.com/docs/passwordless/introduction
Re-inventing the wheel calls for a lot more than usually anticipated. Best to keep it simple - and if you do end up innovating might as well open source it or contribute to an already popular OS solution.
- Not everyone will have set email up on the phone.
- If a laptop is used it adds more complexity if the email is not set up on the device, (or e.g if Gmail is used via a web browser)
- Not everyone will use the Mail app as default and will need to pick the right app
- There may be multiple emails and additional complexity to pick the right 'from' if there are multiple emails being used.
- It is a test of the SMTP server, not the ability to receive email.
- The email needs to match exactly what is being used to sign up when sending the email. With an email inbox email+label@gmail.com can be used as an example.
Using mailto: is just asking for trouble at this day and age.
Exactly. And not everyone accepts HTML E-Mail, i.e. I really hate these "endless" state carrying URLs, which wrap around in my 99 chars wide terminal windows. A short SHA-xxx key should be sufficient, "dear" web form designers.
And last but not least I use greylisting, which still is a useful tool to suppress spam, but delays confirmation emails.
I’ve encountered countless other scenarios where a user is using software in “non-ideal” way because it works for them or they don’t know any better.
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 everybody has DKIM.
- both of those authenticate the domain, not the username. Within the local org network I can probably spoof email usernames without much effort.
Plus... I don't think mailto links really work universally. I remember the last time I clicked one it opened an unconfigured Outlook, even though I use gmail.
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 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.)
You're right that SPF and DKIM are not universal (besides not being strictly for user authentication); this scheme would require a domain to have both in order to be secure and would require some kind of policy attestation around email local parts, which would exclude some email providers and some users. That's why it's "a random idea I had on the subway," and not something I'm doing in production :-)
I could change my client temporarily to send from one of those custom addresses, but I’d have to be quite a bit more interested than usual in your service to bother.
Even users who just have multiple emails in their client would end up sending mail from the default account, which may not match. I have a work account, my personal gmail, my personal domain mail, a family email account, and a side project email account on my phone.
Even if users just have work and personal, how many users are you willing to lose because they sent a mail from the wrong account?
I also think most of the value to the site owner is being able to hit the user with a site->user communication (often an ad or offer of some sort) and me proving I can send you mail from that address is, at a minimum, putting the emphasis on the wrong syllable, and in a lot of cases is telling you nothing about my ability to receive email at that address.
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
A correctly configured mailserver should reject your email (or mark it as spam) if you don't use both DKIM and SPF. It's safe to assume 99.999% of users use both.
Tell me you don't have professional experience in email without telling me you don't have professional experience in email.
Around between four and four and a half orders of magnitude for the Fortune 100, with five orders being the maximum possible wrongness.
* not everybody has an email client set up that works with mailto: links
* sending from an address and receiving emails for an address are very different, and they don't map 1:1
* If you rely on users sending mail to you, the user doesn't know if / when their email is received and processed. They send the mail, try to login, it doesn't work. They have to wait until it's processed, and then forget about your service. OTOH if they receive a mail from you, the mail in their inbox reminds them that they signed up, and as soon they receive it they can use their account.
* I doubt that DMARC/DKIM/SPF are actually deployed as widely as OP thinks, and excluding users based on some (to them) obscure/unknown feature of their email provider is bound to generate frustration. If they self-host their email, your support might end up debugging / having to help them with their email setup.
* There are some subtleties you have to get right, like verify the MAIL FROM, not the From: header, etc. Email is actually a mine field when it comes to security (it's not specified what should happen if a header is sent twice, so some attackers try to fool virus scanners by finding combinations that the scanner interprets one way, but the recipient interprets another way, etc.) Worse, if a verification fails, it's your responsibility to debug it, and you might have to explain the subtleties to a non-technical user.
Mostly bad chrome configs where you need to browser plugin to lauch chrome.
>I doubt that DMARC/DKIM/SPF are actually deployed as widely as OP thinks, and excluding users based on some (to them) obscure/unknown feature of their email provider is bound to generate frustration.
We're at about 30% with DMARC and SPF being deployed in about 65% of email servers. That said, a lot of the really big ones (google, MS, etc...) are in the 30% so are a lot of control panel hosts. Where the slow uptake is, as always is corporate IT departments. Doing the whole DMARC/DKIM/SPF dance isn't hard to do and really puts the clamps on spoofing.
If all you do is use it for login and will never need to send a message, then fair enough, the email is just essentially a random string you can prove ownership of, and your ability to send messages that will be delivered to the corresponding mailbox is incidental. But that's not a general enough conclusion to hold for why "we" (all cases) should do it that way.
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 email. I suspect it's less likely to land as a promotion email in Gmail, because of the code/semantics. It's quite a fun experience as well in my opinion. It seems like more work, but entering 4 digits on the same open tab is easier and nicer experience than clicking on an email link.
There are some security considerations. A short code can be brute-forced, so you need to rate-limit the number of guesses.
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.
This spam filter is broken. A personal email with a signature that contains a blog would be a false positive.
But if you have a link in an email it will go through couple of other checks for sure, where it might be considered SPAM. If there are no links bunch of checks will be skipped.
That is my reasoning, I am not configuring any spam filters on my own.
While the 4 digit code is easy enough to read on their phone in a notification and then type into the other device.
The wording is unclear, so I will ask for clarification: Does the improved email contain both a 4-digit code _and_ a link (URL)?
The crux of verification using an email account is that the person _controls_ the email account. That means the person can receive an email at that account. If the person cannot receive an email at a specific account, that account cannot be used as their identity at the web server.
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 communicate important stuff to you.
Exactly. And the most important thing is password reset, because users forgetting passwords is the one true constant in the universe. Even if I'm not planning to spam you with newsletter crap, I'm still going to ask for your email just for this reason, otherwise I will get inf support tickets about lost accounts and worse, users who just give up.
It helps thinking of the pw reset flow as the true persistent identity/login and password is simply a shorthand. Magic links have virtually identitical security. With just marginally better end-to-end UX, the majority of users would prefer it. (For instance, note the iOS 2fa through text messages, that automatically scrapes the confirmation code and offers to insert it, without leaving the app).
I bring up both of these at the end of the post, under "potential limitations." I'm very aware that SPF/DKIM don't do identity authentication, and that they're not universally applied!
This post is best read as a random thought, not an exhortation or formal argument. It says as much in the first sentence.
Everyone should be able to express their thoughts.
Being able to receive mail on an address should not necessarily imply a capability to send from it. This scheme rules out many actual or potential schemes for email anonymity, especially in a world where very little email is still transactional relatively speaking.
I do not give (almost) any website an address I send normal email from, nor do I want to. And my default configured client for mailto:, if I even have one on the device I'm using, is not going to be set to the single use mail I want to sign up with.
They are exchanging inconvenience for lack of functionality
>…
>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 that want their website to look nice in IE6.
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.
Things like:
- sending empty plaintext part or differnt content in plaintext part and html parts within multipart/alternative subparts (https://www.freesoft.org/CIE/RFC/1521/18.htm) - pretty much only some automated/marketing email is guilty of this. normal senders always get it right
- sending 5 line uncopiable tracking link in plain text (links should be shorter than 80 chars, to not annoy anyone trying to copy paste them)
- sending broken html just because it maybe renders some insane table layout in outlook 97 from 50 years ago more "nicely"
I can only send from kayode@kayode.co and only if I configured my mail client properly because my account is actually a fastmail.com address. Unconfigured, the mail client will send as the fastmail account.
A _significant_ amount of users, especially non-technical ones, won’t have a properly configured email client. They’ll click signup, it’ll open Outlook or Apple Mail, and then they’ll give up on your app in frustration because they can’t register.
There’s very limited room for shifting the signup paradigm in a way that won’t leave N% of your potential users unable to sign up.
No. In one case the proof is "the user receives E-Mails under this address" and in the other it is "the user can send E-Mails under this address".
The service is generally interested in proving the first. For recovery, service-related notifications and for unsolicited marketing. So all the things mentioned in making the "normal" flow undesirable, are actually exactly what the service owner wants to protect against. If their E-Mails don't get to you because they end up in spam or just get dropped by a misconfigured Mailserver, they can't spam you and you won't be able to use this account for recovery.
I agree that the reverse flow is easier (though TBF, mailto links also require the user to have set them up to work, which not all users have on all their devices). But I don't think that's where the incentives align.
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 attack is impossible if the website sends a verification email to the user's inbox which only the person who controls the inbox has access to.
Hence, while the proposed method is interesting, it exposes the user to an unnecessary attack vector.
1. If the target website doesn't validate DKIM/SPF/DMARC, the spoof works. 2. If the target website (or source domain) has a flaw in its DKIM/SPF/DMARC configuration, the spoof works. 3. If the attacker can use a DNS or BGP attack on A) the nameserver of the source, B) the resolver of the target, C) any intermediary, etc, then the spoof works. 4. If the attacker develops a novel spoofing attack, the spoof works.
It's less a question of "how" than "when". A defender has to be successful every time in a myriad different ways; an attacker only has to be successful once. Removing an attack vector is always better than having to defend against it.
Even though it’s be relevant form as systems-thinking point of view, it’s pretty unfair to dismiss a solution because it will be vulnerable to very important pieces of Internet network infrastructure. I think it’s safe to say that if we get a sufficiently bad vulnerability in DNS or BGP, account confirmation emails are going to be least of our worries.
Additionally “any novel spoofing attack” is a very hand-wavy, low effort way to dismiss it as well.
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?).
If major providers such as Gmail/Microsoft/etc agreed to require DMARC for all incoming email senders, then maybe 5 years later we could speak about this again because then DMARC would be universally used.
I'm really surprised no hackers have started sending out phishes via spoofed CloudWatch alerts yet. I guess it takes a while for them to capitalize on industrial vulnerabilities.
If you make a service and ask for email validation, you want validation that the user has that email address. Since anyone can spoof e-mails from any address, getting an email from the address is not validation for anything.
You need to send an email to the account and get a response to validate the email address is real. Otherwise it's trivial for me to go to any web site and pose as you. All I would need to do is spoof your email address.
Edit: I agree that the current state of affairs is unsatisfactory :-)
And what if I use my ISP provided email, and move? Am I just locked out of accounts?
I appreciate the thought process of rethinking our assumptions. But this is not fruitful - the tradeoffs are trivially obvious and unacceptable failure modes.
This author has created a silly flow whereby the user proves that they are somehow able to use e-mail to reflect back some authorization cookie to the server. You can do that without even having an e-mail address; any Internet-connected host can send e-mail, using any sending identity it wishes. The fact that you can contact my server via HTTPS and via SMTP, and relay some information between the two, means absolutely fiddlesticks.
> The “reverse” flow should make intuitive sense: we’re proving that the user controls the specified email address by challenging them to send us an email from it.
Right; here is the core misconception on the part of the author: that receiving an e-mail from someone proves that they control a certain e-mail address. (Imagine the flow being used for password recovery, yikes! Anyone forging an e-mail from you gets your account?)
The second problem with this idea is that it increases the server complexity. Now it has to process e-mail. Conventional e-mail validation doesn't have to receive e-mail; all it does is send confirmation mails. Which, I repeat, any Internet-connected host can do; and it can do so without becoming a mail server.
A third problem is user experience. It complicates things for the user. The handling of mailto: URLs is tenuous. Not everyone has it set up correctly. Many users have some webmail account like Gmail, but when they click on some mailto: URL, some default application comes up that doesn't use their Gmail account. They don't use that application and are prompted to set up that application.
I still think magic links are a good compromise. With a user / pass you still need to verify your email as a separate step. A magic link sends you an email and you're technically verifying your email every time you use it, so it removes an extra step.
It's also really useful for being able to login from multiple devices without needing to keep your password synced with a multi-device password manager. That's especially handy on mobile because even if you're around your desktop with your password manager who the heck wants to manually type `pm'TWZS"$G39c(Es:k@v3-*IhP#DUbows:=='"Z],Ud"R8XO` as a password into your mobile phone?
Lastly, it lets you put the burden of MFA on your email account. If your email account is protected by MFA then your app using magic links is protected by MFA. It means users don't need to give out their phone number or hook up another site to their authenticator app.
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 which point the site can set a cookie for a year and you don't have to deal with logging in by email for another year.
You can also protect sensitive actions by requiring folks to verify their email to replicate how a site might ask for your password to do something like change billing details or whatever makes sense for your app.
It’s unacceptable and everyone I know who uses magic link has eventually given up on them due to user unfamiliarity and a variety of issues such as this one.
This same exact thing happens with a username and password driven site because almost all sites (rightfully) require you to confirm your account after sign up by clicking a link in your email.
And most websites don’t require confirmation email to log in, they require it to unlock certain features.
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 which point the site can set a cookie for a year and you don't have to deal with logging in by email for another year.
There's nothing "magic" about magic links and "remember me". You still read this information from a session and can optionally look up the details from an encrypted and signed cookie (or Redis / Memcached / whatever session back-end) with a user ID which then loads a user from your DB on the back-end. It's the same exact workflow as a user / pass strategy.
Right, and after you click the link in your email to login then your back-end will set a cookie so that when you close your browser and come back again you will be logged in without needing to receive another link your email for however long you want "remember me" to be available.
The person I was replying to said the difference with magic links is you need to check your email every time you login. Especially with his "obvious" remark, it made it seem like he didn't realize you could use magic links and only login once a year just like you could use a password and only login once a year thanks to cookies working the same with both methods.
If I don't have cookies, I have to receive that email again, and it introduces a large amount of failure points EVERY SINGLE TIME this login happens. Instead of just once, on account verification.
Seriously, I've built enough apps that require email verification to know how much of a failure point that email verification is, and it's a significant draw on onboarding when email guarantees are required early on. Doing it every single login (= every new device, every new incognito session, every now and then when the user clears their cache, every time they switch browser, every time they log in from a new computer, etc etc) is insanity, and again, everyone I know who uses magic link has given up on them, or made them extremely optional.
I don't login from new computers often, I have my personal machine and mobile phone. It's great to be able to login from a phone without needing a password manager or manually typing a 50 character randomly generated password where I need to be sitting in front of my main computer to even login. If you really have that many computers you'd still need to sync a password manager between all of them to login with a password.
I also don't browse with incognito mode on sites where I'm expected to be logged in unless I have multiple accounts that I want to have logged in simultaneously.
I also don't routinely switch browsers and if I do I only have to login once per browser and I'm done for a year or however long the site saves it for.
That doesn't sound like insanity to me? I didn't even think about them while writing my original reply because they are such outlier events.
When building a site/service/ui/whatever, you take into account the needs of your users, not your own needs exclusively.
You asked: "I really don't understand why so many folks hate magic links." - I responded with an explanation.
For both of these, I made the case that we should require the incoming emails to pass either a domain aligned SPF or domain aligned DKIM check (essentially what DMARC would do).
Since most people are going to be using a 3rd party email service, this just works by default. If they aren't, we shouldn't have any issue with forcing this requirement as it meets absolute basic email standards.
The higher ups let me do it and we ended up creating an instructional email that would bounce back to failed messages with the reason why, an explanation that we couldn't risk someone being impersonated on the platform and a suggestion that they use the app or website to interact until the issue could be resolved.
In the short time that I was there after that feature launched, we never ran into a problem.
My guess: 95%
1. Part of the reason for doing e-mail verification the old way is to ensure the user can really receive messages at the particular address, for purposes such as password reset or e-mail notifications in the future. The proposed novel verification flow only verifies that the user can *send* e-mails, not receive.
2. My phone is configured with multiple mail accounts. I don’t remember whether you can reliably hint at the mail client to use a particular mail account via a mailto link.Really?
How will this solution tackle the given situation?
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.
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.
Spam filtering in email is performed on the receiving side. You're the recipient, so if your spam filter is filtering emails you want, it's your spam filter that is defective and you are the only one who can solve that.
For me it's the other way around. I don't care about occasional spam. But the possibility of missing message means that I'm forced to read ALL spam periodically.
You can additionally set up email to be forwarded (or retrieved). So, for example, you can easily have your me@example.com account forwarded in to Gmail and Gmail set up to send from that address.
That works fine if the site sends a confirmation email, it'll get to Gmail where the user expects to read it. But the other way around will give the user errors about having the wrong email (even if tj user picks the right outgoing address, because you won't be able to verify it), and ultimately cause the user to give up or you're going to have to spend a lot of time supporting all kinds of weird email configs.
The only legit and practical reason on most web sites is to be able to restore access if you forgot the password.
So just near the password field we can have a "Restore options" section, with email, phone number, etc fields; each having a Test button.
If user have entered email address he can use the Test button and receive a confirmation email, with a link. When user clicks the link, we mark the email as confirmed in DB.
Also, as long as the user does not have a [tested] restore option, we can show him some indicator, like a small red circle on his profile symbol with a tooltip "no restore option configured".
Doing the test email in reverse for me personally would be annoying, because I do not have and do not want to have a configured email client.
So yeah you could build different options for all of these things, and maybe snailmail users of these TOS occasions. But the system of doing this over email is so standardized that the possible friction of one-time setup pails in comparison to the alternatives.
What do you mean by transactional messaging? Could you give an example?
1. receipt / shipping notifications from an online shop 2. emails from enterprise chat apps that let you know you’ve missed messages 3. “Suspicious login” or similar notifications 4. prompts about billing if credit card is nearing expiration or a problem charging your account
I like the idea the author is taking about although I’m not too techie with all the details.
If I tried this “reverse” approach I would do it this way,
After the user creates their account, simply generate a unique token and tell the user to simply copy the token and send it back to a specific email address controlled by me with the token as the subject line and the body is ignored.
This way the user sends the unique code from the email address they want to use so we know it’s them cause how else would they get the unique token.
Is it 100% fool-proof? No. But most things humans touch is not secured 100% anyways but I’d like to think it’s a start.
Coupled with the magic-link approach (including a token in the URL that authenticates the user), this can cause a lot of problems.
Beyond security problems, there can be all kinds of other failure modes. Maybe my domain is blocking email from you. Maybe the address I want to use can't send.
If you need the address because you'll be sending password resets and invoices to it, you want to validate that they can receive there. It was never about whether they "own an email account", whatever that means.
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.
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.
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.
When the user clicks the mailto link, he starts a message chain and my reply almost always goes through appropriately.
As others have pointed out, there are some downsides to mailto links. But I find them to be outweighed by the deliverability benefit that I've seen.
My e-mail client saves my message as a draft as I type, so I can finish my message slowly without fear of losing my progress.
I also know that my email client works. Many web forms are broken and only reveal that once you hit submit, if at all.
Either mail+alias@gmail.com or mail-list@company.com.
For instance, I used admin@, devops@, invoice@, etc. in the places I worked. Each of them includes multiple users (leadership chain and the team)
You're generalizing HN crowd, but you didn't.
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.
Whichever after or before, people will need to open up their mailbox to have access to their newly created account, no matter what, so it does not change anything.
The account creation page could easily provide a plain text email as an option, copy/paste the address, copy paste the code you've been given to send and off you go. Or it could provide both options. Link clicking and mailto.
Not great but else you can configure mailto:handling on any browser/OS
For me the answer is a simple question:
Would the author (or anyone here) be happy to support the proposed reverse email verification process in a production environment which interfaces with the general public? For the sake of forcing the argument, assume the service being accessed is Really Important and failure is generally unacceptable.
This has the advantage that you do not need to receive or send an email.
There may be downsides as well, but I cannot think of any ;-)
https://openid.net/specs/openid-connect-self-issued-v2-1_0.h...
DKIM et. al. security concerns aside, I don't think a mailto link will be easier to use because the web server doesn't control the user's configured handler for mailto links and there's a lot of ways for that link to go unhappy.
Also I can easily see this abused by tons of spamers, where every spam website will have a mailto: popup trying to catch inexperienced users - to reveal their emails.
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
Some caveats:
1. not everyone has email set up on phone. We provide instructions to send email by hand.
2. We emphasize for user to choose correct email if they using work and personal email. No good solution here if user connect game account to work email. Only letter to support
However, these services have to accommodate the technologically less capable. So the degenerate reduction to basically “ok, we’re going to do this the hard/easy way. You just have to click where we tell you to. It’s kinda tedious, but just push the singular buttons we tell you to.”
It's not "just" to verify that this user controls the email address.
So no copy pasting of codes, or having a specific format of the email. We just need to check the sender and recipient.
I haven't really thought this through (what an attacker would gain), just want to point out the general risk.
Do you want to put the code into the recipient email address?
As the owner of a very common [initial][last name]@gmail.com address, I’d take the trade off, but this might be even more niche than neomutt users.
Then you ask them to remove your email address from some other persons account and instead they delete the account. Fun times.
I don’t really know, honestly. I always copy-paste mailto links to Gmail.
And the article also ignores the problems with the mailto:// link. cmon. The solution likely has more issues than the problem it solves.
I don't want to allow a website to link my identity to my email address or phone number.
I don't want the website to push me messages.
I am capable of storing passwords, so no need to send me password recovery emails.
Email verification should be optional.
Such basic things can stop a lot of idiots.
I guess you still lock your house even if proffessioanal thieves can pick your locks. 99% of thieves are not proffessional.
No. I'm hoping that lock-makers work with professionals who do pentesting on locks.
Now of course, HN is more domain specific and niche than other socials so I know it's a bit unfair to compare spam because of course spammers would be more interested in the more populous and general purpose social media, and it's possible that spam and bots on those other services would be even higher if not for email registration, but there's simply no data to support that : email registration is cargo-culted by any remotely user-oriented service without thinking if it fits.
And there is a very good reason to think that email registration is just a dumb lazy hack to delegate problems instead of solving them : come to think of it, email fights spam! How do they do it, by delegating to another email service? Email registration all the way down? Of course not, they just run a bunch of really simple stats on the text to reject the obvious 99% trash. Are reddit and twitter too poor to pay for markov chains running on every text submitted?
Maybe you are, maybe you aren't. As the website's operator, I don't want to manually have to go back-and-forth with everyone who forgets their password to try and verify their identity through their past activity etc.
Making it optional for the people who won't forget is fine, there's no way to know who that will be though. And if your password manager fail you'll be here on HN pointing out how I made a website with not a single fallback mechanism to get back in your account. Why would anyone do that?
That's why I said:
> Email verification should be optional.
So the verification process isn't necessary anymore.
"Is it a good idea?
I have no idea;"
Great, why the article then?
None the less, I learned more about email spoofing from this article then from any other, so it's a nice read.
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...
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.
That same site also says: "Create a plain text version of your email."
Is a burocratic vestige no one need or asked for.
Domino's Pizza; Tinder (they at least sent a verification email, but it was a smokescreen); Match.com; Pinterest; Judicial Watch, Inc.; Straight Talk Wireless; Wayfair; Kellogg's
and many many more.
People sign up with other people's email addresses all the time. In error, or on purpose.
does anyone know where I can find a copy-pastable template for Spring Boot to integrate a classic sign-up workflow in my web app.
I hate to reinvent the wheel here...
Give them the option to enter an email address with a "test" button next to it.
So mailto: is a non starter. A standard that just doesn’t do what a developer might think it does.
No, because email forwarding is a thing and many people use it
What the fuck?
Another major issue I'd personally run into is usage of catch-all addressing [1] (and same issue with plus-addressing [2]). I use a unique email address for every site I sign up to, but I don't easily have the capability to send "from" those addresses. It's not that it's hard to do, but it's enough effort that I'd not bother signing up at all.
> The user is more active: instead of waiting to receive an email in their inbox, the user is immediately presented with an email to send. They can make progress in the flow themselves [...] Even if the flows take roughly the same amount of wall time, this activity makes the “reverse” flow feel faster and more responsive.
Respectfully disagree with this assertion. Users are used to emails taking some time to arrive. I think delays in this flow will feel like your verification service is broken.
> Completing the flow is equivalent to proving that you control an email address
Not exactly. It proves the IP you send from is authorized to send mail for the domain, according to the SPF record setup by the domain owner. It doesn't prove it's your individual email address, and it doesn't prove you can ever receive mail to it.
> The user has fewer opportunities to make mistakes: Users frequently mis-copy verification links, or use clients that mangle them, &c. These mistakes can’t happen in the “reverse” flow, because there’s no verification link to click. The user only has to remember how to send an email, which is a reasonable expectation in any scheme where the user is expected to have an email address.
Except the mailto: link contains a verification code, and thus is subject to exactly the same problems?
IMHO this is better solved by just not doing bad verification URLs.
Bad: https://auth1.web04.example.org/app/1042/verify.php?action=e...
Good: https://example.org/verify/BC44-5204
> The user’s mistakes are easier to detect
If you send the verification email at the beginning of account creation you can avoid them going too far.
If that's a barrier to your sign-up flow, provide some useful options. Eg: after they still haven't verified, ask "Still haven't got the verification email? It was sent to xxxx@example.org, but you can click here to modify it".
[0] https://spf-all.com/by-tld.html
[1] https://news.ycombinator.com/item?id=19333901
[2] https://en.wikipedia.org/wiki/Email_address#Subaddressing
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 government ID in most places. So email verification has become a lazy way to require govenment IDs for even the most basic sites.
It is all built around user hostility. I have added items to a cart,tried to check out and then decided to cancel the whole thing because they have no guest(no-email) check out and require email registration several times this year. Why would they not just take my money? My payment itself is verficiation of anything email can verify?
It is so stupid! Imagine being asked for your phone number and then they call your phone to verify it at every store or business you went to in person.
I challenge any commercial site owner to prove that email registration improves their botrom line.
For non-commercial sites, please understand that you are being needlessly hostile to your visitors, use federated authentication and provide a no-email registration path.
Personally, I think registration itself is outdated. You want users to buy something or generate content on your site. You can still call it registration if you want but you don't need to do more than the bare minimum of authentication which when federated can mean not storing anything new or special about the user other than their login session and associate their content with the identities associated with that session. For example, if HN with github federated, this post and my submissions would be under my GH identity in HN's db, if I want to setup a HN profile, that too would be under that identity. Unless you have a specific need for it, there wouldn't be a table of users with my identity in it.
Lastly, for those that use email as part of an authentication workflow: understand that the use's email security is now your responsibility, because even though you transfered risk lack of options means you are responsible for mandating email as point of failure. So if a user gets phished and damage is done on your site, your site is liable unless you are also providing email security training. There is a reason secret questions exist (although I don't like them), you are not suppose to allow control over an email account as the only factor of authentication requires to reset login credentials. The whole 2FA setup is meaningless if you do that.
"There is no way around it" is such b.s., yes there is, pretend email does not exist, how would you do it? I think you skipped over parts of my post, there is a myriad of messaging applications if you insist control over some external account is the way to go. But really, the ideal way to do this would be have two sets of registration time challenges set. You can go with secret questions but also picture/emoji combinations, pins,patterns as the firsr piece and a second would either be a payment card for $0.01 charge or have them print one-time codes at registration time (second challenge skipped if second-factor auth is good).
"I refuse to change" is what you are saying, you can think about this longer than a minute and come up with more and better ways than what I just mentioned. Not only is email based password reser unneccesary, it is dangerous and lazy.
Another messaging channel is fine of course. You could replace email address by a phone number for SMS/WhatsApp/Signal. Is that more secure though? Would a user rather give your random app their phone number than email address?
Secret questions are usually very much not secret (less safe than password). They are way easier to uncover about a person, and still very much subject to re-use across sites.
I am telling you that I haven't found anything as good and you reply that I must not have taken a single minute to think about it. I guess there's nothing more for us to discuss.
Yes! Even insecure SMS is more secure than email. You know why? Because everybody and their mother is logging and inspecting email, I see people's reset codes and links all the time to everything from banks to porn sites! Many messaging systems including sms have no "account" to get phished either so while other attack vectors like malware infection remain (as with email), credential phishing as an attack vector is eliminated when using these messaging apps. Yes, many people in non-US countries use whatsapp,wechat,facebook or viber but don't even have an email until some retarded app forces them to get one just for the retarded registration system (in some, "internet access" even costs more with just FB,viber,whatsapp being the cheap default). Many gen-Z'ers also use messaging apps over email, it's like asking them to use aol or icq! And it is very convenient to block unwanted senders on those apps if you decide to sell their contact info or spam them with email (where with email it varies greatly with email client and provider). If you go by the numbers the majority of internet users are coerced into using email because people who design apps stuck in the 2000s.
> Secret questions are usually very much not secret (less safe than password). They are way easier to uncover about a person, and still very much subject to re-use across sites.
Depends a lot on how you implement them, again if you read my comment before replying I suggest pictures,emoji and patterns, you can ask them just about anything so long as it isn't information about them others can also learn easily. It is no different than passwords themselves being reused across sites, except here you control what easy to remember questions and answers to ask like "what are your too three emoji from this list" or "create a passphrase from a combination of these common words below", again, not a difficult problem unless in 2022 your assumption is there are many internet users incapable of remembering anything more than their mothers maiden name (who even knows that shit?) or whatever in which case there are plenty of other ways to provide challenges.
> I am telling you that I haven't found anything as good and you reply that I must not have taken a single minute to think about it. I guess there's nothing more for us to discuss.
You literally ignored the possibilities I listed, if you are disagreeing with my comment in ignorance of what I said then yes, let's not waste our time here.
> I think you skipped over parts of my post
> "I refuse to change" is what you are saying
> you can think about this longer than a minute
> if you read my comment before replying
Why are you so hostile? Why use an online forum at all if you will attack anyone engaging with you?
You do have some good points there, but is this really the only way you are capable of expressing them?
"Such b.s." refers to what you said, the rest of what you quoted is hostile but not to you as a person but a criticism of your thinking process and an expression of frustration when you take the time to replh but ignore the plain points I made in my comment and make generalized conclusions like how email is the only way without addressing any of the points in my comment that disagreed with what you are saying. I harbor no hostility towards you but I must criticize your argument and thinking process which might require directness and blutness which in a technical site like HN I would expect to be acceptable.
First, this will always depend on the product you offer. If you target highly specialized tech people, why not, they are most often open to changes. For the rest, it won't never be a good idea.
We tried implemeting a "one time login link" at ImprovMX, like a few others commented here. One drawback we saw was a surge in support requests from people having issues receiving the email, or not understanding how to connect. We could debate on this but definitely, doing something "original" was not a great idea.
But regarding the suggestions made by the original post, I can clearly see a lot (A LOT) of issues:
1. Changing the flow from what the users are used to: Clearly, once you have entered your email and password, you are expecting to receive an email. It's probable that a small percentage of users will close the window once they see the next page asking to send an email, without even reading it, loosing the "mailto:" link with the special token. They will also be lost on what to do; They'll expect an email, and won't understand the need to send one. In a more broader sense, changing the flow will require the users to think harder than usual on what to do, causing more users to leave and never finish the registration form
2. Matching the proper email If they happen to click on that mailto, they will have to remember which email they entered in the form, and will have to keep that in mind when sending the email. For me, if I click on a mailto, I'll have a GMail tab open to send that email, and I have 5 aliases registered. It will require an extra caution to select the appropriate one.
3. Having that email available If the user registers via his phone using an email not configured on that phone, he won't be able to send an email on that "mailto". This will require to copy/paste the link (and copying a mailto on a browser results in A LOT of changes on what is copied), find a way to share that copied data onto a device that has the appropriate email configured.
4. Custom emails Some users enter their email using the specialty of Gmail, such as user+label@gmail.com. When they'll send an email, they won't be able to add that "+label", causing the account creaton to fail
5. SPF/DKIM/DMARC, seriously? Wrapping your head around how these 3 standards works requires significat efforts. And yes, without them, you can not guarantee that the email is truly send by that domain. But still, many custom domains doesn't have a proper DMARC implemented and they can still spoof your account creation. In order to avoid this issue, the only best way is to keep the original flow : the services sends an email to the one the user gave.
Definitely, this is not a good idea to implement for so many reasons, but I agree on the original thought: The current flow has its own issues that needs to be resolved.
One flow I prefer, that doesn't fix everything but still remove a lot of headaches, is to send a code by email when the user has hit "Create my account". The next pages shows that the service expects the code sent by email. Once the user receives the code by email (ideally, having the code in the subject), they can enter it in order to validate their account and they are then automatically logged in a fully activated service.
This removes a few issues, such as:
Not having the email account configured on the same device Ending in a splash page right after creating an account Ending in a splash page when clicking on the link in the email Havign to connect to the service even though you did all the proper validation (I hate that)
The only issue remaining is to ensure the email arrives quite fast. But as long as we need email verification, we will have a hard time fixing this, as it is outside of both the service, and the user hand.
I say: let them experiment. Let this guy implement his clever scheme and see how spam bots population increases several folds and conversion drops 10-15%. If he knows what conversion is and have a metrics for it. And knows what metrics are, also. And if spammers are interested at all in his product. Or whatever.
Also let the legion of newbies and dilettantes vote articles like this to the moon and higher. Let it sit in top 1 HN for weeks. At the end, isn't it a creativity and smartness we should praise and encourage? This is Hacker News, home of brightest startup ideas.
After all, it is good for us, old and inert creeps. Ones who knows what metrics are, how to collect, store and analyse them, how to implement A/B test, and what "statistical significance" means. We still will have several open offers even when all the code would be written by GitHub Copilot, all the texts by GPT3 and all the art by DALL-E.
Forget about retirement, folks, there are interesting times ahead.