10 ms·
> 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 s
by darrinmn 4y ago
> 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.
- emodendroket 4y agoThat 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.
- darrinmn 4y agoYes 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.
- emodendroket 4y agoOften you don’t need to confirm the e-mail address to complete whatever workflow you’re doing.
- darrinmn 4y agoSure, companies are free to make their own choices based on their business incentives. But if you can create an account and be logged in without verifying an email address, then arguably the email address wasn't needed in the first place and you should just allow any type of username string. If the goal of your website is for email address to be the username, the you should confirm the user actually owns the email address they claim first - since anyone could lie and put a random email they don't own.
- rmbyrro 4y agoAuthor talks about that in the article
- lhnz 4y agoIf 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.
- thomastjeffery 4y agoThat's the option #2 they described.
- Al-Khwarizmi 4y agoIn 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.
- thomastjeffery 4y agoYou shouldn't be doing long web forms before creating an account anyway.
- zhfliz 4y agoYou shouldn't be taking my email just to demand lots of information from me after I already gave my email to you. If you demand lots of information that should be clear right away.
- thomastjeffery 4y agoI can sympathize with your frustration about long web forms, but that seems to me like a separate issue with a separate solution. People shouldn't be making long forms part of account creation unless absolutely necessary; in which case it should already be obvious to the user that it is. If it's somehow necessary but not obvious, you can put up a friendly warning. Maybe something like, "Step 1/12" or "expected registration time 15min."
- deleted 4y ago[deleted]
- TeMPOraL 4y agoSo now you're saying web UX should actually improve and give up the major disadvantage it has over paper forms: hiding the full flow from the (l)users. /s, but only slightly. You're right, of course. The answer is the one nobody wants to hear: you can tell users what you'll want from them, then ask to create an account, and then ask them to do the things you outlined before registration. As for multi-page forms, they make sense if you target non-JavaScript use, but if your site is already an SPA, you might as well present the form in full, and conditionally disable parts that don't apply based on earlier inputs. This is the way to improve over the paper UX.
- metacritic12 4y agoWhile clever, this system has UI tradeoffs, if I need to break my signup flow in order to click on a link and return to the signup page. I believe this is also non-standard right now.
- prmph 4y agoCould you please elaborate? What's the standard best practice for signup now?
- darrinmn 4y agoAre 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.
- metacritic12 4y agoI think the sibling post by samwillis explains my view the clearest. Basically, the business case for breaking the signup flow to require users to check their email is low. It interrupts flow and reduces conversion rates. The suggestion then is yes, you are allowed to use emails you don't own to sign up for an account. The reason this is allowable is that who would want to do it? The account would be broken and the real owner of that account can pop your password.
- cozzyd 4y agowell, a user might put in the wrong email by mistake...
- 4y ago
- gohohn 4y agoAnother 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.
- mint2 4y agoGiving in my Facebook that centralized view and extra data… no thanks. Same with Microsoft and google.
- gohohn 4y agoThe only information they would receive is that you signed in to a specific website.
- godshatter 4y agoMost 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.
- gohohn 4y agoThe only extra information you would be volunteering is that you signed in to a specific website. In most cases, this is not really a big deal.
- godshatter 4y agoIf I don't want them knowing I surfed to somewebsite.com, why would I want them to know that I actually logged in to someotherwebsite.com? I get that people have different levels of trust for these services than I do. I'm just more cynical than most, I guess.
- bombcar 4y agoYou are also trusting the Oauth provider to never login as you for their own inscrutable purposes.
- layer8 4y agoThis 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.
- darrinmn 4y agoNot 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).
- cryptoegorophy 4y agoWoocommerce 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
- layer8 4y agoWhat if it wasn’t someone else’s email, but your own with an existing account? Can you re-associate your order with the existing account?
- 4y ago
- thefreeman 4y agoAnd 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.
- darrinmn 4y agoWhat 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".
- thefreeman 4y agoWhat do users usually do after registering an account? They try to login with it (assuming they aren't automatically logged in after registration which is what I would generally prefer / expect as a user). You are giving the user so many chances to just say "forget this" and move on to a different website. Especially if they are on mobile, registering for services is a huge pain in the butt. My basic point is you are severely impairing the UX to prevent what I think is an extremely minor and generally irrelevant piece of information leakage.
- gchamonlive 4y agoThe flow is 1. Sign up for an account 2. Enter the email 3. Receive a confirmation email 4. Create password 5. Sign in This is what op means. You just ingest step 2 without confirming the email is used or not. The actual account creation should occur only after email confirmation.
- thefreeman 4y agoGotcha. That does make more sense and basically signup and reset password are essentially the same process. If the user doesn't have an account previously at that point you collect the information needed to proceed. I personally would not want to break up my onboarding experience like this but I can see other people making the trade off.
- samwillis 4y agoThe 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.
- MichaelCollins 4y agoIf 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.
- marcosdumay 4y agoAny site that requires a password will need an email for password resets.
- MichaelCollins 4y agoIf the site doesn't need email for anything besides that, then it doesn't need email for that either. Let the user set an email for account recovery if they want, but don't require it. If users who choose not to give an email forget their password, they can simply create another account. This is the way HN works. It's the way most websites used to work, until maybe 15 years ago, give or take. Today almost all sites ask for verified email addresses, but this used to not be the case. Besides the commercial value of having user email addresses, I think it's mostly done for the webdev's ego: > Users need to hear about my new update! (Because if I don't spam their inbox, nobody will notice or care about the thing I just did.)
- deleted 4y ago[deleted]
- IshKebab 4y agoI've used exactly one site ever that had this sign-up flow, and hundreds that had the stupid "invalid username or password" error.
- deleted 4y ago[deleted]
- Beldin 4y agoTrue. 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.
- dwheeler 4y agoExactly, if you reveal that an account exists when you just type in an email address, then you have a privacy failure and probably a security failure. For example, the OpenSSF's secure software development fundamentals course <https://openssf.org/training/courses/ https://openssf.org/training/courses/> in its section on minimizing feedback <https://github.com/ossf/secure-sw-dev-fundamentals/blob/main/secure_software_development_fundamentals.md#minimize-feedback--information-exposure 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.
- sbf501 4y ago0.1% representing! I got some code to fix.
- akerl_ 4y agoSure, 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.
- iudqnolq 4y agoBy your definition almost no popular website - including Google - implements signup flow correctly.