6

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?

Community
  • 1
  • 1
Rory
  • 40,559
  • 52
  • 175
  • 261

1 Answers1

7

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.

Community
  • 1
  • 1
mythz
  • 141,670
  • 29
  • 246
  • 390
  • Just realised that ASP.NET doesn't use SessionIds for authentication but rather encrypted & hashed FormsAuthenticationTickets. Any thoughts on comparison of security? Not wanting to be a pain but this is important for us to be able to comfortably choose this framework. – Rory Feb 26 '13 at 23:56
  • The quickest way to get something done is to just send a pull-request for it. Otherwise it'll have to wait till we have the free time to do it. I'll look at getting this in before this weekends release (v3.9.38+) - but no promises. – mythz Feb 27 '13 at 00:00
  • 3
    FYI v3.9.38+ of ServiceStack was updated to use RNGCryptoServiceProvider as seen [in this commit](https://github.com/ServiceStack/ServiceStack/commit/4235f0b11ff6ee9a6f49c49edacb4363684291e2) – mythz Mar 04 '13 at 21:02
  • Awesome!! Did you go down to 120-bits just to be consistent with ASP.NET SessionIds? – Rory Mar 05 '13 at 00:43
  • Yeah, no strong reason to be different. So just in-case SessionIds ever need to be compatible with existing ASP.NET SessionId field in future. – mythz Mar 05 '13 at 00:51