12

To start, and define guid, i am using a .net framework Guid This is somewhat a hypothetical situation Users when preforming a specific action have guids generated. Each user can see their own guids. If a user was to know one of another user's guid there would be a security compromise.

How safe is this system if we asume that a user has no way to steal another user's guid and can only guess it?

I understand that blindly guessing guids is impossible. Even if they had a million success values, they would still have only a 10^20 chance of a successful guess

Where i am afraid a problem may exist is guid prediction. Can a user generate a large number of requests, look at the guids he got, and knowing the .net guid generation formula greatly improve his odds of guessing? Can these odds be reduced to a point where they would be a security concern? In that case how should keys be generated in a unique non guessable way?

I ask anyone who mentions the odds of guesses/collisions to add some hard meaning to it. Either an exact number to define odds, or something like, "it can be used to store account data, but not sensitive data"

EDIT

this question seems to go well into the territory I originally sought to explore with this question Is a GUID a good key for (temporary) encryption?

Community
  • 1
  • 1
Andrey
  • 1,247
  • 11
  • 30
  • 1
    Guid's are not unique; thus in theory two users could have the same Guid. – Aaron McIver Jan 25 '11 at 21:37
  • Probably similar to http://stackoverflow.com/questions/4517497/how-secure-are-guids-in-terms-of-predictability – Eugene Mayevski 'Callback Jan 25 '11 at 21:41
  • For correctly generated random guids the chances of collision are sufficiently low to guarantee uniqueness in practice. – CodesInChaos Jan 25 '11 at 21:41
  • 1
    @Aaron, guids are not technically unique, but they are statistically unique. With 3.4×10^38 possible guids...every star in the observable universe could statistically possess 6.8×10^15. The odds of any two people having the same guid is insanely unlikely – guildsbounty Jan 25 '11 at 21:46
  • @Eugene Mayevski 'EldoS Corp i am realy looking for someone to discuss active prediction attacks. The db will take care of not allowing collisions – Andrey Jan 25 '11 at 21:48
  • @guildsbounty there aren't that many Version 4 UUIDs since a few bits are reserved. But rest of your comment is still correct. – CodesInChaos Jan 25 '11 at 21:49

2 Answers2

8

GUID's/UUID's are intended to generate 128 bit numbers for use primarily as ID's that are unique (for all intents and purposes).

UUID's are not designed to generate cryptographically strong random number sequences, and if you want maximum un-predictability, then cryptographically strong random number sequences are exactly what you want. For this, .NET provides you with the RNGCryptoServiceProvider - designed from the ground up to be as unpredictable as can be reasonably achieved by algorithmic means, so why not use it?

Example:

byte[] GenerateRandomBytes()
{
   byte[] key = new byte[16];

    System.Security.Cryptography.RNGCryptoServiceProvider c =
        new System.Security.Cryptography.RNGCryptoServiceProvider();

    c.GetBytes(key);

    return key;
}
saille
  • 9,014
  • 5
  • 45
  • 57
4

Afaik .net generates Version 4 UUIDs as Guids by default. These are random and hard to guess if properly implemented. But since future versions might use another implementation I wouldn't rely on that. I think even earlier versions of windows or .net used Guids based on the Mac-Address which are easier to guess.

So I'd just use one of the crypto-pseudo-random-number-generators built into .net instead. If you generate 16 bytes you have a drop-in replacement for a Guid.

CodesInChaos
  • 106,488
  • 23
  • 218
  • 262
  • 2
    could you define "hard to guess". Safe enough for forum, safe enough for a bank, safe enough for national security – Andrey Jan 25 '11 at 21:46
  • A random 128 bit number is secure enough for anything(well national security requires certain certification processes, so your ad-hoc implementation can't be used). The quality of numbers is the problem. That's why I recommended not using the standard GUID generator, but a crypto-prng instead. – CodesInChaos Jan 25 '11 at 21:50
  • 1
    There are other attacks much more likely than randomly guessing a valid random number of that size. – CodesInChaos Jan 25 '11 at 21:51
  • If your only worry is someone deriving a GUID by forcing the system to generate a bunch of GUIDs and analyzing them for a pattern then I think you're safe if you generate them using the `RNGCryptoServiceProvider`. I think an attacker would probably go after your transport method instead (HTTP, SMTP, etc). If you believe that someone might attempt to perform this type of attack I'd recommend using a rate-limiter on whatever is "authenticating" the GUID. – Chris Haas Jan 25 '11 at 22:10
  • For such long random numbers bandwidth is a sufficient limitation. But urls can leak rather easily. The browser or a proxy might keep history, its part of the referrer of links you follow from that page,... – CodesInChaos Jan 26 '11 at 08:30
  • @CodesInChaos: actually "A random 128 bit number is secure enough for..." should say 122 bits, cause in version 4 of GUID, which is what .NET currently generates, 6 bits are fixed. – Piotr Owsiak Mar 08 '16 at 14:53
  • @CodesInChaos: also because of 6 bits being fixed you cannot just generate 16 byte random sequence and treat as a drop in replacement for Guid. – Piotr Owsiak Mar 08 '16 at 14:54