I'd like to use a V4 UUID / GUID for authenticating users. To be specific, the user would have to paste the UUID into a text field to gain access to their account. The UUID would be given to them at the time of registration. The UUID would be combined with a username (public) when authing.

Assume normal security practices are in place (SSL, DB holding the UUIDs is encrypted at rest, guards against brute force attacks, UUID would not be passed in a URL, etc). Assume that the application isn't for anything extremely important (banking) but is still fairly important (pretend it is domain names, for the sake of argument). Don't worry about the usability issues that the user might have. I'm just concerned about security.

  • Given the above, is this still a bad idea?
  • Do you think this is less secure than username / pass?
  • Would slamming two UUIDs together be more secure?

My goal here is to not be storing personal data of any kind (email / pass). My hope is that this is a viable alternative.


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.

| improve this answer | |
  • 2
    Luis, my understanding is that a V4 UUID is random and not predictable (and could actually have collisions). – legeek Apr 13 '17 at 0:33
  • @legeek: The RFC—which is one of the documents that officially defines what UUIDs are—says otherwise, as I quoted. – Luis Casillas Apr 13 '17 at 0:43
  • UUID4 is entieraly generated by CSPRING and is not predictable. – rook Apr 13 '17 at 0:50
  • 6
    @rook: If the fact that I've quoted official documents saying otherwise doesn't convince you, I don't know what possibly could. – Luis Casillas Apr 13 '17 at 1:12
  • 3
    @rook: It's been a while since this conversation, but I've updated my answer with a link to a real-life example of an insecure random UUID generator. – Luis Casillas Jul 21 '17 at 18:39

You're just describing a scheme where the UUID simply becomes a password.

There's nothing especially secure or insecure about this, aside from no person ever going to be able to pick a "weak" password, but on the other hand, half of the people going to store their password unencrypted.

I don't really see why you'd do this to people. You're not going to make yourself very popular by denying amateurs the chance to pick a password they can remember nor experts the chance to generate one they deem secure themselves.

Also, I personally think individual bank account passwords are worth way less (considering banks have been 2-factoring wire transfers, at least in Europe, since more than 25 years now with transaction ID one time pads) than domain control (I can hardly ruin someone's business by looking at his bank account unless I plan to use it to mess with him based on other info, but I can easily ruin him by rerouting all his email through my servers by manipulating the MX record of their domain, and selectively letting through CEO mail and answering in their place. Oh, and you know, if they have an online business, actually abuse their web presence to the fullest extent).


Given the above, is this still a bad idea?

Yes, inventing new auth schemes is usually a bad idea.

Do you think this is less secure than username / pass?

Depends on your clients, and as usual, on your attack scenario.

Would slamming two UUIDs together be more secure?

It would lead to longer random sequences, so yes, but then, why not use a longer random sequence from the start?

This all feels like you didn't think this through.

| improve this answer | |
  • Thanks Marcus. Again, the user experience isn't the concern at the moment. I'm fully aware of the downside. Appreciate the answer. – legeek Apr 13 '17 at 0:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.