58

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.

Назар Топольський
  • 689
  • 3
  • 4
  • 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 05 '21 at 13:29
  • 63
    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 05 '21 at 13:30
  • 9
    While interesting from a security perspective, certainly, this question might be a better fit for [User Experience Stack Exchange](https://ux.stackexchange.com). – esqew Feb 05 '21 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 05 '21 at 14:31
  • 1
    @esqew while there definitely is a UX side to this question, the security concern is a lot less clear, at least to me. UX issues can be worked around a lot easier than security holes. – Назар Топольський Feb 05 '21 at 14:35
  • @MikeOunsworth Or using a stateless password generator. Which is not ideal, but slightly better. – gronostaj Feb 06 '21 at 12:44
  • 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 06 '21 at 13:31
  • 1
    As pointed out in reed's answer, there _likely_ isn't a security concern, but taking this approach will complicate your application logic. What you might consider instead is performing immediate validation on the email input to check uniqueness (rather than waiting until the user submits) (and maybe include a link like "Is this you? Click here to sign in." and redirect to login with email pre-populated). Then putting the email field toward the top of the form (ideally first) would prevent the user from having to fill out the rest of the form before discovering they already have an account. – Henry Woody Feb 08 '21 at 02:29
  • @MikeOunsworth and that is the website's problem because? And what would you do about it? – user253751 Feb 08 '21 at 09:35
  • @user253751 MFA is probably the best thing the site could do. Could also consider having password rules that are a bit weird, like _two_ numbers and _two_ symbols which would make most people's default password not work (I hate arbitrary composition rules btw, but it is an option). I'm not saying that it's the website's problem, but there are things the site designer can do, and it's worth recognizing that the site has a non-technical userbase because it may or may not affect design. – Mike Ounsworth Feb 08 '21 at 15:57
  • My wife had this recently with a UK bank. Historically we had a saver account with them and then closed it, deleting all IT records. We opened a new on-line saver account but couldn't check anything because they said we already had a login (but we had no records). Took 6 weeks to gain access because they are 'protecting our money'. Lost 16% of the benefit of the savings account! Make sure the alternate routes to verification actually work, and work well! – Philip Oakley May 26 '21 at 10:42
  • @MikeOunsworth Its not necessary that they are using the same passwords across all websites. I personally have an algorithm to generate passwords on the fly based on the website's name. For instance one such algorithm would be ` `. For instance, in case of stackexchange, the password according to this algorithm would be `sTe_#ILovePizza12!!`. In case of gmail, it'd be `gMl_#ILovePizza12!!`. OTOH, if someone has such an algorithm, they are unlikely to forget it in the first place. – Anmol Singh Jaggi Jun 28 '21 at 08:54

8 Answers8

45

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.

reed
  • 15,398
  • 6
  • 43
  • 64
  • 39
    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 07 '21 at 00: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 08 '21 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 08 '21 at 13:31
  • 3
    @reed Big-oops indeed. I was thinking exactly this kind of scenario (or something like [ashley-madison](https://en.wikipedia.org/wiki/Ashley_Madison#Data_breach)) where this kind of disclosure could have serious repercussions for the user. – spender Feb 08 '21 at 16:09
  • 2
    @spender The information is going to be disclosed anyway. If you try to register with an existing username, it's going to fail and tell you that the username is not available. So the only question is whether it tells you upfront or after you've already gone through the registration form. Many sites tell you at the end, and then offer some alternative usernames. But if the site uses your email as the username, this is not appropriate. – Barmar Feb 08 '21 at 16:19
  • 6
    @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 08 '21 at 21:08
  • 2
    @Bobson Agree and I've seen some sites do that, even when resetting password they'll say "Well send you a email if you have a account with us" – Anunay Feb 09 '21 at 01:20
  • @Bobson That doesn’t change anything, really, just moves the exposure down a step. The entity inputting the e-mail address in the registration form will still eventually be informed whether an account with that address already exists or not. This may be a security flaw, but it is _unavoidable_. If the user name is already taken and cannot be reused, then there is no way for the registration to complete successfully, and that failure _in itself_ lets the user know that the account exists, unless a completely generic “Registration failed” message is used (which would be horrendous UX). – Janus Bahs Jacquet May 26 '21 at 08:31
  • 1
    @JanusBahsJacquet - I think it's possible, but only if username _is_ the email address. Consider: You enter an email and password. If you're right you log in. If not, you're taken to a registration/forgot password screen. You enter the email address again. It says "Check the email we just sent to continue". If it's a new email, it's a "click to set a password" email. If it's an existing one, it's a "click to reset a password" email. The only way to tell if the account exists or not is to have access to _that_ email address. Once usernames can be paired with an arbitrary email, that breaks. – Bobson May 26 '21 at 22:46
16

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.

Marcel
  • 3,494
  • 1
  • 18
  • 35
  • 3
    Nowadays account name is the email of the user, so disclosure is not relevant for email address which is publicly known. – elsadek Feb 05 '21 at 15:06
  • 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 05 '21 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 05 '21 at 15:49
  • @Marcel I looked through the OWASP link. It seems to me like it's only relevant to login. However, I don't see how it would be applicable to registration process, which is the issue discussed here. What should happen if the user tries to apply with an email address/login that's already in use? – Назар Топольський Feb 05 '21 at 16:56
  • @Marcel without looking at the OWASP link, the point you made is clear, but the association will not always create a privacy issue. – elsadek Feb 05 '21 at 17:29
  • 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 05 '21 at 18:12
  • 25
    @НазарТопольський, 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 05 '21 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 07 '21 at 14:11
  • 1
    @НазарТопольський Require users to create a username, and login through that, but require a unique email address to register an account in the first place. That way, external users won't know either the username or the password associated with the email address even if they attempt to register w/ an existing email address. – TylerH May 20 '21 at 20:26
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.

elsadek
  • 1,782
  • 2
  • 17
  • 53
6

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.

Tomasz Lewowski
  • 161
  • 2
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.

knallfrosch
  • 857
  • 5
  • 6
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).

Tobi
  • 11
  • 1
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.

Unglückspilz
  • 101
  • 2
-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.

Billy left SE for Codidact
  • 147
  • 4
  • You could easily enumerate a bunch of email addresses even if you included a captcha with these type of services https://www.deathbycaptcha.com/ – Kevin Smith May 22 '21 at 09:57