0

This blog post describes a method for preventing session fixation attacks (in ASP.Net in particular). The idea is that the session id should be tied to the user's identity in a verifiable way, which means that a given session id can't be valid for both the attacker and the victim. Their construction uses:

select random nonce
session_id = nonce || MAC(nonce || username).

For an application that runs on a cluster, distributing or changing the MAC key can be inconvenient. What is lost if the MAC is replaced by an unkeyed hash?

select random nonce
session_id = nonce || Hash(nonce || username).

It does mean that an attacker can generate session ids that are valid for a given identity, but it's still true that a session id won't be accepted for both attacker and victim. Is there a weakness with this approach?

Improve this question
2
  • I don't think the question here is regarding session fixation but more about generating a session ID itself. Session fixation is an attack where the attacker can either obtain a (default) session ID or can set a session ID to the victim. In both cases the attacker knows the session ID and can perform session hijacking. The reason session fixation exists is because the application does not destroy the old session ID once the user is authenticated. A session ID should be strong and not easily guessable, if MAC is no solution for you, then try to think of something that is workable for you.
    – Jeroen
    Feb 3, 2015 at 19:29
  • Just make sure the session ID you generate is long and strong enough.
    – Jeroen
    Feb 3, 2015 at 19:29

1 Answer 1

Reset to default
1

Q1 - Preventing Session Fixation - MAC or Hash?

Q2 - What is lost if the MAC is replaced by unkeyed hash?

Q3 - Is there a weakness with this approach (of replacing MAC with a hash)?

You identified the drawback of key management with using MAC across multiple servers whereas with unkeyed hash the only drawback is increased risk of session forgery due to the public nature of a hash function. So in terms of the more secure option, the MAC option is better for preventing forged sessions. However, in both cases as you pointed out, session fixation can still occur. Other approaches I have seen to strengthen the session id is to adjust the session expiry and to include the user agent as input to the MAC function. I think Q1, Q2, and Q3 are partially asserting or assuming that using MAC in session id creation is the "solution" to preventing session fixation. I think that it is important to be mindful of a comprehensive set of strategies to prevent session fixation. However, a very important issue in the ASP.Net environment is to not reuse old session ids after a user which is a huge vulnerability for session fixation exploits.

See https://support.microsoft.com/en-us/kb/899918

Improve this answer

You must log in to answer this question.

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