101–110 of 289 posts
> 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…
> 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…
While 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.
Earlier quoted context omitted.
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.
You shouldn't be doing long web forms before creating an account anyway.
If you demand lots of information that should be clear right away.
> 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…
This is the reason why attempting to sign up for an existing account generally fails right away, at least for online retailers.
> 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…
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.
Earlier quoted context omitted.
Quoted post unavailable.
Again, how is that leakage, if you can just try registering a new account and see if that username or email already exists?
Neither login nor sing up form should tell you that the account already exists.
> 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…
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.
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."
Earlier quoted context omitted.
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.
Giving in my Facebook that centralized view and extra data… no thanks. Same with Microsoft and google.
Some users, like me, have learned to use the registration form as an account checker for their own email. I don't remember if I have an account on some websites, and if I do I don't remember with which email+password combo, and the password reset page doesn't tell whether the email is correct, and it often takes 10 minutes for them to send a reset email so I still don't know whether I'm registered with the email I entered and should just wait or not registered at all and no email was sent. So instead I just try to register and bam, instant answer.
In addition to that, the context switch to emails increases friction significantly during registration. It's much easier for the user to be logged-in immediately and not have to check their email. That's not even taking into account the wasted time of having to re-enter all your info.
Disclaimer: I know the first issue is solved with a password manager and a faster email service, that's not the point.
Earlier quoted context omitted.
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.
That was presented as an option, but explicitly not recommended. > …you can make the signup process email based.…I don't recommend this, because of the context switches, though you can implement it.
Now, if you have accounts in places where email addresses are not required and usernames take the place, the calculus may change. But using the context switch as an argument here is just weak.