Developer tools · UUID generator
Version 1 UUIDs Can Leak Your MAC Address and Creation Time
· Why it matters
uuid cryptography browser-apis
A time-based UUID embeds a 60-bit timestamp and a 48-bit node identifier that is often a real network card address. This post shows what an outsider can read from one and why random generation avoids the problem.
The identifier that names your laptop — why an ID in an exported document can be more than an ID
A version 1 UUID is constructed from a timestamp, a MAC address and a clock sequence value. The 60-bit timestamp represents the number of 100-nanosecond intervals since 15 October 1582, the date of Gregorian calendar reform. The 48-bit node field traditionally contains the IEEE 802 MAC address of the network interface that generated the UUID. When you export a document, run a tool or save a file that embeds a version 1 UUID, anyone who later decodes that UUID can read when it was created and, if the node field is a real MAC address, which machine created it. This information leaks silently from what appears to be an opaque identifier.
Anatomy of a v1 UUID — the timestamp fields, the clock sequence and the node field, and where each sits in the 36 characters
The information leak is subtle but consequential for privacy and attribution. If you collaborate with a co-author on a document and your network card's MAC address is in the embedded v1 UUIDs, an observer learns the hardware in use at a particular institution or location. If you export a document at a specific time, the timestamp in every v1 UUID bounds when the work occurred. An author trying to maintain pseudonymity can be deanonymized by correlating the UUID timestamp with known publication dates or document-creation events. The identifiers appear innocuous because they are formatted as opaque 36-character strings, but they are not opaque at all to anyone who knows the v1 format and cares to decode them.
What an observer learns — when the record was created and, if the node is a hardware address, which machine or vendor created it
The anatomy of a v1 UUID clarifies what can be extracted because the structure is deterministic and publicly documented. RFC 9562 defines the layout: 32 bits for time_low, 16 bits for time_mid, 4 bits for version set to 1, 12 bits for time_high, 2 bits for variant, 14 bits for clock_seq and 48 bits for node. The time fields comprise 60 bits total, which when combined and interpreted as 100-nanosecond intervals since 1582 yield the exact creation instant to within 100 nanoseconds. The 48-bit node field usually holds the MAC address as a 48-bit integer. Decoding is deterministic: read the bytes, mask and shift the fields and interpret the values. No cryptography is involved; the UUID structure makes the encoding completely transparent and reversible.
A cautionary history — how identifiers embedded in documents have been used to trace authorship, described without speculation
RFC 9562 acknowledges the privacy history and recommends against v1 for new applications because the costs outweigh the benefits. The specification includes v4 random and v7 time-ordered alternatives with privacy considerations documented. Version 1 is retained for backward compatibility with deployed systems, but new code should not generate v1 UUIDs without careful security review and explicit justification for the exposure. The vulnerability was not an oversight; it was a deliberate design choice in the 1980s when privacy leaks were not primary concerns and tracking was an acceptable feature for distributed system identification.
Worked example — decoding a sample v1 UUID by hand into its timestamp and node fields
The timeline is important for understanding exposure because a v1 UUID in a document created in 1998 includes a timestamp encoding 1998-era time, which is useful for forensics but is the problem itself. If you have historical documents with v1 UUIDs and you later share them, the timestamps persist. You cannot retroactively remove the historical fact that a UUID was generated at a certain time; you can only stop generating new v1 UUIDs. Some applications tried to mitigate the MAC address leak by replacing the real MAC with a random pseudonym, but the timestamp remains fully readable and decodable.
What v4 and v7 change — random UUIDs carry no machine data; v7 still reveals creation time, which may or may not be acceptable
A worked example shows decoding in practice using RFC 9562 example vectors. Take a v1 UUID like f81d4fae-7dec-11d0-a765-00a0c91e6bf6 from the specification. The bytes in order are f81d4fae 7dec 11d0 a765 00a0c91e6bf6. The version field is in the third group: 11d0 in hex is 0001 0001 1101 0000 in binary. The first 4 bits are 0001, which is version 1. The timestamp is split across the first, second and part of the third group: time_low is f81d4fae in decimal 4170404526, time_mid is 7dec in decimal 32236, time_high is 1d0 from the third group after removing the version nibble in decimal 464. Combining these into a 60-bit value gives a number representing 100-nanosecond intervals since 1582.
What this does not cover — the randomised node option some v1 implementations offer, which mitigates but does not remove the timestamp leak
The node field in the fourth and fifth groups is a765 00a0c91e6bf6, which encodes machine information if bit 0 indicates authenticity. If the least significant bit of the first octet of the node field is zero, it indicates a real IEEE address; if set to one, it indicates a pseudorandom value generated for privacy. In this example, a765 in hex is 10100111 01100101 in binary; the least significant bit is 1, so this is a random pseudonode, not a real MAC. However, older implementations sometimes stored real MAC addresses directly, and if they did, the 48-bit node field decodes to a network card identifier. IEEE maintains a registry of MAC prefixes; knowing that a network card began with a certain prefix narrows down the manufacturer and potentially the model of computer in use.
Takeaway: know what your IDs disclose — the ToolAcre generator draws every identifier from the CSPRNG, so there is no MAC address or timestamp to leak
RFC 9562 version 4 and beyond deliberately avoid this leak by using only random data rather than encoded information. A version 4 UUID is 122 bits of cryptographically random data with 4 bits for the version field and 2 bits for the variant field. Reading the bits reveals nothing except that the UUID is valid; there is no timestamp to decode, no machine data to extract. Version 7 includes a timestamp for sorting benefits but that timestamp is derived from Unix epoch familiar and standardized rather than the obscure 1582-based value, and the specification explicitly documents that time information is present in the identifier. The privacy properties differ fundamentally between versions.