> 99.9% of websites on the Internet will only let you create one account for each email address. So if you want to see if an email address has an account, try signing up for a new account with the same email address.
This is not true if the signup flow is implemented correctly. Signing up for an account should always respond with the same message "we sent an email for you to confirm your account signup". The owner of that email address then receives an email - either 1) normal signup process, or 2) "did you just try to sign up? You already have a valid account for this email address."
This way you cannot tell via the signup web form alone whether an account exists or not. You need to have access to the email address.
The vast majority of the time the number one priority is reducing friction before a conversion. As much as a email confirmation prior to completion is more secure, the business case is far less strong.
Customers can fix their email later, they can contact customer support if they got something wrong.
Get them in the door ASAP, and either using the account, or complete an order. Don't redirect them to their email where there is a good chance they will either get distracted or the email will be delayed.
That's not to say you shouldn't also have your own measures in place to detect errors, or malicious checking if an email is associated with an account.
The lowest friction workflows make data collection/entry as lazy/delayed as possible and maximize optionality. Allow users to "save as default" as part of their normal workflows on your site, rather than demanding the information up-front at signup.
The welcome/email verification email should have an expiring passwordless sign-in link (and maybe a way to set password if you decide to support passwords). If I use your site rarely enough, I don't even save your information into my password manager. Your password reset workflow is my normal sign-in workflow. Kudos to sites that don't force me to generate a one-time random password for this sign-in workflow. In practice, I think a lot of people accidentally use this as their login procedure on rarely visited sites.
If account creation is part of the ordering workflow, make the most significant 6 (or more) digits of the order ID a secure message authentication code of the rest of the digits and delay verification of the email address. That allows you to delay email address verification and still securely correct email address typos (of recent orders) if the user records their order ID.
If your site has made birthday mandatory but you haven't demanded a government ID for verification or run a credit check, I've lied to you about my birthday.
If your site demanded a mailing address but you're not shipping anything to me, I've lied to you about my address.
If you're demanding to over-collect information, and I'm polluting your data lake, that's on you.
Side note: the McDonald's app is nice in not requiring (or apparently even allowing) passwords to log in. However, there's a problem with its state transition, where the user needs to exit from the dialog that sends the sign-in link before they go to their email and click on the sign-in link, otherwise the user gets dumped to the next step without having actually signed in.
Even an async validation would be better. I have <common name>@gmail.com, and get several newspapers and some other subscriptions for free.
In one case, a person named Mary in Australia sends their loved one a gift card every year, and the retailer doesn’t provide any information about Mary. In another case, a student missed out on their work study job and a opportunity for early class enrollment due to a bad email.
It’s sad as all of these customers don’t even know that they have a problem.
Discussions of friction and login/signup always drive me crazy. Like I get the need to get people to sign up. But security is always an afterthought - it always loses to lower friction.
And don't get me started when the PM starts lowering friction to the point where they are basically trying to trick the user.
If reducing friction is the priority, then maybe skip email completely. Let people sign up with any username and don't require an email at all, like HN allows. Most sites that require an email don't need an email, and only ask for it so they can spam users with nonsense like product updates.
This is bad in the case of online orders, where the order will usually go through anyway (vendors want to sell even when you don’t confirm your email address, and don’t care a lot about someone else getting the notification emails), because if by mistake you registered your email address as new although you already had an account with that address, the order won’t get associated with your account. Or if it does automatically get associated with the account (or after confirmation), then that’s bad as well if you really entered someone else’s email address, because your order will then get associated with their account.
This is the reason why attempting to sign up for an existing account generally fails right away, at least for online retailers.
Not sure exactly what you mean? Are you referring to a purchase flow where you are buying something and also given the option to checkout as guest or signin/signup?
I am only speaking to the typical signup flow that anyone can access signed out without putting in any information besides email/pw. If you are in a purchase flow where valid credit card info is already entered and is going to result in actual purchase $$, you've already excluded bots/hackers who would be trying to brute force account enumeration. It would be totally fine to confirm the existence of an account in a web form in this situation as it is not a flow that can be easily brute forced for free with little effort or info needed (like a credit card).
If security is not a priority for the vendor, then yes. Otherwise, no, the order will not go through anyway.
I'm very aware that in many many cases, the former is true in the real world, but that doesn't change the fact. This isn't a good justification for the op's dismissal of the practice.
Woocommerce plug-in of Wordpress solved that issue. You can checkout as a guest with someone else’s email, you won’t see other orders from that email and if you do want to see them then you need to sign up for an account
That exact strategy is described in the second paragraph but the author argues (and I agree) that it is so arduous it will cause you to lose many users for questionable benefit.
Yes but the exact quote is confusing as he specifically mentions email addresses (in bold text). I know the author mentions usernames elsewhere in the article and I agree with the author this isn't applicable to websites that allow username signup since anyone can pick any random string... But for email address signup, as the exact quote mentions, there is no additional context switching since you already need to confirm the email address regardless.
In simple registrations this is fine. In multi-page registrations with long forms, it can waste the user's time by making them input all the data again when it wasn't needed, though.
Except in really critical applications like payments, etc., as a user I'd rather have the convenience of being warned early about already having an account that the little extra security.
How often does it happen that you fill out a multi-page registration form just to notify you that you already have an account? I rarely bump into the issue of already having an account that I forgot.
Is saving that extra amount of work in a rare case a concern in practice? Sure, it would annoy me a bit if it happened to me, but I'd be more like "man, I'm stupid" instead of "man, this site is stupid, I'll never go there again."
Are you saying your signup flow would automatically log the user in without confirming their email address (verify later)? I wouldn't suggest that for most websites as that would allow someone to signup with an email address they don't own.
For most websites transacting with potentially sensitive information, having an email sent to confirm you own the email address should already be part of the normal flow, so I'm not suggesting any extra step here. I was only suggesting an alternative email response in the situation you try to signup with an email that already exists. The normal happy path signup flow for a new account is not affected at all by my comment.
And then what happens when the user tries to login with the password they just "created". They will get the same error message as before, but be extremely confused since they just "registered" with that password. Not to mention their browser may have prompted and stored the fake registration password, etc.
What do you mean login? I'm talking about the signup flow. The signin flow would be consistent with what is discussed in the article "invalid username or pw".
Another method is to delegate the registration and login flow to external providers, using OAuth.
If you have to log in to a website via one of Microsoft, Google, Facebook, Twitter, etc. then, if implemented properly, there's no way of knowing if an account associated with this external identity exists already.
Most of those are trying to track me around the net for their own purposes. I'm not volunteering any extra information for them to profile me with. No thanks.
True. Moreover, even if a site implemented this in a naive way, they made the UX much worse for the attacker.
And that constitutes a significant issue, if we follow the reasoning of the article.
It does, actually: it hampers casual attackers -- those looking for any account in. On the other hand, attackers out to break into a specific account will not be deterred. Then again: they are not deterred in either case, so you might as well go with the version that impacts some attackers.
If you did implement it like this it would be helpful to receive an email telling you that somebody has tried to re-register the email address you already have an account with.
* If a user tries to create an account using an email address, don't tell the user if an account with that email address already exists. Similarly, if a user tries to do a password reset using an email address, don't tell the user if there is no account with that email address. Providing that information would allow an attacker to determine if a specific email address is being used (or not) by some existing account.
Now for the unpopular take: not everyone lives in the US. The GDPR requires protection of personally-identifying information, and in many cases that includes email addresses that identify individuals. There are exceptions, but it's typically better to keep email addresses private unless the user specifically authorizes it.
Sure, I guess? But the overwhelming majority of sites on the internet do not do this. Primarily because their new signup flow has priorities that matter an order of magnitude higher for them than avoiding leaking whether an account already exists.
But the error message can be true. If you mistype your username, you might have entered another, existing username. Just telling the user 'wrong password' will mean they are less likely to check that the username was correct.
The website doesn't always know which one you got wrong, and assuming one way or the other just makes things worse.
> If you mistype your username, you might have entered another, existing username.
That's a good point, but there is no way the website can detect that situation, and I suspect it is much less likely than typing your correct username and the wrong password.
> The website doesn't always know which one you got wrong, and assuming one way or the other just makes things worse.
If the website doesn't know which one you got wrong, then yes, it should just tell you so; the article is not arguing otherwise.
You can provide a more helpful error message by explicitly informing the user that the username they typed exists but they haven't offered the correct password for it.
Unless the site searches to find out which username the entered password actually corresponds to (which is a whole new, terribly dangerous, can of worms), it can't do better than that
Because any malicious player can easily check whether usernames exist, so hiding that data point is not much good for security.
> You can provide a more helpful error message by explicitly informing the user that the username they typed exists but they haven't offered the correct password for it.
The parent poster already addressed that though:
“If you mistype your username, you might have entered another, existing username. Just telling the user 'wrong password' will mean they are less likely to check that the username was correct.”
If you inform the user the username they typed exists, the chance of them not thinking about double-checking they didn’t mistype their own username increases.
It doesn't seem like the author is arguing that just because you can instead validate if the email exists on a platform via the signup page instead of the login page, the vague message can be removed, but rather that the signup page should remove the information leakage as well, so there is no leakage anywhere.
I don't get it. It's fine to leak/allow user enumeration on the login page because it's leaked elsewhere anyway? That's a pretty big assumption.
One way to allow users to register using their email address without leaking any information is to just say "user created, please check your inbox to confirm your email address" or something like that. If the user already exists, swap the confirmation email for a warning email if they already have an account.
In a sense, yes. If you’re revealing an account’s existence on one page, your system isn’t made more secure if you hide its existence on another page. If you think it does, you’re fooling yourself. Better to use other tools (like rate limiting) to improve security.
And yes, you’re missing the second part of the article where the author mentions the registration flow you describe and then points out that it’s not a great user experience.
There is also the question of leaking whether a given user has an account on a website or not.
Maybe I don't want my employer to know that I have an account on competitor-service.com, or my partner to know that I have an account on kinky-thing.website.
It might not be a security issue, but it could be a privacy issue.
> Unfortunately this assumes that there's no other way for an attacker to discover whether a username/email address is registered for a service. This assumption is incorrect.
> 99.9% of websites on the Internet will only let you create one account for each email address. So if you want to see if an email address has an account, try signing up for a new account with the same email address.
This point is undermined by the sign-up workflow informing of whether an account is registered under a given username.
That depends on the sign-up workflow. It is possible to not provide the information "user already exist" on sign-up and instead just say "we sent you an email, please confirm". In this scenario a potential attacker who just wants to check for existing email addresses has no access to the email addresses he wants to check.
The contents of the email could be something like "Hey you just tried to register with this email address, but we already have an existing account with this email address ... Was that you? ... Maybe you have forgotten got your password?"
The author explains in the article that you're not protected from that case either, as the attacker can try to sign up with your email and find out anyway if that email is already registered.
Many services let you sign up with an existing email and just send a “you tried to sign up, but you seem to have an address already.” to the account owner. In that case it’s indistinguishable for the attacker.
Many services already require email confirmation to finalize the signup process so the extra effort is low.
Xylakant explains how to cope with that in a sibling comment. Note that email is personal information often containing name, surname and maybe a likely year of birth (johndoe92@example.com). Leaking it is not OK in several legislations so we should take special care before telling someone that some person is or is not in our database.
This is a huge problem - if I know your email, and can get the error pages, I can find out where you have accounts; sometimes I can even find out the account name with that.
Even worse with phone numbers.
If you want to confirm a user is the same as another user on a different site, and you know their phone number, often part of the recovery process will reveal part of the phone (a text has been sent to *-*-*33, eg).
> Maybe I don't want my employer to know that I have an account on competitor-service.com, or my partner to know that I have an account on kinky-thing.website.
In that case, maybe employ the basic opsec measure of having a separate email account for competitor-service.com and kinky-thing.website?
> Heh, after an independent security review we are being forced to take this even further;
We lock people out for five minutes after three invalid login attempts. We are no longer allowed to tell users they have been locked out. So, even if they do remember their password (or even does a reset) we just have to tell them their uid/pwd is wrong when they try to log in. And for “forgot password”? Just tell the user “we have sent you an email – IF we recognised the email you put in”.
This sounds absolutely horrible, and now I'm wondering if I've been subject to this behaviour. Couldn't remember my password (for a trivial site where I use one of my reuse passwords and didn't put it in KeePass), started doubting if I had the correct email, eventually reset the whole thing, reset the password to the password that I thought it should have been, and got an error telling me the new password couldn't be the same as the old one.
I felt this with LastPass. It put in some secret locked mode, and wouldnt let me login even wit h right password. 3-4 hours later, it just started working. I was a paying customer, didnt get any replies to my emails.
It pissed me off so much I moved to 1Password AND Bitwarden -- 2 in parallel, so if anyone pulls this on me again I can immedietely move to the other
> Unfortunately this assumes that there's no other way for an attacker to discover whether a username/email address is registered for a service. This assumption is incorrect.
Security is never perfect, it is always about making it annoying enough that people don't bother. So yes, there are other ways to see if someone has an account. But odds are the person attacking your site is not singling out one account to hack, they are trying bulk attacks with many accounts. So you avoid leaking info to not give the script any more ammo on what else to try. And hopefully the attacker will move on to some site that did give it more ammo.
Maybe instead of saying the email address is already in use on the site, just let the "sign up" happen and tell them to check the email for a confirmation link, and in the confirmation email say "someone is attempting to sign up with this email that is already signed up, if this was you, use the Forgot Password link to reset the password for the existing account. If it was not, click here to report this incident."
> it is always about making it annoying enough that people don't bother.
> But odds are the person attacking your site is not singling out one account to hack, they are trying bulk attacks with many accounts.
I feel like these two statements are at odds with each other. A regular user is going to get annoyed. An attacker using a script and multiple attempts is simply going to include the other way of verifying if an address is real in the script.
"99.9% of websites on the Internet will only let you create one account for each email address. So if you want to see if an email address has an account, try signing up for a new account with the same email address."
Yes, but signing up is a more cumbersome process and usually has a CAPTCHA attached to it, unlike logging in.
> Yes, but signing up is a more cumbersome process and usually has a CAPTCHA attached to it, unlike logging in.
My guess of what is most common is that the actual trying to create a user in the backend/database is protected by a captcha, but checking if the email/username already exists is a separate endpoint that the frontend hits while filling out the signup form, before trying to create the actual user.
But it's just a guess, and I can already think of many examples where that doesn't happen, which is for good reasons.
> but checking if the email/username already exists is a separate endpoint that the frontend hits
I'm sure this happens in some cases, but it's definitely not a good practice, would hopefully get flagged by any pentesting or security audit, and also, most people use some sort of framework for auth (devise for Rails, Spring Security for JVM, or similar) - and those usually don't work in that way.
The only site that has ever asked me to solve a CAPTCHA before browsing content was pcpartpicker.com, and even that one stopped making me solve a CAPTCHA.
Do you browse the web behind a VPN, Tor, or something else to hide your IP? That's been known to trigger CF's CAPTCHAs.
Readit News
This is not true if the signup flow is implemented correctly. Signing up for an account should always respond with the same message "we sent an email for you to confirm your account signup". The owner of that email address then receives an email - either 1) normal signup process, or 2) "did you just try to sign up? You already have a valid account for this email address."
This way you cannot tell via the signup web form alone whether an account exists or not. You need to have access to the email address.
Customers can fix their email later, they can contact customer support if they got something wrong.
Get them in the door ASAP, and either using the account, or complete an order. Don't redirect them to their email where there is a good chance they will either get distracted or the email will be delayed.
That's not to say you shouldn't also have your own measures in place to detect errors, or malicious checking if an email is associated with an account.
The welcome/email verification email should have an expiring passwordless sign-in link (and maybe a way to set password if you decide to support passwords). If I use your site rarely enough, I don't even save your information into my password manager. Your password reset workflow is my normal sign-in workflow. Kudos to sites that don't force me to generate a one-time random password for this sign-in workflow. In practice, I think a lot of people accidentally use this as their login procedure on rarely visited sites.
If account creation is part of the ordering workflow, make the most significant 6 (or more) digits of the order ID a secure message authentication code of the rest of the digits and delay verification of the email address. That allows you to delay email address verification and still securely correct email address typos (of recent orders) if the user records their order ID.
If your site has made birthday mandatory but you haven't demanded a government ID for verification or run a credit check, I've lied to you about my birthday.
If your site demanded a mailing address but you're not shipping anything to me, I've lied to you about my address.
If you're demanding to over-collect information, and I'm polluting your data lake, that's on you.
Side note: the McDonald's app is nice in not requiring (or apparently even allowing) passwords to log in. However, there's a problem with its state transition, where the user needs to exit from the dialog that sends the sign-in link before they go to their email and click on the sign-in link, otherwise the user gets dumped to the next step without having actually signed in.
In one case, a person named Mary in Australia sends their loved one a gift card every year, and the retailer doesn’t provide any information about Mary. In another case, a student missed out on their work study job and a opportunity for early class enrollment due to a bad email.
It’s sad as all of these customers don’t even know that they have a problem.
And don't get me started when the PM starts lowering friction to the point where they are basically trying to trick the user.
This is the reason why attempting to sign up for an existing account generally fails right away, at least for online retailers.
I am only speaking to the typical signup flow that anyone can access signed out without putting in any information besides email/pw. If you are in a purchase flow where valid credit card info is already entered and is going to result in actual purchase $$, you've already excluded bots/hackers who would be trying to brute force account enumeration. It would be totally fine to confirm the existence of an account in a web form in this situation as it is not a flow that can be easily brute forced for free with little effort or info needed (like a credit card).
> vendors want
If security is not a priority for the vendor, then yes. Otherwise, no, the order will not go through anyway.
I'm very aware that in many many cases, the former is true in the real world, but that doesn't change the fact. This isn't a good justification for the op's dismissal of the practice.
Except in really critical applications like payments, etc., as a user I'd rather have the convenience of being warned early about already having an account that the little extra security.
Is saving that extra amount of work in a rare case a concern in practice? Sure, it would annoy me a bit if it happened to me, but I'd be more like "man, I'm stupid" instead of "man, this site is stupid, I'll never go there again."
I believe this is also non-standard right now.
For most websites transacting with potentially sensitive information, having an email sent to confirm you own the email address should already be part of the normal flow, so I'm not suggesting any extra step here. I was only suggesting an alternative email response in the situation you try to signup with an email that already exists. The normal happy path signup flow for a new account is not affected at all by my comment.
If you have to log in to a website via one of Microsoft, Google, Facebook, Twitter, etc. then, if implemented properly, there's no way of knowing if an account associated with this external identity exists already.
Deleted Comment
It does, actually: it hampers casual attackers -- those looking for any account in. On the other hand, attackers out to break into a specific account will not be deterred. Then again: they are not deterred in either case, so you might as well go with the version that impacts some attackers.
For example, the OpenSSF's secure software development fundamentals course <https://openssf.org/training/courses/> in its section on minimizing feedback <https://github.com/ossf/secure-sw-dev-fundamentals/blob/main...> says:
* If a user tries to create an account using an email address, don't tell the user if an account with that email address already exists. Similarly, if a user tries to do a password reset using an email address, don't tell the user if there is no account with that email address. Providing that information would allow an attacker to determine if a specific email address is being used (or not) by some existing account.
Now for the unpopular take: not everyone lives in the US. The GDPR requires protection of personally-identifying information, and in many cases that includes email addresses that identify individuals. There are exceptions, but it's typically better to keep email addresses private unless the user specifically authorizes it.
Deleted Comment
I got some code to fix.
The website doesn't always know which one you got wrong, and assuming one way or the other just makes things worse.
That's a good point, but there is no way the website can detect that situation, and I suspect it is much less likely than typing your correct username and the wrong password.
> The website doesn't always know which one you got wrong, and assuming one way or the other just makes things worse.
If the website doesn't know which one you got wrong, then yes, it should just tell you so; the article is not arguing otherwise.
Why? The website can salt, hash, match your password against all the hashed passwords for all the closest usernames within a certain edit distance.
Not saying this is a good idea security-wise, but it's not impossible.
That could allow “bad username” if you got the password right!
Dead Comment
Unless the site searches to find out which username the entered password actually corresponds to (which is a whole new, terribly dangerous, can of worms), it can't do better than that
Because any malicious player can easily check whether usernames exist, so hiding that data point is not much good for security.
The parent poster already addressed that though:
“If you mistype your username, you might have entered another, existing username. Just telling the user 'wrong password' will mean they are less likely to check that the username was correct.”
If you inform the user the username they typed exists, the chance of them not thinking about double-checking they didn’t mistype their own username increases.
One way to allow users to register using their email address without leaking any information is to just say "user created, please check your inbox to confirm your email address" or something like that. If the user already exists, swap the confirmation email for a warning email if they already have an account.
Or am I missing something?
And yes, you’re missing the second part of the article where the author mentions the registration flow you describe and then points out that it’s not a great user experience.
Deleted Comment
Maybe I don't want my employer to know that I have an account on competitor-service.com, or my partner to know that I have an account on kinky-thing.website.
It might not be a security issue, but it could be a privacy issue.
> 99.9% of websites on the Internet will only let you create one account for each email address. So if you want to see if an email address has an account, try signing up for a new account with the same email address.
This point is undermined by the sign-up workflow informing of whether an account is registered under a given username.
The contents of the email could be something like "Hey you just tried to register with this email address, but we already have an existing account with this email address ... Was that you? ... Maybe you have forgotten got your password?"
Many services already require email confirmation to finalize the signup process so the extra effort is low.
Even worse with phone numbers.
If you want to confirm a user is the same as another user on a different site, and you know their phone number, often part of the recovery process will reveal part of the phone (a text has been sent to *-*-*33, eg).
In that case, maybe employ the basic opsec measure of having a separate email account for competitor-service.com and kinky-thing.website?
It is an advantage of using things like the apple-generated randomized emails for accounts.
> Heh, after an independent security review we are being forced to take this even further; We lock people out for five minutes after three invalid login attempts. We are no longer allowed to tell users they have been locked out. So, even if they do remember their password (or even does a reset) we just have to tell them their uid/pwd is wrong when they try to log in. And for “forgot password”? Just tell the user “we have sent you an email – IF we recognised the email you put in”.
This sounds absolutely horrible, and now I'm wondering if I've been subject to this behaviour. Couldn't remember my password (for a trivial site where I use one of my reuse passwords and didn't put it in KeePass), started doubting if I had the correct email, eventually reset the whole thing, reset the password to the password that I thought it should have been, and got an error telling me the new password couldn't be the same as the old one.
It pissed me off so much I moved to 1Password AND Bitwarden -- 2 in parallel, so if anyone pulls this on me again I can immedietely move to the other
Security is never perfect, it is always about making it annoying enough that people don't bother. So yes, there are other ways to see if someone has an account. But odds are the person attacking your site is not singling out one account to hack, they are trying bulk attacks with many accounts. So you avoid leaking info to not give the script any more ammo on what else to try. And hopefully the attacker will move on to some site that did give it more ammo.
> But odds are the person attacking your site is not singling out one account to hack, they are trying bulk attacks with many accounts.
I feel like these two statements are at odds with each other. A regular user is going to get annoyed. An attacker using a script and multiple attempts is simply going to include the other way of verifying if an address is real in the script.
Yes, but signing up is a more cumbersome process and usually has a CAPTCHA attached to it, unlike logging in.
My guess of what is most common is that the actual trying to create a user in the backend/database is protected by a captcha, but checking if the email/username already exists is a separate endpoint that the frontend hits while filling out the signup form, before trying to create the actual user.
But it's just a guess, and I can already think of many examples where that doesn't happen, which is for good reasons.
I'm sure this happens in some cases, but it's definitely not a good practice, would hopefully get flagged by any pentesting or security audit, and also, most people use some sort of framework for auth (devise for Rails, Spring Security for JVM, or similar) - and those usually don't work in that way.
This just made me to visit and login even more infrequently.
Do you browse the web behind a VPN, Tor, or something else to hide your IP? That's been known to trigger CF's CAPTCHAs.
I've learned much of compliance/security is cargo culting and/or streetlight effect, if not radicalized.
You can debate the standards, just like you can debate with your retired uncle who watches way too much fox news.
The better solution is to find good enough solutions that let infosec teams check their boxes and move on to more important work.