RFC4122bis specifies UUID v7, a version which contains 74 bits of randomness.
Assuming I use a CSPRNG to generate the random bits: Are these UUIDs considered to be unguessable and are enough to prevent attacks such as IDOR?
2 Answers
RFC4122bis specifies UUID v7, a version which contains 74 bits of randomness.
No it should not be used for security.
The UUIDv7 draft states:
If UUIDs are required for use with any security operation within an application context in any shape or form then [RFC4122] UUIDv4 SHOULD be utilized.
However, I would recommend against using UUIDv4 (which has 122 bits of entropy) for security as well. While using an UUID for authorization is quite frequent, it is probably easier to generate a completely random token with a higher entropy.
For example, RFC6819 recommends at least 128 bits of entropy for tokens and secrets. The Oauth 2.1 draft states requires at least 128 bits of entropy and recommends at least 160 bits:
The probability of an attacker guessing generated tokens (and other credentials not intended for handling by end-users) MUST be less than or equal to 2^(-128) and SHOULD be less than or equal to 2^(-160).
Considering your other question:
Are these UUIDs considered to be unguessable and are enough to prevent attacks such as IDOR?
I understand in this question that you want to make the identifier of the resource unguessable in order to protect against IDOR. This is probably not a good approach in most cases.
One problem is that you are conflating the identifier and the authorization token to access this resource. This means it will not be possible to revoke the access without revoking the resource identifier which might (or might not) be a problem.
Moreover, the identifier might be leaked in some other ways.
Whether 74 random bits is sufficiently secure depends on your use case.
Since you mention IDOR, you are probably thinking about using UUIDv7 to identify objects in a web service. In that case, it would need to resist an online attack. You can make that harder for the attacker by implementing rate limiting. If the attacker can only perform guesses at a limited rate, guessing 74 bits would take billions of years.
Unguessable identifiers are not a replacement for proper access control. If I send you the UUID of an object you are not authorized for, you still shouldn't be able to view it, even if you have the UUID.
According to the spec, UUIDv7 is not guaranteed to have 74 bits of random data. These 74 bits can be optionally used by timestamps and counters:
Alternatively, implementations MAY fill the 74 bits, jointly, with a combination of the following subfields, in this order from the most significant bits to the least, to guarantee additional monotonicity within a millisecond:
- An OPTIONAL sub-millisecond timestamp fraction (12 bits at maximum) as per Section 6.2 (Method 3).
- An OPTIONAL carefully seeded counter as per Section 6.2 (Method 1 or 2).
- Random data for each new UUIDv7 generated for any remaining space.
