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.
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.
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.
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".
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.
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.
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.
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.
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.
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.
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.
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.)
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.
- 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.
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.
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.
Using mailto: is just asking for trouble at this day and age.
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.
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.
>…
>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"
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.
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.
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.
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.
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.
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?
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.
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.
Really?
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.
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)
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...
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.
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?
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."
* 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.
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
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.
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.
Coupled with the magic-link approach (including a token in the URL that authenticates the user), this can cause a lot of problems.
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.
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.
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.
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.
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.
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.
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.
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.How will this solution tackle the given situation?
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.
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.
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.
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.
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.
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.
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.
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.
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
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.