I would like to implement the following use case:

  1. User lands on the login page
  2. User submits login credentials
  3. Credentials are validated and they are redirected to another page for inputting the multi-factor authentication token
  4. User submits multi-factor authentication token
  5. Token is validated and user is redirected into the application

My question is about stages 3-5 - What is the recommended method for keeping track of this user once they have entered their username/password but before they have entered their multi-factor authentication token. In order to validate the token there needs to be a way to know which user is making the request. There also must be a way to prevent attackers from skipping over the Username/Password part of the process.

What is the recommended way of solving this problem?

  • Short answer: session cookie
    – gowenfawr
    Apr 27, 2015 at 13:25
  • Sounds reasonably but surely I must put something intelligent in session cookie to prevent bad guys from easily spoofing it? Apr 27, 2015 at 13:28
  • Why not just require the username, password AND multi-factor at the same page?
    – ThoriumBR
    Apr 27, 2015 at 13:57
  • @ThoriumBR I agree that this would be ideal but may not be acceptable due to User Experience concerns. Not every user in the system would be configured with MFA. Apr 27, 2015 at 14:01

3 Answers 3


Use a Session Cookie to track users throughout the authentication process, just as you would after authentication.

Make sure that your cookie's length and complexity are sufficient to withstand brute-force and spoofing attacks. Use the secure and httponly attributes to prevent the bad guys from capturing and using it.

Use one cookie for first-auth-through-verification, and then renew the session id after the second step, which is a Privilege Change.

This is one of those things where the problems have been plumbed and the best practices exist to prescribe what you should do - just read, understand, and follow the OWASP Session Management Cheat Sheet.

  • What if httponly cookies were completely out of the question? Apr 27, 2015 at 13:58
  • 1
    @theycallmemorty, if you require client-side scripts to access cookies and thus can't use HttpOnly, then you have a slightly higher risk of cookies being stolen and used by someone else. If your business need outweighs that security risk, go ahead. HttpOnly is on the easier-to-live-without end of the pool IMHO. Maybe you can bind session IDs to IP addresses, for example, as a compensating control.
    – gowenfawr
    Apr 27, 2015 at 14:33

You should have session cookies. Most web frameworks have useful support for that.

But from a security viewpoint, there is an important issue.

Using session cookies (to differentiate the browsers using your site) and login credentials (to differentiate the users of your site) effectively doubles the authentication functionality of your system. Thus a new attack possibility emerges, based on the unexpected interactions between the two.

The two most trivial attack types could be:

  1. If a user signs out, and then logins again, you will have the same session id, but with a different user. For example, logging out as a moderator user, and then logging in a normal user, could enable the second to use the moderator privileges of the previous login.
  2. Cookies will be nearly so important as passwords - but they aren't even nearly so strictly guarded. A stolen cookie can make possible to effectively "steal" the account which it belongs to.


  1. Use https.
  2. Use a fast cookie timeout.
  3. After a logout, remove the validity of the session cookie.
  4. Try to use as few session-bound variables, as you can.

I would use an unprivileged session token between the two steps, that only proves that this user has finished the first part of your multi-stage authentication processes, but that leaves him unauthenticated (unprivileged).

Then, after the completion of the second-stage, regenerate a session token and escalate the user's privileges to "authenticated" (or anything that fits your access control matrix).

Only allow access to the second stage if you have a token proving that the first stage was completed. Else, redirect the user to the first stage.

You may that a look at the OWASP Authentication Cheat Sheet for some good guidelines: https://www.owasp.org/index.php/Authentication_Cheat_Sheet

You must log in to answer this question.

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