A typical account creation process seems to be:

  1. Provide email address and set a password
  2. Receive confirmation email with a link and/or hashed token
  3. Click the link to verify and/or enter the token on the site

However, I once read somewhere (and I can't find this now, which is why I'm asking) that a better process would modify Step 3 to also require the user to login using the password provided in Step 1. I think the rationale was that this extra precaution ensures that the person verifying the email address is the same person who created the account.

Question: does the above explanation make sense, and should I implement email verification by requiring password-based login?

It makes some sense to me, and at least it doesn't seem harmful -- other than making the user experience slightly more cumbersome. But I see many online services that do not require this, and I wonder why.

For example, here's the scenario I worry about. What if person #1 initially created the account but specified the wrong email address (maliciously or accidentally), and it got sent to person #2. If person #2 is naive, he/she might verify that email address by just clicking the link... and then forget about it. Then person #1 could still login using the password. Suppose person #1 does all sorts of bad stuff on that account. Would person #2 be responsible?

I think an alternative solution might be to ask new users to first specify just an email address, then confirm that with a hashed token, and then ask them to set a password. But I don't see very many online services that do it this way, either.

  • 2
    Yes, it should be done. Otherwise the wrong person could just reset password to takeover a new account. But then, some accounts have little value, so it is usability vs security kind of risk assessment. As for bad stuff, the usual way is to track by IP address, not email address. Oct 26, 2014 at 3:53
  • @QuestionOverflow An email verification algorithm should only allow the link that is sent to be used for a particular amount of time (like 24 hours) and it should use a hash algorithm to prevent reverse engineering (and thus, keep the brute force time long enough to ward off such attacks. Feb 5, 2017 at 3:49

4 Answers 4


You certainly should authenticate the user who clicks the link. Otherwise, as you say, someone could inadvertently confirm an email address. However, it is usually possible to authenticate the user transparently, so they don't need to enter their password.

The way we achieve this is using a session cookie. During the signup process, the new user is issued a session cookie. When they click the confirmation link in the email, they will usually use the same browser, so the session cookie will be attached. The web site can verify the user's identity using that cookie.

  • 1
    Thanks for the confirmation. Using a session cookie sounds like a great way to make the process smooth in the common case, and yet it can still fall back to password authentication in other cases. Oct 28, 2014 at 16:56
  • 6
    I don't think you should rely on a session cookie, since users often use browsers that are not the default and when they click the link in their email it may direct to another browser. Also, they may have to go somewhere after registering, and not be able to complete the verification until later, after their browser has been closed and cookies potentially cleared. They may also choose to do the email verification on their mobile device, which I always do, since that is where I first get the email. Feb 5, 2017 at 3:41
  • 3
    @GregSchmit - In that case the user can login again with user name and password. The idea is to make the common case easy and the less common cases possible.
    – paj28
    Feb 5, 2017 at 10:37
  • Ah, I see the point you were making. I find it easier to implement a hash code that ensures the recipient of the email can validate the email (whether or not this is the creator of the account... I make accounts for my family and friends sometimes, and if I put their email I want them to be able to validate the email and make their own password). Feb 6, 2017 at 0:58

I think an alternative solution might be to ask new users to first specify just an email address, then confirm that with a hashed token, and then ask them to set a password. But I don't see very many online services that do it this way, either.

This is the most secure way as it guards against user enumeration attacks. If the email address is already registered, the user gets a password reset link, if not then they get a link to continue the signup process. Anyone without access to that email address cannot determine whether an account under that email address exists or not.

The signup process then asks the user to set a password and this protects against someone setting up and using an account associated to someone else's email address that they don't have access to.

It is not a widely used as it takes longer to implement, requires awareness of the user enumeration problem in the first place, causes a small speed bump to registration, and in some systems user enumeration is an acceptable risk as accounts on the service are deemed to be generally public anyway (e.g. webmail, as you can't send someone a message without knowing their effective user ID, and you can often verify whether an account exists by sending an email to it).

Another way to do this is the way you are describing. i.e. ask the user to enter their password when they follow the email confirmation link. There is a shortcut available here though - if the user confirms the link from the same session as was used to sign up, you could use this in lieu of a password re-entry. However, be very careful in this case that this does not lead to a session fixation attack. You should invalidate the session token and generate a new one when the user goes to the first step of your signup process. This will ensure that if the session was fixated, the attacker cannot then ride the logged in session. If you want the extra security of them entering their password again, then you must refresh the session token at the first step and once the confirmation link is followed.

  • I really like this -- wish I could upvote! We guard against user enumeration by lying... If you try to create an existing account, we say that an email got sent -- but it wasn't. If you try to password-reset a non-existent account, we also lie about sending that email. I'm not sure if it's better to actually send those emails (swapping creation/reset as you suggest) or if that will confuse the recipients even more. I guess it depends whether more people are being hacked or if more people can't remember if they previously signed up. Probably best not to lie, and just send an email warning. Oct 28, 2014 at 17:04

You don't want to authenticate the one-time link from the email:

  • It's already authenticated by virtue that whoever has access to the mailbox "owns" the whole account. That's how the password reset works.
  • The point about "someone could inadvertently confirm an email address" is moot since the desire of the one time link in the email is to verify that the mailbox owner is the owner of the account. Even if my mum clicks the link while my laptop is open, unlocked and logged into my gmail, that's fine. It's verifying that the mailbox owns the account.
  • It's a poor UX.

The only reason why your Person #1/Person #2 scenario creates a problem is because Person #1 could use the account before verifying ownership of the mailbox. If you prevented that then Person #1 would never receive the email and therefore fail to do all that "bad stuff".

  • To clarify: this is about the account creation process in which no account yet exists; it's similar but not the same as the situation where an account exists and the password is being reset. Feb 25, 2017 at 0:58
  • 4
    Caution! I just ran into a situation where the client's email service (Barracuda) "clicks" all of the links in the email immediately upon receipt, which I suppose is part of their effort to determine if the email is spam. Now I have to add authentication to email verification.
    – Jason Wood
    May 20, 2022 at 21:38
  • @JasonWood how irritating! the "passwordless login" thing is growing rapidly now. I wonder how these other providers will work around these issues
    – cottsak
    May 25, 2022 at 6:14
  • 1
    @JasonWood Does it also click on unsubscribe links in emails?
    – zigzag
    Jul 25, 2023 at 14:53
  • 1
    All I can say for sure is that the link was "clicked" within a couple seconds of being sent, and the user claimed they did not open the email or click any link. I was very concerned about this obviously and I tried to contact Barracuda but I could not get anywhere without an account. To be safe I now require login if the link is clicked on a different device/browser.
    – Jason Wood
    Jan 23 at 4:02

This is an old question but I recently faced the same scenario and want to share with my thought. What I did is not require users to login and directly verify users' email. The response is as below:

  • The author mentioned one case that a user input a wrong email address but the email owner accepts this for some reason. After verify the email, the original user may do many sorts of bad stuff. From my point of view, users' email address shouldn't be shared in your application. You need to hide users' email and not public it. Second, email is usually used for reset password, verify transaction, etc. If that user intentionally type a wrong email address, I don't see any benefits he/she can get from this action.

  • Many applications don't allow users to login without verifying the email address.

  • From UX point of view, we'd like provide a one-button click feature. In other words, we want to reduce the steps users need to make in order to verify email address. Clicking the link on that email is probably the easiest way to do so.

  • There are many other ways of verification. Email is only one of them. Others are SMS message, two factor authentication, upload identity document etc. So email is not number one important in an application.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .