1

Lets say I want to generate a name-based UUID using v5 of the RFC 4122 using sensitive information as the input (for example the password to my bank account). And lets say I give the generated UUID to a malicious user who wishes to reverse it and obtain my password. Given the following about how UUID v5 is generated:

  • Password and namespace are hashed with SHA-1, which is a one-way function, that is, a function which is practically infeasible to invert
  • Only the first 16 bytes of the 20 byte SHA-1 hash are kept

The malicious user cannot reverse the UUID to obtain my password. Is this a safe assumption to make? And if so, why does the RFC 4122 specification state "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."? Does the fact that SHA-1 is a one way function alone makes it fairly secure, assuming you're not using any data that is susceptible to dictionary attacks or rainbow tables?

Community
  • 1
Cooper
  • 113
  • 4

1 Answers1

2

Whether this is secure depends on the entropy in the secret. If your input is a regular password, where entropy is low, any simple hash using your password and other determinstic data is insecure because an attacker can simply brute-force all the possible passwords to determine yours. This is true of literally all such types of simple hashing of passwords, with or without additional data, whether in a UUID or not, and whether or not truncated. There are many, many password lists of breached passwords and it's extremely easy to generate many possible passwords programmatically.

If this is a pseudorandomly generated token with enough (e.g., 128 bits or more) of entropy, then this is secure. Using a cryptographic hash function on a high-entropy secret is secure because it is impossible to efficiently guess the input based only on knowing the algorithm and the hash, since the domain of the function is sufficiently large.

bk2204
  • 7,828
  • 16
  • 15