A much easier, and already widespread, way to prevent the problem described in the post is to use the email address as the login username. It is highly unlikely that the same person will mistype the same email address every time he tries to log in, so the mistake will be caught very quickly even if someone else clicked the confirmation link.
If a person enters the wrong email address at signup, no damage is done. He can just sign up again with the correct email address. The account with the incorrect email address will either remain uncomfirmed and deleted at some point, or belong to someone else. Doesn't matter, it's an empty account. You should prune unconfirmed, empty accounts periodically anyway.
If you really want users to have a separate username, nickname, handle, or whatever, that's fine. But that should be separate from the login, especially if it's going to be visible to other users.
The "damage" that is done is that the user is doing things attached to their account and now they no longer have access to it when they try to come back later.
I am sure you can also get autofill to get the email address correct on popular devices for most people, therefore making the process fairly frictionless. Plus email address is a very good primary key.
Email addresses are awful primary keys. Sure, it's unique. But the other main property of a good primary key is that it never changes. Email addresses change constantly. People use their work or university address for personal things, and then change jobs / are laid off / graduate. Or they use an email from their ISP, and move. Or they used to use one webmail system, and switch to one with a better UI; buy their first Apple device switch to an icloud email instead of a gmail one.
It's fine to use an email address as the thing you enter into a login box. But internally you really want the user records to be keyed by something else, and just associate an arbitrary number of email addresses to that.
Indeed, the ecommerce system at my company used to use email+password as the account identifier (because reasons) and when we tried to deduplicate we found a lot of duplicates were things like SmithFamily@isp.example.com where one account always shipped to "Laura Smith" and the other one always shipped to "Harry Smith".
Email addresses are a terrible primary key. They change (and they change a lot). They are longer than strictly necessary.
A related problem there isn't a one-to-one mapping between email address and person, one person can have several email addresses. If you want to let a person have many accounts and keep track of which accounts a person has (like ebay does) then you're going to need a person primary key too and can't make an assumption about email = person.
Its my opinion natural primary keys should be used very, very sparingly if at all. There's basically no "person" natural key. Even social security numbers are subject to various problems when used as primary keys. SSNs can (rarely) change. Laws and policies around SSN use and storeage also change.
Adding friction to user registration should be done with caution, forcing users to go through your registration form and then refuse access to the site until they click on an activation link and then enter their registration information again is so much friction, it's going to drive users away and will frustrate those who do push through it... and it's completely unnecessary.
The problem this idea proposes to solve is an edge case, and there are better solutions. For example after registering an account a user can be immediately logged in with a banner displayed at the top until their account has been validated via email, with the option to change their email address if they entered it incorrectly on registration. There's no additional friction, and the minority of users who do make a mistake with their email are covered.
The article wasn't suggesting a three step process (1 enter username+password, 2 validate email 3 enter username+password), it was suggesting a two step process (1 validate email 2 enter username+password).
These two desirable features, email verification and minimal friction are not incompatible. It is possible to allow a user to login right away and verify email in parallel. It could also be possible to ask the user to double check the email if the email validation failed. It could also be possible to force a delayed email validation.
The later might be required for user who porvided a fake address when just testing the service or want to make sure they wont be spammed by the site owner. A reminder with a "don't show me again" check box would address these cases and everybody would be happy.
Minimal friction is especially desirable in startups that are trying to grow their user base that provide some sort of service that is not tightly bound to identity, but it is not always the most desirable measure.
> For example after registering an account a user can be immediately logged in with a banner displayed at the top until their account has been validated via email
That still wouldn't solve the problem the author proposes to solve. If you accidentally entered someone else email, that someone might click on the link and you'll never see the banner.
Perhaps there's a room for a functionality that automatically backs up the page that is linked to HN provided it gets enough votes (actual algorithm is up to debate) :)
I ran into exactly this problem about two years ago with Google Apps for Work. I mistyped my email address, but was able to finish registration and start using it. When I noticed my error, there was no way to change the account's email address without confirming that through the original one, which I obviously couldn't. I had no other choice than letting go of the account.
It's quite silly because you'd think for a big platform like this, they would have thought about such a case, but they obviously didn't.
if user doesnt verify email within a few days, that email "expires" and is removed from the account. Add a message to nag the user to add a proper email to their account.
this removes the edge case mentioned in the article and reduces sign up friction.
I don't necessarily agree with the article but your proposition does not solve the scenario described, where the owner of the email address gets the emails and clicks confirm out of curiousity or habit
the problem that the article describes is that an incorrect email was entered at sign up, and the user gets invested in their account, all for it to get hijacked by original the email account owner down the road. Expiring an unconfirmed email solves this.
There's still many other possible scenarios but I think it generally does what the author wants in a not so annoying way.
No, you are incorrect. What you propose wouldn't stop the situation described at all.
From the article:
> What happened?
> Well, turns out that the person that actually owned the jon.smith@email.com was a kid that was curious and clicked the email from TheService asking him to verify his email address.
> He himself forgot about this until a couple of years later when he heard about TheWebsite from some friends, and decided to try it. He tried to create an account and got an “account already exists” error. He used the password reset functionality and that’s that. He now owns the original John Smith’s account.
While outside publishing platforms those needs are rare (and that's why I consider it an antipattern) I agree with you in terms of a publishing platform.
Having a separate non-email username allows the user to change his email, for instance when he changes his ISP (many people still use ISP-provided email), or if his current email provides ceases providing service.
Financial institutions do this. I guess its part of layered security. It's annoying but I can see why they do it, I wouldn't consider it an anti-pattern.
I could change the email if I know the username and password. I could change the username if I have access to the email and password. If it adds no benefit then it should be removed.
>I could change the username if I have access to the email and password.
No you can't.
Lets say I download a database leak of email/password combos from a popular service. I can't go onto bankofamerica.com or whatever and start iterating through that leak for password reuse, I don't know the username for a given email account.
Usually password reset goes something like this:
If I click on "forgot password" it asks for username and email address to email me a password reset link. If I click on "forgot username" it asks for email address and other information a financial institution would know, like SSN, account number, credit card number, CVV code. You can't do anything with just email and password. You can't even do anything with access to that email address and password. I just reset my password with Wells Fargo last night and it even gave me security challenge questions from my credit report to change my password (questions like what car did you own, what's the payment amount for your mortgage, what address are you associated with, where does $(relative) live?).
- website that use a username as the primary identifier will make it clear that the email address has not yet been verified. They will nag the user to confirm the email address, or at least prominently indicate that the email is not yet verified. It will be difficult for the user to not notice an unverified email address.
- most websites use the email address as the identifier. If the user used the wrong email address to create the account, they will not be able to subsequently log in.
- some website require you to verify the email address before you create the account, even though they ask for all the information on a single signup form.
Confirming the email requires logging in. If you are already logged in then your session might be sufficient, but if you open the confirmation link on another device (like your phone) it will ask you to log in.
If the site uses the email address as the primary identifier and there is no separate username, it is OK if someone confirms a mistyped email address. In such situations, an account should not be created until the email address is confirmed. Let's say matt@gmail.com is sitting in front of the computer and creates an account for mattt@gmail.com. mattt@gmail.com confirms the email address and is now the owner & controller of that user account. matt@gmail.com does not have access to that account, nor did he get a confirmation email. Ideally, he will realize something is wrong and will try creating the account again.
If the site uses a username, and the email is just a contact method, the process of confirming the email address should ask the user to re-enter the password.
In my experience, as someone who has a lot of dealings with users, I've found that users are very goal-oriented. They have a particular task they want to complete, and they just want to get on with it. A website may prompt for email confirmation, but if confirming their email is not actually necessary for them to complete the task at hand, there's not much incentive to do it.
A website needs to make a determination how important it is for them to have a verified email address. If the email address is used only for notification or marketing purposes, then there it should not put too much pressure on the user to validate the email address.
If, on the other hand, the email address is required for something important, such as password recovery, it should make a concerted effort to get a user to provide one.
> If the email address is used only for notification or marketing purposes, then there it should not put too much pressure on the user to validate the email address.
You must verify the address -confirm the opt-in- before you start to send stuff to it. If you don't you're spamming.
It's interesting how it's common practice to ensure email addresses are confirmed before sending marketing messages to them, whereas there doesn't seem to be such a requirement for telephone numbers or postal addresses.
Agree with all your points, but I actually really like the idea of having the signup form only ask for e-mail. Do the confirmation song and dance, and then ask for the rest of the users details (name, password, etc).
Absolutely! If done right, the workflow you suggest takes a lot of friction out of the registration process.
You can do even better! You can just let a user start using your application without even providing an email address. Keep track of the user via a cookie at first. Present them with opportunities to provide an email address (and other info) if they wish to return in the future. Once they do, associate the account with the email address. After that, continue asking for more information on a need-to-know basis.
> You can do even better! You can just let a user start using your application without even providing an email address. Keep track of a user via a cookie.
This is not better from a business 101 perspective. You've just traded the ability to communicate with some of your users without requiring their e-mail.
It depends on the business/service. In some cases it's a good idea to give the user a taster of what they can do with the service before making them sign up.
You know what I do when I come across a service that forces me to sign up before I can see if it's any good? I hit the back button.
The taster can be in the form of a descriptive home page, landing page, or article. It could also be in the form of a completely friction-less trial that does not ask for any user info. The latter are rare.
It's up to the user to decide if they should invest their time in trying out the product based on whatever taster the website offers.
There's one major problem with this idea from user point of view:
when you have just a "enter your email" field and nothing more, you already gave someone an email and got nothing in exchange yet, then at the next step, you click the link, and they ask you about 100 mandatory things to finish registration, asking about everything including your shoe size. Then you might not want to register to this kind of site out of principle, and also can not unregister anymore usually.
(To be fair, sometimes pages have multi-step registration and do the same, asking few innocuous things first, and more privacy-invading things later. I hate that.)
First of all, after clicking the mail link only a username and password is to be set. It is your job to design it such that it is not a menial task to register.
Secondly, if the user decides to not register after all, just give them an unlink mail button at the registration form. This way they can stop the registration and use the mail in the future if they change their mind.
> Secondly, if the user decides to not register after all, just give them an unlink mail button at the registration form.
This is one of those things that never get implemented by 99% of teams due to "why would someone need it" / "additional complexity not worth it" / "we'll do it later"
I wonder if it's really necessary to provide an unlink mail button. If the user decides not to register, then an account is not created. They can simply abandon the registration process and forget about the service.
Unless the service sends out regular email reminders or something to anyone who has entered their email address, then I can understand the need for an unsubscribe link.
I wish this was the only problem with signing up to services, because it can be solved with formfills, verifying your email upon entering it, etc, etc.
As someone who got their last name at gmail in 2004, I've gotten a lot of emails for other people over the years, and A LOT of services don't require verifying your email for signing up.
I've gotten a Twitter, Instagram and Fiverr account without signing up (on top of probably hundreds of smaller services, golf clubs, local news, charities, etc), and definitely without ever clicking a link in an activation email I didn't sign up for. The latter of which I can't delete, nor change my username, effectively burning that email address for that service.
I'm sure those named services have since fixed that, but that it was ever an issue in the last 15 years baffles me.
Nowadays I use my own domains for email, so it matters less, but I wish even confirming emails at all for services was more enforced.
I'm sure this is all rooted in services wanting to grow their "user"base rather than have real users.
A possible solution: a) Allow multiple registrations with the same email until a confirmation click happens and b) require a browser session or password to confirm.
people that can't remember or don't want to look up their password
Or people who use long complicated passwords and don't want to type them on mobile (yes, yes, I usually copy/paste my password manager generated passwords, but magic link is still easier)
For what it's worth, that is what Mozillas Persona was offering (and what portier is offering now). I'm not sure which was the biggest site using that and did not find it searching just now, but maybe you have more luck.
>I wonder if anyone has implemented a non-optional version of this on any decent scale? i.e. is anyone using passwordless 'email link'-only login?
Yes, Craigslist.
There's username and passwords now but I believe that's relatively new. The typical workflow doesn't include registering and there wasn't originally an idea of an account (if I recall correctly).
Marco Arment also did this a while back with either "The Magazine" or Overcast (I forget which one, only heard them discuss it on the Accidental Tech Podcast). No passwords at all.
The article says the e-mail was confirmed, but by wrong person:
> the person that actually owned the jon.smith@email.com was a kid that was curious and clicked the email from TheService asking him to verify his email address.
Unfortunately, most comments to this article miss this point and argue about unconfirmed addresses instead.
71 comments
[ 3.3 ms ] story [ 163 ms ] threadIf a person enters the wrong email address at signup, no damage is done. He can just sign up again with the correct email address. The account with the incorrect email address will either remain uncomfirmed and deleted at some point, or belong to someone else. Doesn't matter, it's an empty account. You should prune unconfirmed, empty accounts periodically anyway.
If you really want users to have a separate username, nickname, handle, or whatever, that's fine. But that should be separate from the login, especially if it's going to be visible to other users.
OP's suggestion is just an extreme version of the same principle, since it won't even allow people to set a password until their email is confirmed.
It's fine to use an email address as the thing you enter into a login box. But internally you really want the user records to be keyed by something else, and just associate an arbitrary number of email addresses to that.
No, it's not even unique.
A related problem there isn't a one-to-one mapping between email address and person, one person can have several email addresses. If you want to let a person have many accounts and keep track of which accounts a person has (like ebay does) then you're going to need a person primary key too and can't make an assumption about email = person.
Its my opinion natural primary keys should be used very, very sparingly if at all. There's basically no "person" natural key. Even social security numbers are subject to various problems when used as primary keys. SSNs can (rarely) change. Laws and policies around SSN use and storeage also change.
The problem this idea proposes to solve is an edge case, and there are better solutions. For example after registering an account a user can be immediately logged in with a banner displayed at the top until their account has been validated via email, with the option to change their email address if they entered it incorrectly on registration. There's no additional friction, and the minority of users who do make a mistake with their email are covered.
The later might be required for user who porvided a fake address when just testing the service or want to make sure they wont be spammed by the site owner. A reminder with a "don't show me again" check box would address these cases and everybody would be happy.
That still wouldn't solve the problem the author proposes to solve. If you accidentally entered someone else email, that someone might click on the link and you'll never see the banner.
Cached version: http://webcache.googleusercontent.com/search?q=cache:Er9PEaJ...
It's quite silly because you'd think for a big platform like this, they would have thought about such a case, but they obviously didn't.
if user doesnt verify email within a few days, that email "expires" and is removed from the account. Add a message to nag the user to add a proper email to their account.
this removes the edge case mentioned in the article and reduces sign up friction.
There's still many other possible scenarios but I think it generally does what the author wants in a not so annoying way.
From the article:
> What happened?
> Well, turns out that the person that actually owned the jon.smith@email.com was a kid that was curious and clicked the email from TheService asking him to verify his email address.
> He himself forgot about this until a couple of years later when he heard about TheWebsite from some friends, and decided to try it. He tried to create an account and got an “account already exists” error. He used the password reset functionality and that’s that. He now owns the original John Smith’s account.
- Tell people how to get to your profile in person (and remember how to get to someone’s profile without needing a link)
- Mention people by name
- Keep your e-mail address private
You might also want to associate the same e-mail address with multiple profiles.
This seems like an overgeneralization.
No you can't.
Lets say I download a database leak of email/password combos from a popular service. I can't go onto bankofamerica.com or whatever and start iterating through that leak for password reuse, I don't know the username for a given email account.
Usually password reset goes something like this:
If I click on "forgot password" it asks for username and email address to email me a password reset link. If I click on "forgot username" it asks for email address and other information a financial institution would know, like SSN, account number, credit card number, CVV code. You can't do anything with just email and password. You can't even do anything with access to that email address and password. I just reset my password with Wells Fargo last night and it even gave me security challenge questions from my credit report to change my password (questions like what car did you own, what's the payment amount for your mortgage, what address are you associated with, where does $(relative) live?).
- website that use a username as the primary identifier will make it clear that the email address has not yet been verified. They will nag the user to confirm the email address, or at least prominently indicate that the email is not yet verified. It will be difficult for the user to not notice an unverified email address.
- most websites use the email address as the identifier. If the user used the wrong email address to create the account, they will not be able to subsequently log in.
- some website require you to verify the email address before you create the account, even though they ask for all the information on a single signup form.
I'll address two common situations:
If the site uses the email address as the primary identifier and there is no separate username, it is OK if someone confirms a mistyped email address. In such situations, an account should not be created until the email address is confirmed. Let's say matt@gmail.com is sitting in front of the computer and creates an account for mattt@gmail.com. mattt@gmail.com confirms the email address and is now the owner & controller of that user account. matt@gmail.com does not have access to that account, nor did he get a confirmation email. Ideally, he will realize something is wrong and will try creating the account again.
If the site uses a username, and the email is just a contact method, the process of confirming the email address should ask the user to re-enter the password.
There are always users who exceed your expectations.
A website needs to make a determination how important it is for them to have a verified email address. If the email address is used only for notification or marketing purposes, then there it should not put too much pressure on the user to validate the email address.
If, on the other hand, the email address is required for something important, such as password recovery, it should make a concerted effort to get a user to provide one.
You must verify the address -confirm the opt-in- before you start to send stuff to it. If you don't you're spamming.
You can do even better! You can just let a user start using your application without even providing an email address. Keep track of the user via a cookie at first. Present them with opportunities to provide an email address (and other info) if they wish to return in the future. Once they do, associate the account with the email address. After that, continue asking for more information on a need-to-know basis.
This is not better from a business 101 perspective. You've just traded the ability to communicate with some of your users without requiring their e-mail.
You know what I do when I come across a service that forces me to sign up before I can see if it's any good? I hit the back button.
The taster can be in the form of a descriptive home page, landing page, or article. It could also be in the form of a completely friction-less trial that does not ask for any user info. The latter are rare.
It's up to the user to decide if they should invest their time in trying out the product based on whatever taster the website offers.
when you have just a "enter your email" field and nothing more, you already gave someone an email and got nothing in exchange yet, then at the next step, you click the link, and they ask you about 100 mandatory things to finish registration, asking about everything including your shoe size. Then you might not want to register to this kind of site out of principle, and also can not unregister anymore usually.
(To be fair, sometimes pages have multi-step registration and do the same, asking few innocuous things first, and more privacy-invading things later. I hate that.)
Secondly, if the user decides to not register after all, just give them an unlink mail button at the registration form. This way they can stop the registration and use the mail in the future if they change their mind.
This is one of those things that never get implemented by 99% of teams due to "why would someone need it" / "additional complexity not worth it" / "we'll do it later"
Unless the service sends out regular email reminders or something to anyone who has entered their email address, then I can understand the need for an unsubscribe link.
As someone who got their last name at gmail in 2004, I've gotten a lot of emails for other people over the years, and A LOT of services don't require verifying your email for signing up.
I've gotten a Twitter, Instagram and Fiverr account without signing up (on top of probably hundreds of smaller services, golf clubs, local news, charities, etc), and definitely without ever clicking a link in an activation email I didn't sign up for. The latter of which I can't delete, nor change my username, effectively burning that email address for that service.
I'm sure those named services have since fixed that, but that it was ever an issue in the last 15 years baffles me.
Nowadays I use my own domains for email, so it matters less, but I wish even confirming emails at all for services was more enforced.
I'm sure this is all rooted in services wanting to grow their "user"base rather than have real users.
Doesn't this solve the issue presented?
I wonder if anyone has implemented a non-optional version of this on any decent scale? i.e. is anyone using passwordless 'email link'-only login?
Or people who use long complicated passwords and don't want to type them on mobile (yes, yes, I usually copy/paste my password manager generated passwords, but magic link is still easier)
Yes, Craigslist.
There's username and passwords now but I believe that's relatively new. The typical workflow doesn't include registering and there wasn't originally an idea of an account (if I recall correctly).
edit: found it, it was overcast
https://marco.org/2012/07/31/passwordless-login
https://overcast.fm/skeptics_faq
> the person that actually owned the jon.smith@email.com was a kid that was curious and clicked the email from TheService asking him to verify his email address.
Unfortunately, most comments to this article miss this point and argue about unconfirmed addresses instead.