13

When a user registers on a website, he has to confirm e-mail to activate account.

When clicking confirmation link, the user is identified by one-time hash to activate account.

Is it safe to authenticate user right away or should he sign-in by login/password after activating?

Proposed Registration flow:

  1. Fill-in registration form with login/email/password
  2. Confirm e-mail by one-time link with hash
  3. If e-mail confirmed (and account was not activated), authenticate user and grant access to his account

My Current Registration Flow:

  1. Fill-in registration form with login/email/password
  2. Confirm e-mail by one-time link with hash
  3. If properly confirmed, user needs to enter email or login and password

Side notes:

  1. While having access to e-mail, it is possible to reset password
  2. Registration form contains only login/email/password
Community
  • 1
PeterM
  • 241
  • 3
  • 12
  • 1
    It maybe acceptable for registration, but definitely don't allow this for password reset. If the user is effectively logged in without changing the password, a compromised email will grant access to the attacker without the user ever finding out. – billc.cn Oct 04 '16 at 13:48
  • Well, I plan to use it only on account activation to improve user experience. When e-mail is compromised user is anyway in trouble. – PeterM Oct 04 '16 at 14:56

6 Answers6

13

It depends on why you want to confirm an e-mail. If that e-mail will later be used for password reset, the proposed workflow has a major security problem. Consider the following scenario:

  • Alice creates a new account and inadvertantly write Bob's mail (say she copy-paste the mail and uses wrong line)
  • evil Bob sees the mail, confirms the account, writes down Alice's login name if it is different from the e-mail and logs out
  • Alice tries to connect later and sees everything works fine - she assumes validation was automatic and she normally uses her account for a while
  • some times later, Bob tries to connect using Alice's account, asks for a password reset => as he own the registered mail, he is successful in changing the password
  • Bob now owns Alice's account and can do anything on behalf of her!

Ok, Alice was not very cautious when creating her account, but the proposed workflow did not really protect her :-(

That's the reason why my prefered workflow is:

  • let a user create a new account with login, password an e-mail (may be login or not, better not) -> the account is created unactivated and will be destroyed if not activated within a limited period of time (say 2 days)
  • send a unique confimation link to the given mail
  • the link opens a login form - the user name should be pre-filled and read-only. If the user successfully logs in, the account is validated, the link is invalidated and the user is put his session. If the password is incorrect after three attempts the connection is broken.
  • if a user tries to connect using a non validated account, he/she sees a message saying that a validation mail was send to that address, that he/she still has n days/hours to validate the account, and proposing him/her to re-create the account with a new mail address. In that case, the old validation link is immediately invalidated.

If the previous scenario happens, Bob will not be able to validate Alice's account nor to steal her account later.

Serge Ballesta
  • 25,636
  • 4
  • 42
  • 84
  • Why does the user name have to be pre filled and read only? – toogley Oct 15 '16 at 17:09
  • 3
    One semi-concern about this setup: I'm not sure I like conditioning users to think "Okay, sometimes this site will legitimately require me to enter a password on the next screen after I click on a link in an email from them." – mostlyinformed Oct 16 '16 at 19:52
  • What if a user forgot / failed to record their password during those first n days before they validated the email account? Do they lose their account and anything associated with it and have to start over? – Dave L. Feb 08 '20 at 00:46
2

It depends if the registration form contains any sensitive data and if the newly created account may be of any value to a third party (either by itself or by impersonating the legitimate user).

The issue is that if the user made a mistake while typing his email address, the registration link may be sent to an unknown person.

  • In the proposed registration flow, this unknown recipient will have access to the newly created account.
  • In your current registration flow, this link will be nearly useless to this recipient, the only action he can do being "validating" the email address.

The proposed registration flow can therefore bring some usability improvement to the end-user, but at the expense of a potentially slightly weaker security.

WhiteWinterWolf
  • 19,082
  • 4
  • 58
  • 104
  • Added extra information, as having access to e-mail used for registration, password can be reset to new one. – PeterM Oct 04 '16 at 12:41
  • @PeterM: This doesn't fundamentally change my answer. If a new account is empty and doesn't give access to any sensitive information or privilege, then the situation becomes like the account has been created by this other person. On a public forum for instance, the only annoyance could be that the legitimate user will not be able to use its favorite user name but will have to user another one, so no big deal. At the opposite on a banking application, you do not want an unknown person being able to access newly created web access so you have better double-check. – WhiteWinterWolf Oct 04 '16 at 12:49
  • Allright. Just wanted to clarify. – PeterM Oct 04 '16 at 13:21
2

With your "Proposed Registration flow" you are assuming the person that has just made the account is the person that clicks the link. This assumption is generally true and there are people out there that will just take this risk. Afterwards this is an issue of what balance you are looking for between security and usability (quite an interesting debate subject :D).

The bad thing about this is that if your assumption is wrong someone could just log-in and reset the password having full access from now on into the account, even change the email account of the user.

With your "My Current Registration Flow" you have enhanced security while risking to bother the user a little bit by just forcing him to log-in AGAIN even though that is what he just did a few minutes ago.

The way I would do it is that at registration I directly log-in the user while restricting what he can do but opening a session for him. If he wants full functionality than he has to activate his account. After he clicks the one time token link in his email he is redirected to the website where if he has an opened session he will be logged in (having an opened session means that the chances of someone to get hold of his email from the registration till now are lower) otherwise he will have to log back in (meaning his session has expired in the mean time so there are higher chances that this is not my user anymore).

I hope this helped you and I hope I make some kind of sense in what I tried to expose.

The problem that you are stating here is more of whether you minimize security (a little bit) to gain more usability or you find something in between.

Stefan Idriceanu
  • 43
  • 7
1

I would say, it depends.

Everyone knows email is insecure, there are things you can do to email to make it secure but from everything I know very few people use it and it has to be set up on both the sender and receiver's accounts.

As said by @WhiteWinterWolf you are giving access to the account to whoever owns that email. Only yesterday I misstyped my email address and I have had it over 10 years and must have typed it 10,000+ times in that time but still made a mistake. So if it can happen in that situation , it can happen in a lot more situations.

Lastly, how good is your random? Could it be guessed? I dont know what language you are using but there are random functions which are not as random as you think. Are you willing to put all your faith into that random function when you could add a protection?

Also,i know this isn't UX but there isn't much lost in terms of user experience to get them to log in again but as a precaution you could have the email authentication page check for a cookie generated by the registration page, this would indicate that the registration and email authentication was done on the same browser and remove the requirement to log in with that cookie present.

Topher Brink
  • 1,639
  • 11
  • 13
1

The current flow can be considered insecure for the following reasons.

  1. An adversary having (even limited) access to somebody else's email can create, and use an account on behalf of them.
  2. The authentication here is entirely dependent on the security of email. Email, here is the weakest link and with access to it an adversary can gain access.

In the proposed flow, the above issues are mitigated as you are confirming that the person who created the account and the person with access to email are the same.

I have seen certain applications which uses the original flow you mentioned. They consider it an accepted risk limiting the accepted emails to a few domains. Original flow is user-friendly with a slight trade off in security.

hax
  • 3,851
  • 1
  • 16
  • 34
1

Most websites require user to input his password after activating account. Is it even nessesary?

a lot.

If someone can read your e-mails, they cannot take over your account this way, as it depends on a pre-shared secret, the password.

A very good practice.

Similar to requiring a password to do key actions (see GitHub's sudo mode), such as change password. If someone can hijack your session or simply get access to your computer, they cannot do much since they still need the password, which don't weren't provided with.

Samuel Shifterovich
  • 876
  • 9
  • 18