3

I have been reading a little bit about security lately and wondered this. Why are session IDs not essentially temporary passwords linked to the user name? Both being sent from the client and checked by the server with each request.

From what I can make out it would be more difficult to hijack by brute force (though perhaps not more than just adding more bits to the session ID), help prevent session fixation and improve logging to discover how/why the site is being attacked.

Though from what I can make out it's not standard practice, so I feel like I must be missing something.

techraf
  • 9,159
  • 11
  • 45
  • 63
Matthew
  • 33
  • 2
  • Would user's have to type in their session ID as a password? If not, what are you proposing? Can you explain what the authentication flow would be? – Neil Smithline Jul 02 '16 at 22:00
  • The user would authenticate with their credentials as normal. When their user name and password are sent to the server, the session ID would be generated by the server. This is then saved to a cookie with the user name that was just supplied and verified.

    The user never sees or needs to know their session ID. It's essentially as session IDs are normally, but with user names added to them.

     – Matthew Jul 02 '16 at 22:10

1 Answers1

1

A session id is a temporary password which is usually linked to a username. Anonymous sessions are also useful tools in some cases.

Storing the username on the client serves no useful purpose. If the server trusted this information then it anyone could gain control by changing their username cookie to 'admin' or root'. Hence the session id does identify the user as well as proving the state of authentication, but only via an indirect lookup stored on the server.

In addition to anonymous sessions, it's also worth noting that the session data may be more than just a username and authentication state - it may also contain authorization information (e.g. roles) user preferences and (within bounds) transactional information. Storing information securely is not easily done on a substrate which is not protected against tampering.

I don't understand how you think this makes session hijacking / fixation more difficult; you've not explained why and you have some misconceptions about the way sessions work.

Certainly if the cookie data was trustworthy, then it would be easy to associate the true identify of an attacker with the http requests however the data is NOT to be trusted.

There are other ways to map identities to requests at the webserver - most SSO implementations provide for populating the webservers notion of the authenticated user. The information can be pushed up from the application (e.g. mod_auth_memcookie) or indirectly via other vectors such as supercookies and browser fingerprinting.

HashHazard
  • 5,195
  • 1
  • 20
  • 29
symcbean
  • 18,625
  • 1
  • 41
  • 75
  • Thanks. I'm not a security expert. It certainly doesn't surprise me I have some misconceptions. I realised it is a temporary password of sorts. It's just not tied to a user name on the client so I changed the terminology to reflect that. My thoughts were: brute force hijack is more difficult as you can only guess one person's session at a time. Performing an attack by session fixation now requires you to also know the user's user name. Obviously you would hope these are prevented anyway (long, regenerated IDs). The main thing is the more informative logging. You can see who is being targeted. – Matthew Jul 02 '16 at 22:48
  • Also I'd really appreciate knowing what my misconceptions about how sessions work are. Thanks. – Matthew Jul 02 '16 at 22:50
  • 1
    Why is guessing the username any harder than guessing part of the session id? Assuming the latter is randomly generated it should have much less redundancy / greater entropy. – symcbean Jul 02 '16 at 22:57
  • It's not. I admitted as much in the original post. – Matthew Jul 02 '16 at 22:58