UUID-Generator

So funktioniert der UUID-Generator

Der UUID-Generator erzeugt eine oder bis zu 100 UUIDs auf einmal, Universally Unique Identifier nach Version 4 und RFC 4122, also 36 Zeichen in der Form 8-4-4-4-12 aus Hexadezimalziffern, bei denen 122 der 128 Bit zufällig sind und die restlichen sechs Version und Variante kennzeichnen. Die Erzeugung läuft im Browser mit dem kryptografischen Zufallsgenerator, nichts wird übertragen, und die Liste lässt sich mit einem Klick kopieren, für Primärschlüssel in Datenbanken, IDs in APIs, Dateinamen, Sitzungen und alles, was weltweit eindeutig sein muss, ohne dass sich jemand abstimmt.

Merksatz: Eine UUID ist eine 128-Bit-Zahl, so groß, dass zwei zufällige Exemplare praktisch nie gleich sind, auch wenn Millionen Rechner gleichzeitig welche erzeugen. Die Eselsbrücke: Die dritte Gruppe beginnt mit 4, die vierte mit 8, 9, a oder b, daran erkennt man die Version 4.

Drei Beispiele:

• Eine UUID: etwa efb58ad6-a196-4ae9-aeac-44501a780dd6, mit der 4 an der ersten Stelle der dritten Gruppe und dem a an der ersten Stelle der vierten.
• Fünf UUIDs: fünf Zeilen zum Kopieren, jede mit 32 Hexziffern und vier Bindestrichen, jede anders, jede 2 hoch 122 Möglichkeiten.
• 100 UUIDs: die Obergrenze je Durchgang, für Testdaten und Seeds; die Wahrscheinlichkeit einer Kollision unter 100 ist so klein, dass sie sich nicht sinnvoll ausdrücken lässt.

Regeln statt Formeln: 128 Bit, 32 Hexziffern, Format 8-4-4-4-12, Version 4: 122 Zufallsbits, Versionsnibble 4, Variantenbits 10xx, Kollision: erst bei etwa 2,7 Trillionen UUIDs liegt die Wahrscheinlichkeit bei 50 Prozent. Zufällige Zeichenketten mit wählbaren Zeichen und Längen erzeugt der Passwort-Generator, und Fingerabdrücke aus vorhandenen Daten der Hash-Generator.

Wissenswertes zum Thema

Was eine UUID ist und warum sie eindeutig ist

Eine UUID, in Microsoft-Welt GUID, ist eine 128-Bit-Zahl, geschrieben als 32 Hexadezimalziffern in fünf Gruppen, und ihr Zweck ist Eindeutigkeit ohne zentrale Vergabe: Zwei Datenbanken, zwei Geräte, zwei Teams können unabhängig voneinander IDs erzeugen und sie später zusammenführen, ohne dass sich zwei überschneiden, was mit fortlaufenden Nummern 1, 2, 3 unmöglich wäre. Die Version 4 erreicht das durch Zufall: 122 Bit werden gewürfelt, 2 hoch 122 sind 5,3 Sextillionen Möglichkeiten, eine Zahl mit 37 Stellen, und nach dem Geburtstagsparadoxon liegt die Wahrscheinlichkeit, dass unter n erzeugten UUIDs zwei gleich sind, bei n zum Quadrat durch 2 hoch 123, so dass erst bei 2,7 Trillionen UUIDs, 2,7 mal 10 hoch 18, die Hälfte erreicht ist; wer eine Milliarde UUIDs je Sekunde erzeugt, braucht dafür 86 Jahre, und bei einer Milliarde insgesamt liegt die Kollisionswahrscheinlichkeit bei 1 zu 10 hoch 19. Die sechs festen Bits stehen an zwei Stellen: Die erste Hexziffer der dritten Gruppe ist die Versionsnummer, 4, und die erste Hexziffer der vierten Gruppe trägt die Variante nach RFC 4122, Bits 10, also 8, 9, a oder b, weshalb jede gültige v4-UUID an diesen beiden Stellen erkennbar ist. Das Tool nutzt crypto.randomUUID oder crypto.getRandomValues, den kryptografisch sicheren Zufall des Browsers, nicht Math.random, so dass die UUIDs auch für Sitzungs-Tokens taugen, sofern sie geheim bleiben; eine UUID ist eine Kennung, kein Geheimnis, und wer sie in Adressen zeigt, zeigt sie allen. Die Schreibweise ist in Kleinbuchstaben nach RFC üblich, Großbuchstaben sind gleichwertig, und die Bindestriche sind Konvention, viele Datenbanken speichern die 16 Bytes binär. Wie zufällig der Browserzufall ist und was ihn vom Würfeln unterscheidet, beschreibt der Zufallszahl-Generator.

Die Versionen: 1, 4, 5 und das neue 7

Version 1 von 1997 baut die UUID aus Zeitstempel und MAC-Adresse der Netzwerkkarte, eindeutig durch Zeit und Hardware, aber mit zwei Haken, sie verrät, wann und auf welchem Gerät sie entstand, und sortiert sich schlecht, weil die Zeit in der Mitte steht; Version 2 ist eine DCE-Variante ohne Verbreitung. Version 3 und 5 sind deterministisch: Aus einem Namensraum und einem Namen entsteht per MD5 oder SHA-1 immer dieselbe UUID, nützlich, wenn aus "example.com" oder einer Artikelnummer eine stabile ID werden soll, die zwei Systeme unabhängig berechnen. Version 4 ist die zufällige, die das Tool erzeugt, seit 2005 standardisiert und die mit Abstand verbreitetste, in Java, Python, PostgreSQL, JavaScript und jedem Framework eingebaut. Version 7, seit Mai 2024 in RFC 9562 standardisiert, ist die Antwort auf den größten Nachteil von v4: Zufällige Schlüssel in einer Datenbank verteilen neue Einträge über den ganzen Index und machen Einfügen und Suchen bei Millionen Zeilen langsam, weil nichts beieinanderliegt; v7 setzt die ersten 48 Bit auf den Unix-Zeitstempel in Millisekunden und füllt den Rest mit Zufall, so dass die UUIDs chronologisch sortieren, wie eine fortlaufende Nummer, aber ohne Abstimmung, und PostgreSQL 18, MySQL und die meisten Sprachen unterstützen sie inzwischen. Für Datenbankschlüssel ist v7 heute die bessere Wahl, für alles, bei dem die Entstehungszeit nicht sichtbar sein soll, v4, für stabile IDs aus Namen v5, und v1 nur noch aus Altsystemen. Die Nil-UUID aus 32 Nullen und die Max-UUID aus 32 f sind reserviert. Was ein Zeitstempel in Millisekunden ist, aus dem v7 seine ersten 48 Bit bezieht, erklärt der Unix-Timestamp-Rechner.

Typische Fehler im Umgang mit UUIDs

Der erste Fehler ist die UUID als Passwort oder Token, der mit Math.random erzeugt wurde; der Browserzufall des Tools ist sicher, aber viele Bibliotheken und alte Generatoren nicht, und ein vorhersagbarer Token ist keiner. Der zweite ist die UUID als Sicherheitsmerkmal, "die URL errät niemand", was für v4 stimmt, solange die UUID nicht in Logs, Referrer-Headern und Browserverläufen landet, was sie tut. Der dritte ist v4 als Primärschlüssel in großen Tabellen ohne Nachdenken, mit fragmentierten Indizes und 36 Byte Text statt 16 Byte binär je Zeile; v7 und der UUID-Typ der Datenbank lösen das. Der vierte ist die Prüfung nur auf Format, eine Zeichenkette in 8-4-4-4-12 ist nicht automatisch eine UUID nach RFC, Version und Variante müssen stimmen. Der fünfte ist das Kürzen, "die ersten acht Zeichen reichen", 32 Bit sind nach rund 80.000 Stück mit 50 Prozent Wahrscheinlichkeit kollidiert. Der sechste ist der Groß-Klein-Vergleich, "ABC…" und "abc…" sind dieselbe UUID, und ein Textvergleich sieht zwei. Der siebte ist die Annahme, v1 sei anonym, sie enthält die MAC-Adresse. Der achte ist das Erzeugen von UUIDs in Schleifen für Testdaten mit demselben Seed, alle gleich. Und der neunte ist die Verwechslung mit Hashes, eine UUID entsteht aus Zufall oder Zeit, ein Hash aus Daten, und nur v3 und v5 sind beides. Wie ein Hash aus Daten entsteht und warum er nie zufällig ist, zeigt der Hash-Generator.

Ein Stück Geschichte: Von Apollo-Workstations zum RFC 9562

Die UUID stammt aus dem Network Computing System der Firma Apollo Computer in Massachusetts, die um 1985 Workstations vernetzte und für ihre Objekte Kennungen brauchte, die auf jedem Rechner ohne Absprache eindeutig waren; die Lösung aus Zeitstempel und Netzwerkadresse wanderte 1989 in das Distributed Computing Environment der Open Software Foundation, das DCE, und von dort nach Microsoft, das sie 1993 als GUID für COM und die Windows-Registry übernahm, weshalb jeder Windows-Rechner Zehntausende davon enthält. Paul Leach, der bei Apollo und dann bei Microsoft arbeitete, schrieb mit Rich Salz 1997 den ersten Internetentwurf und 2005 den RFC 4122, der die Versionen 1 bis 5 festlegte und die zufällige Version 4 zur Standardwahl machte, als Rechenleistung und Zufallsquellen für 122 Bit je ID selbstverständlich wurden. Die Datenbankwelt nahm die UUID ab 2000 als Primärschlüssel an, PostgreSQL mit eigenem Typ seit 2007, und mit den verteilten Systemen der 2010er, Microservices, Mobile Apps, die offline Datensätze anlegen, wurde sie zum Standard, weil fortlaufende Nummern dort nicht mehr funktionieren. Die Klagen über zufällige Schlüssel in Indizes führten ab 2016 zu Alternativen wie ULID und Snowflake-IDs von Twitter, und 2024 übernahm RFC 9562 die Idee als Version 7 in den Standard, 27 Jahre nach dem ersten Entwurf. Die Funktion crypto.randomUUID, die das Tool nutzt, kam 2021 in die Browser. Der Generator würfelt, was Apollo 1985 noch aus der Uhr und der Netzwerkkarte zusammensetzte.

Praktische Tipps

Nehmen Sie v4 für Kennungen, die keine Zeit verraten sollen, v7 für Datenbankschlüssel, v5 für stabile IDs aus Namen. Speichern Sie UUIDs binär oder im UUID-Typ, nicht als 36-Zeichen-Text. Vergleichen Sie ohne Beachtung der Groß- und Kleinschreibung. Kürzen Sie UUIDs nie. Nutzen Sie sie nicht als Geheimnis, sie stehen in jedem Log. Prüfen Sie Eingaben auf Version und Variante, nicht nur auf das Muster. Erzeugen Sie Testdaten mit dem Tool, bis zu 100 je Durchgang. Und lassen Sie v1 in Altsystemen, wo sie ist. Zufällige Zeichenketten anderer Form, etwa API-Schlüssel mit 32 Zeichen, erzeugt der Passwort-Generator.