From what I understand about the way session hijacking works I don't see any advantage that Forms Authentication has over storing user authentication info in the ASP.NET session. Both Forms Authentication and ASP.NET session use cookies that are both hashed to verify integrity but both can't protect against a hacker stealing the cookie and masquerading as the user. So is there any reason as far as security is concerned, for using Forms Authentication over storing authentication info in the ASP.NET session?
Couple of differences:
If you store authentication information in session state and the app pool recycles, all of your users are instantly logged out. In contrast, forms authentication holds the necessary information in encrypted format in the forms authentication cookie, and will survive app pool recycle.
Session IDs are a 120-bit random number. The only protection is the randomness. There is no tamperproofing and in fact a hacker could continuously poll your web site with random session IDs until he finds one that works. There is no intrusion detection mechanism for this sort of activity, because it is impossible to distinguish a tampered session ID from an expired one.
The forms authentication ticket (cookie) is completely different. It is composed of a long string of data that is then encrypted with your 128-bit machine key. If anyone tampers with it it simply won't decrypt. The failure to decrypt is a trappable error and can be enlisted in intrusion detection mechanisms. The overall cardinality of the ticket is much higher and harder to brute force.
On all the sites I have worked with recently, we actually use BOTH the forms authentication mechanism and the ASP.NET_SessionId. We also have an internal session ID (an ESB session identifier) that we insert into the forms authentication ticket.