Yesterday I asked Are GUIDs generated on Windows 2003 safe to use as session IDs? and the answer combined with combined with this article GUIDs are globally unique, but substrin
The short answer is, no guid's aren't sufficiently strong to generate session id's if you want to prevent session id guessing and cracking.
For the same reason why you wouldn't want to use a GUID as an AES key, you don't want to use them for any type of sensitive identifies.
A GUID works extremely well for what they are designed to be: A mathematically guarenteed unique ID to never repeat.
Even if cracking a session ID is only worth $1000, imagine if thats done 100 times. Now you're talking serious bling.
I know it's an easy way out to use GUID's but resist, and deal with the pain by taking the proper precautions to adequately secure your application. Your users will thank you.
It is almost impossible to get a duplicate guid considering the possiblities of getting one. Here are some quick math facts
Grains of sand in the world 75,000,000,000,000,000,000
Number of GUIDs 340,282,366,920,938,463,463,374,607,431,770,000,000
I suggest you use the System.Security.Cryptography.RandomNumberGenerator. This is designed to produce numbers which can't be reverse engineered. Guid's motivation is to be unique. You could combine both the GUID and secure random number, but a 128 bit secure random number is never going to have a collision on practice.
Some notes:
If you're really concerned with having strong session IDs, then perhaps a cryptographically secure hash of something that cannot be determined from off-machine would be your best approach. Perhaps generating a one-time pad from some internal document or data source would even work.
What are you trying to do? Do you want just a source of random numbers?
Check out random.org and hotbits. Many many years ago, I had a Java library that would gather numbers from these sources, and join them together, to get a quite beautiful random series (though it assumes the two sites aren't in cahootz).
It's not a complete answer, but I can tell you that the 13th hex digit is always 4 because it denotes the version of the algorithm used to generate the GUID (id est, v4); also, and I quote Wikipedia:
Cryptanalysis of the WinAPI GUID generator shows that, since the sequence of V4 GUIDs is pseudo-random, given the initial state one can predict up to the next 250 000 GUIDs returned by the function UuidCreate. This is why GUIDs should not be used in cryptography, e.g., as random keys.
The rest of the article, and its references: http://en.wikipedia.org/wiki/Guid
--Edit--
From a security standpoint, I'd suggest that you generate your session ID however you feel like, then cryptographically sign it; that way you can pack in whatever information you want and then just slap a signature on the end - the possible issue being the tradeoff between the size/strength of your key and the resulting size of the cookie. GUIDs are useful as IDs, but I'd only rely on a dedicated cryptographic technique for security.