Should I log users in if they enter valid login info in registration form?

Question

Recently, we've had users complain that they forget that they have an account, try registering, and get error message that the user with such email already exists. There is a proposal to just log them in such cases. So, if the user inputs valid login info into registration form, they are just logged in instead. Obviously, if the password isn't correct, user will not be logged in.

What are the security implications of such approach? If the attacker already knows login and password, they will be able to log in normally anyway. Most sites don't have this behaviour, and my gut reaction is that this is not a good practice, but I can't articulate any specific objections.

Answer 1

Unless other authentication methods are involved (for example 2FA, etc.), if a correct email and the corresponding password are sufficient and necessary to log you in, then I see no security issues. The reason is simple: the authentication and authorization process doesn't change. However, if for example 2FA has been enabled for an account and the second factor is necessary in order to log in, if you allow users to login from a registration form that only accepts email and password, you will introduce a weakness (because it will be possible to bypass the second factor from the registration form), unless of course you also check the second factor right after the registration of an existing user with 2FA enabled. This might make your app more complicate.

That said, I believe what you proposed is generally a bad choice for UX (User Experience) anyway. What happens if there are other fields in the registration form, and the new data is different from what is already saved in the account? Think of a phone number, for example. Are you going to update it in the profile automatically without a warning? Are you updating it with a notice? Or will you discard it? This problem will introduce steps and choices that will make everything more complicated, both for you (and your code) and for the final user. Also you will have to distinguish between users that already have an account but entered a wrong password, and users that already have an account and entered the correct original password. You can't just log them in without a notice, because their experience is going to be different (a new account will not behave in the same way as an established account, and will have different data and settings). Unless the users understand what you are doing, some of them might even wonder if there's a bug in your software and think: "Did it just let me log in because I used the right password, or would anybody be able to log in to my account with this registration process?".

So, as I said, I believe that this is going to complicate things both for you (and your code) and for the user. If you have huge registration forms and you want to avoid that users waste a lot of time when registering if they already have an account, then make sure you check their email address right away, in the first steps of the registration process, or in the background via AJAX, so the user will discover they already have an account before they start filling in all the fields.

Answer 2

From a security perspective, you should not disclose to visitor, that an account under a given name already exists.

By doing so, your users are prone to the account enumeration attack.

Depending on the kind of your website, this may disclose unwanted associations for your users. Think Asley Madison, where users were exploited by testing their public email addresses.

To mitigate, you may want to use arbitrary usernames, or have a registration form with some kind of captcha to at least discourage automation.

Answer 3

So, if the user inputs valid login info into registration form, they are just logged in instead. Obviously, if the password isn't correct, user will not be logged in.

From legitimate user perspective, this could bring confusion unless he is alerted upon successful login.
However by allowing login through registration form, the attack surface become wider, so you have to apply the same security control that exists in the login process.

Answer 4

Some services (Slack, I think?) do something similar, which may be more user-friendly: when a user registers, a registration email is always sent to their mailbox, regardless if the email is linked to an account or not.

The difference is that a new user receives a regular "please activate your account" email, while an existing user receives a message of "we got a registration request for this email, if this was you please log in here" type. Perhaps you can automatically add a short-lived "Reset your password" link to such an e-mail to help them reacquire their accounts.

This way user gets the regular "registration experience" (fill in a form, go to email, click a link, log in) in both cases, while not disclosing whether an account for a given email exists or not (only address owner gets this information, not everybody who tries to create an account). It is slightly more complex when the user forgot the password and needs to restore their account (going to mailbox twice), but it's also a fairly typical flow, so it shouldn't cause much confusion.

While your proposition does not add any security risk, this flow removes client email disclosure that you may have in your registration form.

Answer 5

From a UX perspective, logging users in automatically might be as confusing as it is annoying to have to re-enter their credentials.

From a security standpoint, obviously you're revealing that the email address is valid, but that is trivial to find out anyway – by trying the normal and valid new-user registration process and failing because of an 'email adress is already in use' error.

To untie the knot

• make the distinction between registration and login more obvious.
• or log them in and show a short pop-up saying 'we already know you and have logged you in.'
• Ask them for their username first, without showing the password prompt. That is normal for 2FA anyway (in case it is enabled, the user has to provide the token.) This would give you a chance to step into the registration process with 'this email adress is already in use. Do you want to log in instead?' Provide a link to the log in form and prefill the email adress input.

Also note that, as @Mike Ounsworth pointed out in a comment, users that 'just so happen' to guess their password right even though they don't remember your site are certainly reusing this password.

Answer 6

Various comments refer to the UX - without distinguishing two very different types of users: those mistaking the new user registration form for the existing user login form (something I've definitely done in the past - it happens especially if the new user form looks like the login form (i.e., doesn't ask for any info other than email and password in the first step, and doesn't ask to repeat the password) and is the default form) and those trying to register anew. I'd argue that the answer to the original question might be different depending on which situation you are dealing with. So if for some good reason your website is designed in a way that many users mix up login and registration forms, and if additionally you believe to recognise the user's device, I see a strong case for logging in right away. And if it is evident that the customer tries to register a second time (e.g., enters the password twice and also completes other fields such as name), the email solution suggested above is great, and you may even add a warning about re-using passwords (extra kudos for giving feedback on the strength of the password and suggesting 2-3 methods for conveniently creating and using stronger passwords).

Answer 7

First of all, I'd make sure that the initial registration form only requires e-mail and password filled in (and potentially, a captcha). Upon submitting, user gets the confirmation e-mail with a link to continue the registration process and fill in the rest of the data.

If they already have an account, registration confirmation e-mail can let them know they can log in with their old credentials and/or optionally offer to reset their old password to the one they used to register with.

This way, you can prevent account enumeration with minimal inconvenience to the end-user.

Answer 8

In the new user creation form, the first field you ask them for should be their email address.

Use javascript to asynchronously check if there's already an account with that address.

Mitigate account enumeration with a captcha. Maybe the captcha should be first if it has to be manually completed.

If the email's already taken, the user should get a popup "Looks like there's already an account with that address." with two buttons "Log in instead" or "Forgot password".

Clicking 'Log in' should pre-fill the email address field for the user, so all they need to do then is provide password to log in.

Clicking 'Forgot' should send a one-time, time-limited link to the email address, which can be used to reset password.

Having 2fa complicates this of course., and any password reset sequence would need to incorporate a lost 2nd factor procedure.