UUID() returns a value that conforms to UUID version 1 as described in RFC 4122. The value is a 128-bit number represented as a utf8 string of five hexadecimal numbers in aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee format:
The first three numbers are generated from the low, middle, and high parts of a timestamp. The high part also includes the UUID version number.
The fourth number preserves temporal uniqueness in case the timestamp value loses monotonicity (for example, due to daylight saving time).
The fifth number is an IEEE 802 node number that provides spatial uniqueness. A random number is substituted if the latter is not available (for example, because the host device has no Ethernet card, or it is unknown how to find the hardware address of an interface on the host operating system). In this case, spatial uniqueness cannot be guaranteed. Nevertheless, a collision should have very low probability.
The MAC address of an interface is taken into account only on FreeBSD and Linux. On other operating systems, MySQL uses a randomly generated 48-bit number.
I don't know if MySQL has built-in UUIDv4 though. pg does.
We really ought to use names for them, not version numbers. If someone wrote "Timestamp-based UUIDs Are Not Fully Random", well, by the time you've typed out the title of your blog post you'd have figured out what the problem was.
I'd prefer to use letters in cases like this. Letters have a much weaker association with ordering, there's no implication that the set is of infinite size, and there's no affordance for doing anything arithmetic with them except enumerating them.
For example, a plain old USB cable has an "A" and "B" ends, radiation can be alpha/beta/gamma, and power outlets can be type A, B, C, ... (it looks like they're up to "N" now). Nobody would think that a Danish "type K" plug is 9 versions improved on an American "type B" plug. It's just different.
Are you sure? If they have the number I always see a "v" in front of it.
It was relatively painless, sure, but I seem to remember having to add it.
/dev/urandom does not produce such non-random results; the comparison is rather far-fetched. /dev/urandom is suitable for virtually all tasks, including cryptography. It's the same as /dev/random on various BSDs, even.
No, the lesson here is to not assume a "random" function is cryptographically secure unless stated otherwise. The same article could be made about Math.random or rand.
Or if you have an application installed on personal machines, it's leaking identifying information about those machines.
Since when someone on earth has recommended something like that?
UUIDs are time/mac address sensitive. They have version info within. They make an awful, guessable secret. It's just that: An unique identifier across the globe and not just your database.
Why would you ever assume that? UUIDs could be formed from a low-entropy LCGRNG and still match the specifications.
Any secret should be generated with cryptographically secure random number generators. Calling "UUID" instead of like, BCrypt or something would be a major red flag to me. Heck, a modern cryptographically secure secret can be generated from Intel's "RDSEED" assembly instruction, which provides a hardware-random source of entropy, as well as entropy guarantees. (You'll probably use this assembly instruction if you are using /dev/urandom)
As always, it's the programmer's duty to investigate the RNG before relying on the entropy of some function's result.
UUIDs based on a CSPRNG and used as a password/token have some nice features--they're of fixed length, easy to validate for well-formedness, easy to serialize or deserialize in a variety of conventions.
Take a Version 1 UUID (time-based), and spin it through a 128-bit LCGRNG. Do the AND / OR bitmasks needed to properly tag it a Version4 UUID and you're done. Bam, universally unique but not cryptographically random.
This would be very fast (cryptographic entropy is very slow!), and would be ideal for databases or most purposes.
In our case it wasn't a problem, but I couldn't help thinking that this was a nice information leak where you could find out some property of a dataset that was never intended to be retained. Just imagine that you mobile sign-ups had one kind of UUID and your web sign-ups the other kind. Though you might not explicitly store the information how someone signed up you inadvertently really do.
And now if you are tempted to ask why we stored our UUIDs as strings - just don't...
UUID VARIANT TYPE TIME
4f95de28-0fd1-48db-ad2e-34ecd169c483 DCE random
4331cb9e-1d91-11e9-be2c-45923c63e8a2 DCE time-based 2019-01-21 17:28:54,631107+02:00
4331cc4c-1d91-11e9-be2c-45923c63e8a2 DCE time-based 2019-01-21 17:28:54,631124+02:00
c7e2f124-f6ba-4434-843f-89958a7436ec DCE random
3e18f8dd-b1d3-4e16-8a81-4bdceac91772 DCE random
DCE The Open Software Foundation's (OSF) Distributed Computing Environment UUIDs.
time-based The DCE time based.
random RFC 4122 random.
I've never used UUIDs for secrets, but I've often dependended on UUIDs to be uniform - as the primary identifier when passing data around inside distributed systems. If the chance of collision is implementation dependent, that could end really badly.
TIL only version 4 is generated using a random source.
Thing for example getDocById.php?id=...
Of course it does not have to be UUID, but this can have some benefits as you DB for example may have a nice datatype for it.
* One that is better served with a UUID than a random binary blob.
For example, a company I used to work for named IntegriShield is essentially a for-hire private Internet police company. When I got there, we would take an automatic screenshot of a web site and then send it to the people who were doing something "bad" (for whatever the definition of "bad" was) and you would essentially visit some sort of link like
One of my jobs there was to improve this process: reduce image storage costs and increase the productivity of the humans who had to look at these web sites to determine what had gone wrong. With my contribution, we could intelligently flag language that might be "bad" and then capture enough metadata that we could later reconstruct screenshots which highlighted those "bad" things, after a human being had looked at them and said "no, these things are okay but those things really are bad" and deleted half of our highlights. So the screenshots were now only generated after we were done and clearly highlighted what was wrong, and then it becomes a serious problem if folks from one of these companies can see what their peers are doing.
We did not switch to UUIDs but rather just encrypted the counter with a server key, but the point is still that you would now visit
UUIDs v4 (chosen securely randomly) have the same properties from the very start. You can easily use them in cases where the security model demands that some non-client must be able to access some sort of information simply by knowing the identifier.
We could have chosen something more complicated, of course, like creating a many-to-many table relating screenshots to email addresses and then embedding the email address somehow in the URL,
In other words, you shouldn't use a non-cryptographic RNG for security purposes.
There are different types of UUIDs . MySQL generates version 1 UUIDs - you can tell by the first digit of the third block. It looks like something else is also generating UUIDs, using the v4 format - so you have two different types of UUID in your database:
4331cb9e-1d91-11e9-be2c-45923c63e8a2 # v1
c7e2f124-f6ba-4434-843f-89958a7436ec # v4
v1 UUIDs are typically based on the MAC address of your computer and the current time. Online tools exist  that decode the uuid and tell you it was created at 2019-01-21 10:28:55 (UTC)
v4 UUIDs are random.
V4 UUIDs are supposed to be random.
"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."
You can't assume, but you can certainly check for a given implementation. Plenty of implementations do provide secure randomness, e.g. Ruby's SecureRandom.
Regardless of what method you use to generate secrets, someone could later change the code to generate the same secret using a non-cryptographically-secure RNG. By that logic, alphanumeric strings should not be used as secrets either.
There are a million things that get posted on Hacker News that are "beginner level". How many tutorials have we gotten about Rust on here? I don't think that's a bad thing.
They are certainly useful for creating unique id's, but for randomness? No.