- 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.
Right: this would fail for me on my laptop, because I use gmail for email and don't have anything setup such that a mailto: link would compose a new email from my gmail account.
> Not everyone will have set email up on the phone.
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.
Text emails don't have a limited width either. If your email reader and/or terminal app is not able to deal with long URLs then that is really YOUR problem.
Well said. Particularly the point around people not having email set up on an “OS” level. There are a lot of people who already struggle to effectively use modern computers and smartphones, and you’ll run into all kinds of weird edge cases. For example, I previously helped a friend who had just been using the gmail website on their smartphone for years because they had forgot their password but Safaris keychain had saved it so they could auto fill the password.
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.
I don’t remember the last time I clicked a mailto: link, and probably haven't seen one in a long time. And it’s configured to use the default Windows 10 Mail app, which I don’t use. Can I change it to Firefox and Gmail? Sure, but why would I bother?
This isn’t better. I don’t have a default mail client and a lot of people don’t. You could open up the browser page to login but by the time you’re logged in all context is lost and you won’t get the pre setup outgoing mail ready to click send.
A general rule of thumb I've built up over the years: resist the temptation to innovate around login!
Look at the most commonly used flows that are not obviously terrible and try to implement as close a match to them as possible.
When I've tried to innovate around login in the past I've found that any clever ideas I come up with inevitably run into road blocks pretty quickly.
Here's one example: why have a separate 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.
When I started on my first project as a junior engineer I thought I was being clever to build an app without any passwords: every time you wanted to login you received a new email with a link to log you in. Technically, this worked great but after a while I received many complaints from frustrated users who kept looking for the “signup form”…
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.
Okay, but what if you don't know your password and your password manager is offline or you don't have access to it on your phone or the phone ran out of battery or... I assure you we can find a similar amount of cases where passwords would fail. It's mostly novelty phobia.
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.
That's crazy! I was reading the article and kept in mind what we did in ImprovMX and was surprised to see we were mentioned in the comment :D
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").
Thats a crazy level of risk assessment for an average user.
> 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.
> Thats a crazy level of risk assessment for an average user.
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?
Do you think youre going to get scammed and send a fraudulent Western Union transfer? What do you think the venn diagram overlap between "uses a specific email for each service" and "gets phished" is? The people that even have the capacity to do the first aren't going to fall into the second. If someone is sending fraudelent transfers to scammers, they're not going to be smart enough to create multiple emails.
> Do you think youre going to get scammed and send a fraudulent Western Union transfer?
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?
You are right of course in one sense, but look at the comments here! If the HN crowd is still sending verification links rather than codes to be copy and pasted, that implies regular folks are still clicking the links..
> To claim that the most basic and easy internet security precautions are at a "crazy level",
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.
> But they don't have a problem - they just don't use the passwordless sites.
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/
can you name even one service that uses login links and allows you to configure an address that is exclusively used for login links and not any other communication?
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.
That is a fair point, indeed this would probably make the configuration page extremely complex.
I guess my suggestion would only work for cases where you don’t really care much about other kinds of notifications.
And yet it's surprising how many sites allow you to reset a password using nothing but an email link (single factor authentication - and there are already known cases of emails being silently redirected).
Amazon does this! Morons will ask you to "click the link in the sms" to "authorise access". I can understand doing this randomly once or twice, for security. But every single time!? Figured they were doing it for two reasons - data-mining (to figure out what mobile phone and mobile browser yo have, and to leave an Amazon cookie on your mobile browser), and to harass you into installing and using the Amazon app instead of the website. Had to call customer support multiple times before this stopped (who kept urging me to install the Amazon app).
Unfortunately even privileged users (that have authority to change the permissions or possibly passwords of other users) can still use weak passwords.
A better solution would be to have your browser prevent you from reusing passwords (it only needs to keep hashes).
If the web browser is governing the passwords you can and can't have, and forcing you to have unmemorisable passwords, you're better off rethinking the whole thing. For instance, it probably makes more sense to ask the web browser to generate keypairs rather than passwords if we know the passwords cannot possibly be memorised.
I don't reuse passwords, or use a password manager. I just have a system for remembering which password to use for each website, and maintain a list of hints. And I have a pretty terrible memory. But having had the password I used to re-use across a few (non- critical) sites show up on haveibeenpwned it's what works best for me.
That turns all users into a greater threat in the case of any bugs in the server. Makes it easier for the service to get DOS'd by authenticated users, and so on. Allowing on user to be more insecure, makes all users more insecure.
It’s still better than using the same few passwords everywhere or having a system with the site name. Because you need only on website vulnerability, which is quite common, to compromise your passwords. It’s better to have a single unlikely point of failure than many guaranteed points of failure in my opinion.
Chrome has a password manager but the key is stored for you, which is less secure because it’s not using a HSM (hardware security module) as far as I know.
Your single point will be compromised. Someone gets access to your system they now have access to all of your passwords. Your password manager is hacked. Your device dies. Putting your eggs in one basket feels like a smart thing until you lose that basket.
I agree it’s not perfect but what is your better solution? My email and some passwords have been collected at least 8 times according to https://haveibeenpwned.com/
A password manager with multiple factor authentication sounds better to me.
Firefox is great in that regard: when you fill in a signup form it will automatically suggest you a long, generated password, and will then store it for you.
That is not really unique to Firefox, right? Safari does it as well and I am pretty sure Chrome does it too (I am not a Chrome user, so I can't check).
This is news for me. I've been using a local password manager for ages and disabled any browser form support since maybe the last century so I missed all those new functionalities. I'll keep using my password manager anyway, it's not only for the browser and not only for one device. I sync the db across devices with Syncthing, I don't login into any browser cloud sync.
For your example, this seems bizarre. Every "sign up" process I can think of ends with you being signed into to your new account. Every "log in" process includes a button or link that says "are you a new user, sign up here". You chose a very streamlined thing to worry about.
That's a step of the signup process. AS this article points out, that link ends up with you back in your browser and logged in. In fact, that's probably the most important reason to bring you back to the browser - so you end in the logged in state and can memorize the password in your browser.
This is why views are so nice. You can reuse the view and controller logic and only write a new data model that updates instead of creates (tbh though those can just be two functions on some data model.)
People do go back to the signup page a lot. Redirecting them when detecting an existing account from the email is enough in the most common cases.
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.
There is a site I use that does this. I try and use $sitename@domain.tld as the email for most things I sign up to. Occasionally this gets wonky like the site in question because it was originally a Patreon sub for access so the email for the site was patreon@domain.tld then they switched to their own payment system but my email for them is now locked to patreon@domain.tld.
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.
At the same time, the whole idea of a shared secret instead of asymmetric crypto is source to so many leaks that I wish we would pressure services to not use password-based authentication as their default.
That’s what I used to believe. Circa 2000 the advice was ‘do what Yahoo! does’ and that was good, but when I revisited that in 2006 I found that Yahoo’s signup and login process was deformed by the need to discourage users from responding to phishing attempts —- a bank needs to be concerned about this but it will hurt the login for other sites that have higher iq users and aren’t big enough that spamming everybody is a good tactic.
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.
> 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.
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.
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.
This is not well reasoned. Sending emails can be easily spoofed, because sending doesn't fully check the identity of the sender as being in control of the email account. There is discussion of various technologies like SPF or DKIM, but those are not universally applied. When they are applied, there isn't universal quality in their application.
The crux of verification using an email account is that the person _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'd argue the crux is about proving that Me The Service can send You The User whatever info is needed (password reset, notification of planned downtimes, pricing changes, warnings about service abuse) to this address - and you'll get it.
I don't care about you "controlling" an email address - you can easily get fake ones for free. It's about both parties having agreed _at least once_ on a way for the service to communicate important stuff to you.
Ownership over the email shortname is exactly what is being proven. It’s your identity as far as the service is concerned. I can block emails from a service right after verifying so verifying does not guarantee that I will receive emails from the service at any point in the future.
If you do block it, your access to the account you’ve created might be in jeopardy. At least it depends on how you “block” it. If the service receives an error on future emails, the user’s account can be disabled, as usually described in the TOS.
> 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).
With this method, it seems to me the entire user registration information would be in your Sent folder. So forgetting the password should be more difficult. Though you would still need to reset a password.
> This is not well reasoned. Sending emails can be easily spoofed, because sending doesn't fully check the identity of the sender as being in control of the email account. There is discussion of various technologies like SPF or DKIM, but those are not universally applied. When they are applied, there isn't universal quality in their application.
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.
I personally like the scheme. But I think it caters to the technologically capable, in particular the “compose an email with this bit of magically secure content” skill.
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.”
What’s doing the verification of the email on the server side? How does this service associate the email with the account? Specifically, what could be put in the email header or body by the MUA that is equivalent to a single use auth token?
1. Attacker goes to website, initiates signup up for an account
2. Website generates mail link for attacker to send
3. Attacker uses mail link to spoof email
4. Account is opened for the attacker using email address
This spoof attack works for both account creation and password reset (account takeover).
This attack is impossible if the website sends a verification email to the user's inbox which only the person who controls the inbox has access to.
Hence, while the proposed method is interesting, it exposes the user to an unnecessary attack vector.
The attacker just sends an email that they got from the target server's "mailto" link. They just have to use a spoofing method when they do. Such as:
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.
Yes. 1) DKIM, SPF and DMARC do not prevent spoofing, they simply make it less easy. A compromise of those methods, or an attack on DNS or BGP, or any other novel spoofing attack, gives the attacker a successful attack vector that would not exist if the website simply sent the user an email to verify. 2) The unique token and timeout is simply given to the attacker when the attacker initiates the new account/password reset form, it has no bearing whatsoever on security.
> or an attack on DNS or BGP, or any other novel spoofing attack
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.
It's not unfair to point out a design as needlessly insecure. Regardless of the method, this design adds a new attack vector (email spoofing) that did not exist before. Even if it was very hard to do, it's an unnecessary added risk.
The same attacks can likely also be used to capture verification emails. E.g. for DNS if you can spoof TXT records for Gmail using some malicious server, chances are you can also spoof MX records. And I can't think of shenanigans with BGP that allow you sending spoofed emails that pass DKIM, SPF and DMARC (ultimately routing traffic to your malicious server again), but not allow capturing of mails.
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?).
Yes I do find them unsound. Now you need ordinary people to understand the pros and cons of DMARC (SPF + DKIM). Not every one has this configured. In fact it's shocking how many companies don't have DMARC set up given the benefits.
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.
As an example: AWS has no DMARC on its SES domain, and its SES domain is what sends SES emails from by default. Anyone who's not using a custom domain with SES, has no way for anyone to validate where that email came from. All CloudWatch alerts come via the generic SES domain, so there is literally no way to tell if a CloudWatch alert is spoofed or not.
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.
Having to tell an ordinary user that their domain didn't configure DKIM properly so sign up didn't work and they now have to go through an alternate flow sounds like a nightmare. The article does not mention what to do with the many users who don't already have the mentioned security mechanisms, just that they are "commonly deployed".
>…and here it is in neomutt, which helpfully “renders” the HTML with lynx:
>…
>But that’s a solution born from practice: the fact remains that HTML email doesn’t generally degrade gracefully in clients that don’t support images or CSS.
I hope that companies don’t waste their time at such edge cases that are irrelevant for 99.9% of users such as Lynx graceful degradation. It reminds me of the stories about clients that want their website to look nice in IE6.
Yep. I read this and thought PEBKAC. Optimise for the base case, be inclusive of those using screen readers, ignore the masochists who insist on making life difficult for themselves by refusing to use technologies that have been around for decades. The author's other issue - multiple browser sessions open and logged in to different accounts and tabs opening in the last active one - this is a more common annoyance. But easily solved by the user making sure they are in the right browser session by focussing it. So PEBKAC again.
I'll say as the PEBKAC'd author: I try to remember to focus the right browser session! But I still load the wrong one about once a week, and whether it works with a particular site is a crapshoot.
Without weighing in on this, I think this entire section is a distraction in this post. The author's point in this article would be better served by moving the HTML rant to its own blog post.
Multi-part MIME emails with both plain text and HTML content used to be a standard[1] or at least a good and common practice. Not including plain text version or making it "can't see newsletter? click here for web article" is an ongoing process of moving users from unsnoopable email to invigilated web. It's invisible to dumbed-down users, possibly saves corpos some money: devs can learn something that benefits business more and, depending on email volume, business may decrease spending a bit by removing few kilobytes of text from each message sent.
Imo a standard of sorts, being removed due to lack of knowledge or for money (savings on data transfer or profit from data gained from users reading "web version of email" and email clients loading remote content) doesn't make it an "edge case". The edge case here (necessity to parse and read HTML in pure email client) is an effect of businesses and developers not following standards in the first place.
Also, IE6 overstayed its welcome not due to edge user cases but due to corporate savings as well.
If company can't be bothered to learn how to send email properly, their email will just go to trash, thank you. :)
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've had family members fall prey to phishing scams. I would be concerned if legitimate sites trained their users to send odd content to odd addresses as part of normal net usage. How can an ordinary person understand the difference between sending a token to real.com and sending a threat to another user on behalf of fake.com?
Besides the security and usability problems others mentioned, I also highly doubt it will improve confirmation conversions.
One thing that helped us improve confirmations -- we A/B tested it and confirmation rates increased ~8%: send a 4-digit confirmation code rather than just a link.
It's easier and more familiar on mobile, especially if you see the code on the push notification, so don't even need to open the 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.
Agreed. Usability on mobile is best with the short codes. Even 2 FA is fairly efficient that way as long as the messages are designed to show the code in the preview.
Not having a link in email is important. I believe most of the times email from my systems go to spam because there is a link in it.
I don't have any hard data but I can imagine that if email contains link it will be checked by more rules in heuristic checks. If there are no links - most likely it is not spam.
in our case we included both a link and the code and saw an increase in confirmation rates. If I recall we reached over 90% conversion rates. For a B2C niche service, I think that’s pretty high. I somehow doubt removing the link will improve things further, but it might be interesting to test in future.
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.
I've seen similar numbers on an ecommerce site. The theory there was the people may be on a device where their email isn't logged in. So doing that and then clicking your link is a lot of work and could run into even more hurdles like Gmail 2FA popping up because they don't use that device frequently.
While the 4 digit code is easy enough to read on their phone in a notification and then type into the other device.
This doesn't work for creation because it's too easy to spoof where the email came from.
In the OP's diagram this really hinges on the Mail Transfer Agent (MTA) needs the ability to verify that Mail User Agent (MUA) is legit, and that is quite hard.
Realistically MTA would need to go to a known MUA address to verify do you actually own this account?
But not all is lost!
This does work great for 2FA. Where the contents itself is is the only requirement of trust. Just make the contents unrealistic to copy/spoof and then it doesn't matter who sent it.
The whole point of email verification is to verify that the user is able to receive email at the given address. Aside from the other issues mentioned here, the proposed solution does not achieve this.
I can 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.
I use email aliases that I can't send email from. It's also possible that email from your domain is blocked by mine, and I would never receive that invoice or password reset link. In reverse, there are addresses on my company's domain I can send from but not receive at, and I shouldn't be allowed to sign up with those.
I would hate this, and probably instantly bail out of any flow that tried to force it on me.
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.
$Work does not allow outgoing (out of domain) emails but *Requires* signup to a bunch of websites for stuff like provident fund management and stock compensation. This kind of workflow is not possible for those cases
They are exchanging inconvenience for lack of functionality
A lot of email clients support multiple email accounts, or at least sending addresses. Not just desktop ones like Thunderbird, but web ones like Gmail too.
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'm very skeptical of relying on every random domain on the internet setting up SPF/DKIM properly to the point it's trustworthy in this way. I can't find stats on usage of `~all` (soft fail) but only an abysmal 6.4% of .com domains have `-all` (hardfail) [0].
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.
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".
328 comments
[ 4.5 ms ] story [ 273 ms ] thread- 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.
https://support.google.com/a/users/answer/9308783?hl=en
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.
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.
Really?
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.
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.”
My guess: 95%
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.
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.
>…
>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.
[1] https://www.rfc-editor.org/rfc/rfc2046.html#section-5.1
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"
Coupled with the magic-link approach (including a token in the URL that authenticates the user), this can cause a lot of problems.
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)?
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.
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.
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
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.
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.
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