0

As is stated in this question:

Two-factor or multi factor authentication is based on three possible forms of authentication:

  • Something you know which is considered secret (password)

  • Something you have (token, SMS token, card,...)

  • Something you are (biometrics)

Given that a session ID is obtained after a successful authentication, could it be considered as "something you have" obtained from "something you know" (e.g. user/password)?

For example, if I want to authorize a specific operation by using biometrics, would be the pair ("session ID","biometrics") be considered as a valid two-factor authentication?

Improve this question
4
  • 1
    I'm confused at the use case for this - to authenticate and gain a session ID in the first place, you'd need two different factors - otherwise you'd just have one factor authentication "holding the gates", as it were.
    – Monica Apologists Get Out
    Mar 15, 2018 at 13:40
  • 1
    Well if you have to authenticate to obtain your session id, that hardly counts as an authentication factor, now, does it?
    – korrigan
    Mar 15, 2018 at 13:40
  • A use case would be, for example, that I allow a user to login and visualize information by asking just user/password, but if he tries to edit something then I ask for a biometric factor. In this situation, the user would be providing 2 factors: session id (which equals to user/password, is it's obtained by authentication with them), and biometric factor. Would this be considered a two-factor mechanism?
    – Jausk
    Mar 15, 2018 at 13:57
  • In which case the two factors are 1. Password, and 2. Biometrics. Don’t attempt at redefining what 2FA (or MFA) means and what users should expect from it. If you say your application implement 2FA but the authentication only asks for a password, they’ll be (rightly) suspicious because it doesn’t really. Authentication already happened, and impersonators (for example) have access to it, even it it’s a partial scope.
    – korrigan
    Mar 15, 2018 at 14:46

1 Answer 1

Reset to default
1

The "something you...." terms are intended to illustrate by example what the underlying concepts are. It would be wrong to infer a reverse relationship; the examples do not define the concept.

Usually when we are talking about session ids then we're talking about HTTP sessions. Here the session id has 2 functions:

  1. it acts as surrogate credentials in place of supplying your username and password with every request

  2. it provides a means for the application to maintain state (e.g. the contents of your shopping basket) between requests

Since it acts as a surrogate for the (username and) password rather than alongside it, it is not 2 factor authentication.

Authentication data is supplied by the party seeking to be authenticated - however a session id is generated by the service and reflected by the client. It is therefore not authentication data. Allowing clients to choose their own session id creates security vulnerabilities.

That's not to say that persistent data stored on the browser could not be used as a second factor ("device registration") but this should be emplaced independently of the users application session.

Improve this answer

You must log in to answer this question.

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