Skip to main content
replaced https://tools.ietf.org/html/rfc with https://www.rfc-editor.org/rfc/rfc
Source Link

UUIDs do not generally guarantee unpredictability or any security properties. As RFC 4122RFC 4122 says (section 6):

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. A predictable random number source will exacerbate the situation.

What you require here is a cryptographically secure random number generator. Some UUID implementations are driven off such RNGs, but that's an implementation choice, not a guarantee. The ITU standard explicitly says that the use of cryptographic random number is recommended, which clearly implies it's not a requirement (p. 10):

The use of cryptographic-quality random numbers is strongly recommended in order to reduce the probability of repeated values.

And it turns out that some UUID implementations are not secure. For example, at least some versions of Google's V8 Javascript engine use a non-cryptographic PRNG for random UUID generation. The link describes how to attack such UUIDs—with a couple of lines of code, an attacker who sees one such UUID can reconstruct the PRNG's state when it output that UUID, which allows them to predict all subsequent UUIDs.

So I would not use UUIDs as cryptographic secrets—I'd interface directly with the cryptographic RNG, at least to make the intent of the code evident.

The bigger problem is that your users wouldn't be able to remember such tokens; they'd have to store them somewhere secure, and you'd be providing no assistance for so doing. The unobvious but actually very natural alternative here is to use a multi-factor authentication system based on passwords and secret keys, like TOTP. For example, if you build an integration with Google Authenticator or Authy, your users get the benefit of those vendors' user-side apps to store and manage the shared secret key.

UUIDs do not generally guarantee unpredictability or any security properties. As RFC 4122 says (section 6):

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. A predictable random number source will exacerbate the situation.

What you require here is a cryptographically secure random number generator. Some UUID implementations are driven off such RNGs, but that's an implementation choice, not a guarantee. The ITU standard explicitly says that the use of cryptographic random number is recommended, which clearly implies it's not a requirement (p. 10):

The use of cryptographic-quality random numbers is strongly recommended in order to reduce the probability of repeated values.

And it turns out that some UUID implementations are not secure. For example, at least some versions of Google's V8 Javascript engine use a non-cryptographic PRNG for random UUID generation. The link describes how to attack such UUIDs—with a couple of lines of code, an attacker who sees one such UUID can reconstruct the PRNG's state when it output that UUID, which allows them to predict all subsequent UUIDs.

So I would not use UUIDs as cryptographic secrets—I'd interface directly with the cryptographic RNG, at least to make the intent of the code evident.

The bigger problem is that your users wouldn't be able to remember such tokens; they'd have to store them somewhere secure, and you'd be providing no assistance for so doing. The unobvious but actually very natural alternative here is to use a multi-factor authentication system based on passwords and secret keys, like TOTP. For example, if you build an integration with Google Authenticator or Authy, your users get the benefit of those vendors' user-side apps to store and manage the shared secret key.

UUIDs do not generally guarantee unpredictability or any security properties. As RFC 4122 says (section 6):

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. A predictable random number source will exacerbate the situation.

What you require here is a cryptographically secure random number generator. Some UUID implementations are driven off such RNGs, but that's an implementation choice, not a guarantee. The ITU standard explicitly says that the use of cryptographic random number is recommended, which clearly implies it's not a requirement (p. 10):

The use of cryptographic-quality random numbers is strongly recommended in order to reduce the probability of repeated values.

And it turns out that some UUID implementations are not secure. For example, at least some versions of Google's V8 Javascript engine use a non-cryptographic PRNG for random UUID generation. The link describes how to attack such UUIDs—with a couple of lines of code, an attacker who sees one such UUID can reconstruct the PRNG's state when it output that UUID, which allows them to predict all subsequent UUIDs.

So I would not use UUIDs as cryptographic secrets—I'd interface directly with the cryptographic RNG, at least to make the intent of the code evident.

The bigger problem is that your users wouldn't be able to remember such tokens; they'd have to store them somewhere secure, and you'd be providing no assistance for so doing. The unobvious but actually very natural alternative here is to use a multi-factor authentication system based on passwords and secret keys, like TOTP. For example, if you build an integration with Google Authenticator or Authy, your users get the benefit of those vendors' user-side apps to store and manage the shared secret key.

Example of actual insecure UUID generator from V8
Source Link
Luis Casillas
  • 10.9k
  • 2
  • 32
  • 42

UUIDs do not generally guarantee unpredictability or any security properties. As RFC 4122 says (section 6):

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. A predictable random number source will exacerbate the situation.

What you require here is a cryptographically secure random number generator. Some UUID implementations are driven off such RNGs, but that's an implementation choice, not a guarantee. The ITU standard explicitly says that the use of cryptographic random number is recommended, which clearly implies it's not a requirement (p. 10):

The use of cryptographic-quality random numbers is strongly recommended in order to reduce the probability of repeated values.

And it turns out that some UUID implementations are not secure. For example, at least some versions of Google's V8 Javascript engine use a non-cryptographic PRNG for random UUID generation. The link describes how to attack such UUIDs—with a couple of lines of code, an attacker who sees one such UUID can reconstruct the PRNG's state when it output that UUID, which allows them to predict all subsequent UUIDs.

So I would not use UUIDs as cryptographic secrets for that reason—I'dsecrets—I'd interface directly with the cryptographic RNG, at least to make the intent of the code evident.

The bigger problem is that your users wouldn't be able to remember such tokens; they'd have to store them somewhere secure, and you'd be providing no assistance for so doing. The unobvious but actually very natural alternative here is to use a multi-factor authentication system based on passwords and secret keys, like TOTP. For example, if you build an integration with Google Authenticator or Authy, your users get the benefit of those vendors' user-side apps to store and manage the shared secret key.

UUIDs do not generally guarantee unpredictability or any security properties. As RFC 4122 says (section 6):

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. A predictable random number source will exacerbate the situation.

What you require here is a cryptographically secure random number generator. Some UUID implementations are driven off such RNGs, but that's an implementation choice, not a guarantee. The ITU standard explicitly says that the use of cryptographic random number is recommended, which clearly implies it's not a requirement (p. 10):

The use of cryptographic-quality random numbers is strongly recommended in order to reduce the probability of repeated values.

So I would not use UUIDs as cryptographic secrets for that reason—I'd interface directly with the cryptographic RNG, at least to make the intent of the code evident.

The bigger problem is that your users wouldn't be able to remember such tokens; they'd have to store them somewhere secure, and you'd be providing no assistance for so doing. The unobvious but actually very natural alternative here is to use a multi-factor authentication system based on passwords and secret keys, like TOTP. For example, if you build an integration with Google Authenticator or Authy, your users get the benefit of those vendors' user-side apps to store and manage the shared secret key.

UUIDs do not generally guarantee unpredictability or any security properties. As RFC 4122 says (section 6):

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. A predictable random number source will exacerbate the situation.

What you require here is a cryptographically secure random number generator. Some UUID implementations are driven off such RNGs, but that's an implementation choice, not a guarantee. The ITU standard explicitly says that the use of cryptographic random number is recommended, which clearly implies it's not a requirement (p. 10):

The use of cryptographic-quality random numbers is strongly recommended in order to reduce the probability of repeated values.

And it turns out that some UUID implementations are not secure. For example, at least some versions of Google's V8 Javascript engine use a non-cryptographic PRNG for random UUID generation. The link describes how to attack such UUIDs—with a couple of lines of code, an attacker who sees one such UUID can reconstruct the PRNG's state when it output that UUID, which allows them to predict all subsequent UUIDs.

So I would not use UUIDs as cryptographic secrets—I'd interface directly with the cryptographic RNG, at least to make the intent of the code evident.

The bigger problem is that your users wouldn't be able to remember such tokens; they'd have to store them somewhere secure, and you'd be providing no assistance for so doing. The unobvious but actually very natural alternative here is to use a multi-factor authentication system based on passwords and secret keys, like TOTP. For example, if you build an integration with Google Authenticator or Authy, your users get the benefit of those vendors' user-side apps to store and manage the shared secret key.

cite the ITU standard.
Source Link
Luis Casillas
  • 10.9k
  • 2
  • 32
  • 42

UUIDs do not generally guarantee unpredictability or any security properties. As RFC 4122 says (section 6):

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. A predictable random number source will exacerbate the situation.

What you require here is a cryptographically secure random number generator. Some UUID implementations are driven off such RNGs, but that's an implementation choice, not a guarantee. The ITU standard explicitly says that the use of cryptographic random number is recommended, andwhich clearly implies it's not a requirement (p. 10):

The use of cryptographic-quality random numbers is strongly recommended in order to reduce the probability of repeated values.

So I would not use UUIDs as cryptographic secrets for that reason—I'd interface directly with the cryptographic RNG, at least to make the intent of the code evident.

The bigger problem is that your users wouldn't be able to remember such tokens; they'd have to store them somewhere secure, and you'd be providing no assistance for so doing. The unobvious but actually very natural alternative here is to use a multi-factor authentication system based on passwords and secret keys, like TOTP. For example, if you build an integration with Google Authenticator or Authy, your users get the benefit of those vendors' user-side apps to store and manage the shared secret key.

UUIDs do not generally guarantee unpredictability or any security properties. As RFC 4122 says (section 6):

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. A predictable random number source will exacerbate the situation.

What you require here is a cryptographically secure random number generator. Some UUID implementations are driven off such RNGs, but that's an implementation choice, not a guarantee, and I would not use UUIDs as cryptographic secrets for that reason—I'd interface directly with the cryptographic RNG, at least to make the intent of the code evident.

The bigger problem is that your users wouldn't be able to remember such tokens; they'd have to store them somewhere secure, and you'd be providing no assistance for so doing. The unobvious but actually very natural alternative here is to use a multi-factor authentication system based on passwords and secret keys, like TOTP. For example, if you build an integration with Google Authenticator or Authy, your users get the benefit of those vendors' user-side apps to store and manage the shared secret key.

UUIDs do not generally guarantee unpredictability or any security properties. As RFC 4122 says (section 6):

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. A predictable random number source will exacerbate the situation.

What you require here is a cryptographically secure random number generator. Some UUID implementations are driven off such RNGs, but that's an implementation choice, not a guarantee. The ITU standard explicitly says that the use of cryptographic random number is recommended, which clearly implies it's not a requirement (p. 10):

The use of cryptographic-quality random numbers is strongly recommended in order to reduce the probability of repeated values.

So I would not use UUIDs as cryptographic secrets for that reason—I'd interface directly with the cryptographic RNG, at least to make the intent of the code evident.

The bigger problem is that your users wouldn't be able to remember such tokens; they'd have to store them somewhere secure, and you'd be providing no assistance for so doing. The unobvious but actually very natural alternative here is to use a multi-factor authentication system based on passwords and secret keys, like TOTP. For example, if you build an integration with Google Authenticator or Authy, your users get the benefit of those vendors' user-side apps to store and manage the shared secret key.

typo
Source Link
Luis Casillas
  • 10.9k
  • 2
  • 32
  • 42
Loading
Source Link
Luis Casillas
  • 10.9k
  • 2
  • 32
  • 42
Loading