Are ServiceStack session ids secure enough?

Question

From what I understand, when using ServiceStack's Authentication you'd typically authenticate at the start of a session and then mark the session on the server side as authenticated. Subsequent web service requests will use that session id and not require re-authentication. (Please correct me if I'm wrong so far).

Generation of new session ids is performed using Guid.NewGuid() in SessionExtensions.cs, which doesn't generate cryptographically fantastic values. Is there any reason not to switch to use cryptographically secure values, e.g. using RNGCryptoServiceProvider?

UPDATE:

Actually, after thinking about it a bit further, ASP.NET doesn't use its Session Id to confirm that the requestor is authenticated. It uses a FormsAuthenticationTicket which has been encrypted with a machine key and hashed (here's a nice description of the process for ASP.NET 2.0).

I'm not a security dude so I don't know what implication this has if you were to compare the level of security provided by ASP.NET Forms Auth and that provided by a random value. I suppose it all comes down to key and data lengths... but also the time required to mount a brute-force attack on Forms Authentication is probably much higher as it doesn't require just trying a whole heap of random numbers?

Answer 1

Right ServiceStack uses the standard HTTP approach of Authenticating + Set session cookie to setup an authenticated session for subsequent requests, which is a common approach across all web frameworks.

Although I've never heard of a vulnerability in .NET from being able to predict and reverse-engineer a GUID, it appears that ASP.NET's own SessionId is not as strong as a Guid (2^120 vs 2^128 bits of entropy). But given it's not truly random we'll change ServiceStack's implementation to use a truly random identifier in the next release.