I recently ran into an interesting discrepancy:

What you see below are 120-bit Session IDs, one printed as hex and one in the format of a #UUIDv4.

After validating their randomness, I would classify the first as secure but raise concerns about the second.

Why?

Well, according to RFC 4122:

"Do not assume that UUIDs are hard to guess; they should not be used as security capabilities (identifiers whose mere possession grants access), for example."

And that's exactly what a session ID is: an identifier whose possession grants access. As such, UUIDs should not be used in such a case.

What do you think? Is this nitpicking? Or a valid security nuance?

Does the format in which data is displayed have an impact on its security?

I'd love to hear your thoughts.

#Pentesting #AppSec #InfoSec #CyberSecurity #BugBounty #Hacking

@kpwn while the format alone doesn't change the security attributes i'd say it may at least invite attackers to believe its a insecure token worth to be guessed.

The owasp guidelines recommend at least 128 bits (of course generated with a cryptographically secure random number generator), but if these 8 bits actually impact security in a meaningful way?

(I referenced to https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html#session-id-entropy)

@kpwn UUIDv4 can be based on CSPRNG, in that case it's just as secure as a sid with same number of (secure) random bits. Only problem is that random source can't be identified in a blackbox setting, but statistical methods can give a good estimation about its security.

@kpwn wrote: "Does the format in which data is displayed have an impact on its security?"
No.

You just need to be sure that a cryptographically secure random number generator was used to generate the number.

The original UUID/GUID was intended to be globally unique, not unguessable.