Securing a secondary login page for inputting a multi-factor auth token

Question

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?

Answer 1

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.

Answer 2

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.

Thus,

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.

Answer 3

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