I am designing a new login/register process for a system and want to combine the 2 initial pages for register and login.

This would be one page where the user would enter their email and press 'Continue'. We would then check if the email is recognised or not, if it is recognised then we would push the user to an 'Enter password' page and if not then it would push them to a 'Register' page.

Are there any security issues with this? Obviously you'd be able to enter a bunch of emails and check whether or not they are registered on our system but is that a problem? We have 2FA for registered accounts as well as complex password policies.

  • This is a good question and I have also seen this fairly often. I wonder if a more secure approach would be to: 1. ask for an email 2. Use local storage/cookie if they've logged in previously to dynamically get them a password field 3. If there is no local storage/cookie telling you they've logged in before, then inform them that if their email address was found to have an account then they were sent an email (and of course send an email) 4. Tell them that if they didn't receive an email then click on the Register button below...
    – MER
    Commented May 23 at 1:28
  • 4
    On login pages Jeff Atwood says to “Tell the user when their email doesn't exist” for a better user experience Commented May 23 at 3:23
  • 2
    For what it's worth, there's already the reverse question, where the register becomes login: security.stackexchange.com/questions/134198/…. Despite being the reverse flow, it's got the same vulnerabilities.
    – Bobson
    Commented May 23 at 13:16
  • Having two separate pages makes it much easier to present different workflows for the second page. Commented May 24 at 14:25
  • 1
    It's not a security concern, but this setup is terrible from a usability perspective. Now to login I have to go through two separate page loads, and password managers often have trouble with this setup if the fields aren't tagged correctly. Commented May 24 at 20:23

3 Answers 3


Obviously you'd be able to enter a bunch of emails and check whether or not they are registered on our system but is that a problem? We have 2FA for registered accounts as well as complex password policies.

2FA and complex passwords will not help against leakage of accounts existence, only against logging in with these accounts. The information that a specific email has an account with your site can be valuable depending on what kind of site this is.

Apart from that not being clear up-front about what the user can expect (i.e. login or registration) is a usability problem. One cannot expect that all users remember exactly if they have an account with the site and what the exact email was they've used for registration (many users have multiple emails).

If the user expects to login they will be confused if you ask them to register instead of notifying that the account does not exist. If the user expects to register they will treat your question for a password as the one used in registration and then will be confused if you tell them that the password is wrong (since the login failed).

Even sites which ask for the email and then offer both a "login" and "register" button on the same page are too confusing for users and they'll regularly click the wrong one.

  • 3
    It's even more fun in German, where "anmelden" can mean both "log in" and "sign up", and is used by different websites for either. Commented May 23 at 12:04
  • 2
    "One cannot expect that all users remember exactly if they have an account with the site" seems to me to be in argument in favour of the integrated automatic login/register as proposed by OP rather than against it.
    – jcaron
    Commented May 23 at 15:25
  • 2
    @jcaron: Not remembering exactly does not mean that the user has no clue, but that they might get it wrong (maybe registered at similar site, maybe registered here but with different email, ...). In this case the wrong thing will happen for the user: they might think they register but then get the information that the password is wrong - since they already had an account but with a different password. Or they think they login (but use the wrong email) and enter the password - but end up with a new registration instead. Not informing the user what actually will happen is bad usability. Commented May 23 at 16:31
  • You left out the significant impact on the site of a directory harvest attack, which will happen. OP would be wise to include CAPTCHA and/or some kind of throttling to their login and registration pages. Commented May 25 at 18:56

Allowing anybody to check whether a particular e-mail address is registered at your site is both a privacy and a security issue. The privacy impact of this information of course depends on how sensitive the website content is. As to security, this is a case of Account Discovery. You're allowing an attacker to find valid accounts and possibly try to gain access in the next step. This doesn't have to happen through obvious methods like a brute-force attack. The attacker may also use phishing, in which case 2FA and strict password rules don't help much.

So from a security perspective, the pages should be separated. Also make sure you're not exposing any account information on the registration page. Instead of checking whether the account is already registered and showing the result on a website, send out an e-mail: If the address is new, link the user to the usual registration procedure. If the address has already been used, point this out in the e-mail -- and allow the user to reset their password if they no longer remember it.

  • 1
    Thank you for this information it's very helpful. How do sites get away with it then? As I've seen several use cases e.g. link - Also would some form of recaptcha help?
    – Ollie
    Commented May 22 at 13:00
  • 2
    "How do sites get away with it then?" They are not breaking any law, it's just bad practice, on top of unnecessary information disclosure. Recaptcha is a possible strategy, but should preferably triggered only after a couple unsuccessful attempts have been made. Because captcha is irritating and poses accessibility issues.
    – Kate
    Commented May 22 at 14:56
  • 1
    @Ollie: Unfortunately, account enumeration is often overlooked, either because website owners don't know any better, or because they don't care. It's definitely bad pratice. CAPTCHAs can slow an attacker down, but they cannot solve the underlying problem.
    – Ja1024
    Commented May 22 at 16:26
  • 4
    @Kate They may be breaking a law, depending on jurisdiction... you're leaking private information held about your customers (namely, that they're your customers), and that's going to run afoul of GDPR and others. It's more accurate to say that sites get away with it because few people make enough noise to get the problem fixed. Commented May 23 at 2:47
  • 1
    @Barmar: See my suggestion in the second paragraph. The application should send an e-mail in both cases: If the address is already registered (which means the owner of the mailbox already has an account), say that in the e-mail. If the address hasn't been registered yet, also say that in the e-mail and let the user go through the usual registration procedure.
    – Ja1024
    Commented May 23 at 15:12

You've defined your threat model as:

An attacker gaining a list of registered users in your system.

Irrespective of your UX/UI decision to combine login/register into one page or keep them separate, you have to not provide any clues as to whether a specific username (usually email) is already taken.

So, how do you balance telling a legitimate user that their desired username is in-use and not revealing such info to an attacker?

Here is a sample flow assuming login/registration is a single starting point and their username is their email:

  • If username/password match
    • Log them in
  • If username does not exist or username/password does not match
    • Generic message telling them the login failed and should expect an email. And if they don't have an account then they should follow the registration procedure in the email
    • Send an email to the user
      • The email will reveal to the end-user the cause of the failure such as:
        • It seems you failed to login at {My site}, you have 5 more login attempts, or feel free to reset your password here. If you did not initiate this login attempt then let us know immediately because it's possible someone is trying to log in to your account.
        • Thank you for choosing {My site}! To finish registration click this URL with a unique ID in it. If you did not initiate this registration then someone may be trying to register using your email. Do NOT ever share this registration link with anyone!

Also consider rate-limiting the login/registration form so that you don't accidentally blacklist your server from sending emails.

If you don't wish to rely on unreliable email for this communication then you have to perform profiling of the user and deduce whether you think this is an attacker interacting with your login/registration form or a legitimate user; think reCaptcha.

  • I’m confused about the email. How does the system know what email to send to for unregistered users? Also why have an email sent at all? Also getting an email every time I mistype my password would annoy me so much. Commented May 25 at 18:53
  • @ToddWilcox Given OP's threat model, assume the system uses email as the username.
    – MonkeyZeus
    Commented May 26 at 7:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .