57

Someone came up with this proposed behavior recently and I haven't been able to find examples of services working the same way. I have to say I don't really like it, but can't put my finger on a precise reason.

It would work like this. We have a user in dB with:

The user goes to example.com/sign_up and signs up with:

  • Email: "[email protected]"
  • Password: "12345678" (we might ask for a password confirmation)

What we're doing now in this case is letting the user know there's a conflict; there's an account with that same email.

But since the user entered valid credentials, would it make any sense to authenticate him/her?

Edit: I don't think my question covers the same situation discussed here. These are not two different users with just the same email, it's one single user registering with the same credentials (both email and password) he/she used at an earlier time. What we usually see in this case is an unsuccessful registration attempt. The proposed behavior here is to check the credentials against the authentication and, if they work, simply log the user in.

As I said earlier, I've never seen this done and I don't like it myself. Some of the answers are giving very valid insight as to why it seems to be a bad idea.

Improve this question
15
  • 3
    On multiple accounts with same email: ux.stackexchange.com/questions/74777/…
    – locationunknown
    May 19, 2015 at 9:08
  • 1
    Can you please clarify if the question is about registering as a new user, or logging in as en existing user?
    – Bart Gijssens
    May 19, 2015 at 9:42
  • 2
    I often wish amazon did it this way. For a lot of actions you get redirected to a login page where there are email/password fields and a radio button "want to register" and "already have account". Default is "want to register" but I almost always forget to change it and then get "there is already an acount" click back, switch the radio button and log in...
    – PlasmaHH
    May 19, 2015 at 12:13
  • 3
    tumblr does this... I think it's really handy, as it takes you to the sign up page by default. This allows you to log in without navigating to the login page first...
    – Shadow
    May 21, 2015 at 4:38
  • 4
    It's worth noting that Stack Exchange does exactly this. If you're not logged in to a site, and try to sign up with existing credentials, it just logs you in.
    – Bobson
    May 22, 2015 at 12:08

11 Answers 11

Reset to default
51

So basically you want someone who signs up for a new account and enters already existing credentials, to log in as the owner of these credentials?

I wouldn't recommend this:

  1. The chance that the person signing up is not the owner of the existing account may be small, it is still possible.
  2. The difference between signing up and logging in should be clear.
  3. A user might forget it already has an account. Informing that an account with that e-mail address already exists is better than just logging in, which would be unexpected behavior and really confusing.
Improve this answer
10
  • 5
    Surely the chance that the person signing up is not the owner of the existing account is essentially zero if email addresses are used as the username as in OP's example.
    – Kit Grose
    May 19, 2015 at 10:27
  • 29
    I can only see two scenarios that wouldn't be legitimate: a user enters a typo that happens to correspond to another account and a hacker. In both cases, the same exact problem would apply to the existing login form. I see that it would be necessary to harden the sign up form in the same way as the login form if it's able to serve the dual purposes, but I don't accept that it invalidates the idea outright.
    – Kit Grose
    May 19, 2015 at 10:52
  • 4
    I think the edit to the question invalidates this answer. It's now explicitly about when the username/email and password match. And if you're signing up with the same email and password, then you can just log in with them...
    – Bobson
    May 19, 2015 at 17:39
  • 5
    The chance that the person signing up is not the owner of the existing account may be small This chance isn't just small, it's equal to the chance of someone guessing the login credentials of another user. If a user uses "password" for a password, not having the OP's suggested functionality isn't going to protect that from having their account jacked.
    – Mar
    May 19, 2015 at 22:29
  • 4
    wrt #3, how would you feel about an interstitial along the lines of "We found your existing account and you will now be logged in" ? It doesn't have to happen silently and surprisingly.
    – Ben Voigt
    May 19, 2015 at 22:53
43

Yes, log the user in

There are several ways an existing user might end up on a sign-up page:

  • User clicks sign up by mistake
  • User recently signed up for an account and the browser URL autocomplete takes user back to that URL (most recent)
  • User forgot they signed up previously and is attempting to sign up again (and, like many users, ill-advisedly uses the same password on all sites)

  • Site landing page contains a sign up form and the user starts filling the form out (or browser credentials autocomplete fills out the form)

    • eg the default landing page for github.com has a signup form, and existing users who enter their email and password can log in via the sign up form:

      github homme page

Assuming that, like most sites, you don't allow multiple accounts with one email, then the user has provided you with valid login credentials so unless there is a non-ux reason (eg security concerns) it's okay to log the user in.

From the design perspective this is called interpolating user intent...you are making an informed guess as to what the user actually intends to do with the UX (in this case, by assuming that the user's ultimate goal is to access the site and signin/signup is just a means to that end) .

An example of interpolating user intent:

google search

Improve this answer
11
  • 2
    Your example is just showing a suggestion without leaving the page, but logging in on an assumption will take the user to an unexpected page.
    – jazZRo
    May 20, 2015 at 6:21
  • 7
    +1 for a well reasoned argument and because as a user this is what I want to happen. The theme of having the registration form on the homepage and a link to log in sometimes leads me to try and login using the register form. It's annoying to have to type out details twice... I would expect a notification if this happens though, to avoid confusion.
    – Matt
    May 20, 2015 at 12:19
  • @jazZRo the point of interpolation is a proper understanding of user needs. In this case, it's most likely that the core user goal is to access the site. So if the user has already signed up before, then logging the user in fulfills that primary need. The user will be satisfied, not dissatisfied that she is now logged in. As a secondary matter it can help to inform the user that she has been logged into her account via a toast or top-of-page notice, but that is a secondary and not a primary need.
    – tohster
    May 20, 2015 at 12:29
  • 1
    @tohster The core goal is not to access the site but actually use it. How can you guarrantee that a user wants to use that old account that he/she forgot about? Wouldn’t it be far more thoughtful to just ask if they want to use that old account?
    – jazZRo
    May 20, 2015 at 13:12
  • 1
    As another example, tumblr.com does this too.
    – Riking
    May 23, 2015 at 23:57
35

NO.

There are chances that user might have no idea about their registration status on the site. And start a fresh registration.

In such a case, best solution would be to OFFER a way to login by inline validation. Before the user reaches the password field, the validation should suggest ways to login as the email is present in database. But, since its not SURE, provide links to login or retrieve the password.

An illustration:

enter image description here

Improve this answer
14
  • 11
    The problem with this is that you are telling potential hackers that "[email protected]" is a valid user on the system. They can they go about trying to guess/social engineer the password.
    – ChrisF
    May 19, 2015 at 11:20
  • 14
    Informing user, who is registering, that this email already exists is a common use case. Even after showing this information, the account is not exposed. Yes a possible hint is given. But then, it depends on strength of password.
    – Prashant Dubey
    May 19, 2015 at 11:34
  • 12
    @ChrisF - It's a valid concern, but not necessarily one that needs to be addressed. It very much depends on the type of site in question and how much is at risk. If it's for a bank, it's a very different scenario than if it's a cat picture forum. It also depends on whether it's email addresses or usernames in question.
    – Bobson
    May 19, 2015 at 17:37
  • 6
    You can't avoiding telling someone sooner or later that they can't register an account because it already exists. The tricky bit is deciding when to tell them -- too soon and it allows testing for the existence of many accounts easily, too late and it's potentially bad UX as the user has to go through right through registration before finding out.
    – Chris H
    May 20, 2015 at 10:36
  • 2
    @Bobson Banks usually require other identifiers than just an email address to sign up for their services!
    – jwg
    May 20, 2015 at 11:05
30

I disagree with the other answers, and say yes, it may make sense (with a couple of caveats).

There is an increasing prevalence of the combined login/sign up form pattern on some sites, where the whole sign up form is simply email address and password, and all more substantive profile questions become an optional step after registration. This pattern dramatically lowers the barrier to entry for a site for new users.

If you apply this pattern, I think it does make sense to simply log the user in if they enter their credentials and happen to click the wrong button (provided the password was correct). The only problem I can see arises when the password doesn't match, and so your error message should be tailored to the action the user ostensibly requested (that is "that account could not be registered because an account already exists for your email address" as opposed to "invalid password" if the user clicked "Register New Account" but specified a different password).

All that seems like a pretty beneficial process from where I'm sitting, helping the user achieve their goal (accessing the site's restricted features) easily, but it is unusual and so you'd probably benefit from user testing this feature.

Worst case scenario, you could take a hybrid approach: present the conventional error screen ("An account with your email address already exists") and extend it with a link saying something like "Would you like to sign in now?"

Improve this answer
2
  • What is there to prevent a person from fishing your user's e-mails by guessing at the login? the more substantive profile questions are often a required step (or at least a captcha or something else to slow down any automated attempts), and will occur before the email is actually checked as available first in a properly secured system.
    – user2813274
    May 20, 2015 at 13:20
  • 1
    user2813274 Brute forcing email addresses to find out who is a user of the site is fairly unconcerning, most of the time.
    – Frames Catherine White
    May 21, 2015 at 23:48
5

I would not recommend that. Signing up screen should inform visitor that a certain email is already registered. When you inform the user about that, he/she takes a step back to remember when and what he/she did that. This helps him/her get into context about the last visit to this site.

Your website should comply to user's mental model. I do not think every user will welcome system taking this proactive step of automatically logging the person in. It also helps create a different, not intentional workflow, which I would discourage.

Furthermore, many sites restrict login attempts on their login page. If you allow logging in via sign up pages, you would invite brute force attacks, and you'd have to put the restrictions on the sign up pages too. That is an overkill.

You can think of asking the user in a friendly note, that this email address is registered, do you want to log in instead?(then take him/her to login page) Or this email is already registered, have you forgotten a password?

Improve this answer
4
  • 4
    For what it's worth, you almost certainly should prevent many consecutive hits to a sign up form. There's no legitimate reason for a user to hit that page hundreds of times any more than there is for a user trying different passwords on the login screen.
    – Kit Grose
    May 19, 2015 at 10:29
  • 2
    "When you inform the user about that, he/she takes a step back to remember when and what he/she did that." I'm probably not your average user, but I would go "well then log me in already?". I have a gazillion accounts from sites that stupidly require me to register to download a file or so, and oftentimes I already have an account. And sometimes I rediscover services without realizing, try to register, and then have to fill in my credentials again on the login page because, indeed, the site goes "Hey we already know an identical user but we still don't log you in!"
    – Luc
    May 20, 2015 at 12:57
  • @KitGrose How would one measure "many consecutive hits" by "a user"? By cookies, with a false negative from clients who clear their cookies? By IP address, with a false positive from multiple users behind a big NAT?
    – Damian Yerrick
    May 21, 2015 at 20:57
  • @tepples while I think the answer to that is well and truly a security question, you'd normally use IP. The idea as I understand it is to throttle requests from a single IP (by a few seconds) such that a regular human user is mildly affected but a bot trying many consecutive requests is substantially slowed down, preventing brute force attacks from being viable. Can't use cookies for this; client side protections can be thwarted trivially by a malicious hacker.
    – Kit Grose
    May 21, 2015 at 22:57
3

Absolutely Not

Login attempts lock after a few attempts (or they better, otherwise an attacker could break in trying the top 100 likely passwords), at least for a few minutes. Users would be very confused, I think, if registration screens locked after a few attempts, and by not logging them in, you give the attacker a clue that they password was wrong, so they can try those top 100 passwords and break into other people's accounts.

The best you can do is to tell the user that the username is already registered. That does tell an attacker more information than one would want to, but there isn't a choice. For a good user experience, if you could tell the user that as soon as they move off the username field (before they type in the password), that would be nice.

I also suggest posting this question to the security experts. You always want to understand how much security you are giving up for the sake of a better user experience.

Improve this answer
1
  • You've just suggested a very big security hole: if sign-up form doesn't locks up EXACTLY in same way as login form and responds with "already registered" - that becomes perfect way to quickly harvest valid logins.
    – Oleg V. Volkov
    May 26, 2015 at 1:49
2

I would say no, do not login eventhough all the credentials are identical.

Eventhough it would seem logical to login because all the credentials are identical, it will as mentioned above cause confusion.

I would just say give them a notification about the username/email is already in use.

If you want to login the user, I'd say work with cookies?

Improve this answer
1

No.

Irrespective of the fact that you may want to use something other than the e-mail address to uniquely identify a user (such as a separate user ID), no 2 different users can have the same e-mail address. Period.

If a user registers with an e-mail address that is already known by you, you may want to direct him/her to the "forgot password" functionality, or have him fill in another e-mail address.

There is no good use case in allowing 2 users to register with the same e-mail address.

Improve this answer
6
  • 1
    That wouldn't be the case, we'd be checking the password the user enters and only logging him/her in if it matches. Weird, I know :/
    – raul2010
    May 19, 2015 at 9:21
  • That's bad practice. First I hope you are not storing the password itself (which is forbidden), but rather a hash which you will check for a match. Mind that multiple passwords may end up with the same hash. So hashes are not unique, so to WHICH account will you login if the hashes match?
    – Bart Gijssens
    May 19, 2015 at 9:34
  • 1
    We are obviously not storing passwords in plaintext :) And I guess your point is valid, but it would apply to the sign in form as well, wouldn't it?
    – raul2010
    May 19, 2015 at 9:37
  • It's not clear whether your question is about registering as a new user, or logging in as an existing user.
    – Bart Gijssens
    May 19, 2015 at 9:41
  • 3
    It's basically logging in an existing user when he incorrectly enters valid credentials on the sign up page. Added further clarification on the question, hope it's clearer now.
    – raul2010
    May 19, 2015 at 10:28
1

No, because you just doubled the attack surface.

Request the user enter an identifier. Atomically check if the identifier already has credentials. If so, offer three choices:

  1. Go to login form
  2. Go to forgotten credentials form
  3. Resubmit a new identifier

Same effect as you proposed, but the login barrier remains in exactly one place. Being in one place, there is less code to vet for security.

Improve this answer
5
  • The behaviour suggested only happens if the users enters both the right username and the right password, so it doesn't double the attack surface.
    – Flimm
    May 22, 2015 at 8:16
  • @Flimm Perhaps I wasn't clear. There is a login form with URL X. That is one attack surface. There is a registration form with URL Y. That is another attack surface. I'll give benefit of the doubt and say that both forms go through the same code (but I've seen plenty of cases where that is not true). Even with this benefit, the two URL will require a more complex IDS monitoring setup, which is a non-trivial cost. Basically, it's easiest to ensure proper access when there is only one gate.
    – bishop
    May 22, 2015 at 14:38
  • How did you "double" any attack surface if you perform exactly same checks on both sign-up and login form with same throttle counters?
    – Oleg V. Volkov
    May 26, 2015 at 1:47
  • @OlegV.Volkov Assuming every bit of code is identical, all throttling is shared, and any IDS setup tallies both in same bucket, then the doubling is only apparent. In reality, I doubt all of these assumptions are met, so the increased area is reality.
    – bishop
    May 26, 2015 at 2:18
  • @bishop, as I've commented on another answer, if signup form itself doesn't have same throttling as login, then it is a already a big hole allowing to quickly harvest valid logins through analyzing "already registered" responses. You'd basically just expand already existing security hole that should be fixed in the first place.
    – Oleg V. Volkov
    May 26, 2015 at 6:06
0

Yes and no.

You should let the user know that the email already has an account associated with. They should then be able to switch to login without retyping anything. The God Login Shows this well, Using just email and password fields while having multiple buttons for the different actions.

Hiding the signup button on the login page, is also acceptable as long as it appears if the users details are not already stored making it a super simple action to then signup.

Improve this answer
0

No, you should not authenticate the user. You should prompt the user that already there's an account with the e-mail Id and you can also help the user to go to the log in section to sign in. If you want you can pre-fill the E-mail ID field, but the user should give password again to verify and enter specifically from the log in section.

Also, I always disliked the idea that a sign up form with only two fields- email and password. Keep at least three fields like name or username along with email and password to make it more look like a sign up form. I have seen few companies(some of them are big), doing this, and I have stumbled multiple times there. So, if you are planning that too, you should re-consider.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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