1

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 '15 at 13:25
  • Sounds reasonably but surely I must put something intelligent in session cookie to prevent bad guys from easily spoofing it? – theycallmemorty Apr 27 '15 at 13:28
  • Why not just require the username, password AND multi-factor at the same page? – ThoriumBR Apr 27 '15 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. – theycallmemorty Apr 27 '15 at 14:01
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? – theycallmemorty Apr 27 '15 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 '15 at 14:33
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.
1

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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