57

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.

11
  • 4
    Great question! I think I've seen it the other way where the Login form is the first page, and if user does not exist then it takes you to the Registration form. – Mike Ounsworth Feb 5 at 13:29
  • 61
    One thing that does come to mind: clearly your users are re-using passwords across websites if they believe they are registering a new account and happen to choose the same password. – Mike Ounsworth Feb 5 at 13:30
  • 9
    While interesting from a security perspective, certainly, this question might be a better fit for User Experience Stack Exchange. – esqew Feb 5 at 14:05
  • 1
    @MikeOunsworth true. Some of our users are non-technical, and don't have a slightest clue about good security practices. However, I don't think we can realistically influence them in this regard, so we just have to deal with it. – Назар Топольський Feb 5 at 14:31
  • 2
    "clearly your users are re-using passwords across websites" / "I don't think we can realistically influence them in this regard" - you could prompt them to change their password if you did allow them to login via the registration form. However, do you have evidence that they are actually entering a valid password? Why is the user "complaining" - it sounds as if there could be other UX issues here? – MrWhite Feb 6 at 13:31
44

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.

9
  • 38
    Personally I'd rather be redirected to the login page with my email prefilled and with a error message (You are already registered, login here). Where I type my password once again. – Anunay Feb 7 at 0:25
  • 6
    @Anunay Useful though this might be, I would be distrustful of any website that provides an oracle that can tell you whether a user is registered or not. Leaking this information to a wider audience via "You are already registered" messages, to me, has a bad smell and exposes information to attackers that they really shouldn't be able to establish. Whether I have an account is between me and the site. Nobody else. – spender Feb 8 at 12:18
  • 9
    @spender, I agree that it can be a privacy issue, but I just tested it here on StackExchange, and if you try to register with an email that has already been used, you are asked "did you forget your password?" instead of completing the registration process. So the vast majority of websites and services allow you to distinguish between registered and unregistered emails. In fact, I even tested it on PornHub, and by entering "john.doe@gmail.com" you get "email has been taken". Oops! – reed Feb 8 at 13:31
  • 3
    @reed Big-oops indeed. I was thinking exactly this kind of scenario (or something like ashley-madison) where this kind of disclosure could have serious repercussions for the user. – spender Feb 8 at 16:09
  • 5
    @Barmar - Not necessarily. A website that requires you to click a link in an email before it actually creates your account could behave exactly the same whether the account exists or not, but send a "you look like you're trying to recover your account" email instead of a "click here to register" email. Either way, the registration form says "Please check your email" – Bobson Feb 8 at 21:08
15

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.

9
  • 5
    Like many sites, we use email for user registration. If somebody tries to input an email that is already in use for the site, we have to report an error - I just don't see other solutions. – Назар Топольський Feb 5 at 15:36
  • 4
    @elsadek The problem is, that an association can be made from the publicly known email to the not generally known association to a website. Please read the OWASP link. – Marcel Feb 5 at 15:49
  • 5
    I don't think this really answers the question. This kind of privacy is of course important in most cases, but it's not really what the OP was asking. – reed Feb 5 at 18:12
  • 23
    @НазарТопольський, if you wanted to avoid leaking email addresses during the registration process, you would have to show the same notice to everybody (for example "An email has been sent to you"), and then communicate all the details (success, fail, help, etc.) in the email you sent (and that only the real owner could read). – reed Feb 5 at 18:15
  • 6
    Exactly; which means sites with open registration should generally either not use e-mail addresses as login identifiers, or not care about account enumeration (which is IMHO quite fine for most sites; yeah, if you are making Ashley Madison, you are an exception). Doing complex registration process with e-mail verification as the first step? Yeah, theoretically possible, but terrible, UX-wise, for no great security gain in most cases. – Mormegil Feb 7 at 14:11
8

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.

5

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.

4

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.

1

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).

0

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.

-2

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.

1
  • You could easily enumerate a bunch of email addresses even if you included a captcha with these type of services deathbycaptcha.com – Kevin Smith May 22 at 9:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.