Entwicklertools · UUID Generator
Namensbasierte UUIDs (v3 und v5): Deterministische IDs aus einem Namespace
· Hintergrund
UUID Kryptographie Browser-APIs
Wenn derselbe externe Datensatz immer die gleiche Kennung erhalten muss, reichen zufällige UUIDs nicht aus. UUIDs der Versionen 3 und 5 hashen einen Namespace und einen Namen in eine stabile ID; In diesem Beitrag wird erklärt, wie und wann man sie verwendet.
Den gleichen Kunden zweimal erneut importieren – das Duplizierungsproblem, das deterministische IDs lösen
Eine Datenimportpipeline empfängt Kundendatensätze von einem externen System mit stabilen externen IDs in diesem System. Wenn Sie für jeden Importlauf ein neues zufälliges UUID generieren, führt der zweimalige Import desselben Kunden zu zwei unterschiedlichen Kennungen und doppelten Datensätzen. Diese Duplizierung fließt in die Berichts-, Abrechnungs- und Supportsysteme ein. Wenn Sie ein UUID aus der externen ID des Kunden und einem stabilen Namespace ableiten, der Ihre Importquelle darstellt, erzeugt jeder Import dasselbe UUID für denselben Kunden, sodass Sie vorhandene Datensätze identifizieren und aktualisieren können. Dieser Determinismus ist das bestimmende Merkmal von v3- und v5-UUIDs: Sie werden nicht unabhängig generiert, sondern von Eingaben abgeleitet, und dieselbe Eingabe erzeugt immer den identischen UUID.
Namespace plus Name – wie die Eingabe verkettet und gehasht wird und warum der Namespace Kollisionen zwischen verschiedenen Quellen verhindert
Ein v3- oder v5-UUID wird aus drei Komponenten abgeleitet: einem Namespace UUID (normalerweise vordefiniert), einem Namen (beliebige Bytezeichenfolge) und einem Hash-Algorithmus (MD5 für v3, SHA-1 für v5). Verketten Sie die 16 Bytes des Namespace UUID mit den UTF-8 Bytes des Namens, hashen Sie die Verkettung, nehmen Sie die ersten 16 Bytes der Hash-Ausgabe und interpretieren Sie diese Bytes als UUID, wobei das Versionsnibble auf 3 gesetzt ist. oder 5. Der Namespace partitioniert den ID-Raum: v5-UUIDs aus dem DNS-Namespace kollidieren nie mit v5-UUIDs aus dem URL-Namespace. RFC 9562 definiert vier vordefinierte Namespaces: nach DNS-Namen, nach URL, nach OID und nach X.500 Distinguished Name. Organisationen können ihren eigenen Namespace prägen, indem sie einen v4 UUID generieren.
MD5 in v3 und SHA-1 in v5 – warum ein geschwächter Hash hier akzeptabel ist, da die ID keine Sicherheitskontrolle darstellt
Version 3 verwendet MD5 und Version 5 verwendet SHA-1, Auswahlmöglichkeiten, die auf ihre Spezifikationsdaten und verfügbaren Implementierungen zurückgehen. Für namensbasierte UUIDs ist diese Unterscheidung unerheblich, da die Hash-Funktion keine Sicherheitsgrenze oder kryptografische Kontrolle darstellt. Der UUID beweist weder Authentizität noch Integrität; Es wird lediglich eine Zeichenfolge variabler Länge in einen festen 128-Bit-Wert umgewandelt. Das Angriffsmodell ist irrelevant, da UUIDs als undurchsichtige Werte gespeichert und verglichen werden, nicht als Beweise oder Sicherheitskontrollen. Neue Implementierungen sollten v5 (SHA-1) anstelle von v3 (MD5) verwenden, nicht aus zwingenden Sicherheitsgründen, sondern weil v5 der moderne Standard und allgemein verfügbar ist.
Die vordefinierten Namespaces – DNS, URL, OID und X.500 und wann Sie Ihre eigenen erstellen sollten
RFC 9562 gibt genau vier vordefinierte Namespace-UUIDs mit spezifischen Byte-Darstellungen an: 6ba7b810-9dad-11d1-80b4-00c04fd430c8 für DNS, 6ba7b811-9dad-11d1-80b4-00c04fd430c8 für URLs, 6ba7b812-9dad-11d1-80b4-00c04fd430c8 für OIDs und 6ba7b814-9dad-11d1-80b4-00c04fd430c8 für X.500 Distinguished Names. Ein v5-UUID, der vom DNS-Namespace und dem Namen www.example.com abgeleitet ist, ist immer identisch und kollidiert niemals mit einem v5-UUID aus dem URL-Namespace. Die Verwendung eines vordefinierten Namespace gewährleistet die Interoperabilität: Wenn mehrere Teams unabhängig voneinander v5 mit dem DNS-Namespace verwenden, generieren sie identische UUIDs für dieselben DNS-Namen. Das Auswählen oder Prägen eines Namespace ist Teil des Schemadesigns.
Ausgearbeitetes Beispiel – konzeptionelle Ableitung eines v5 UUID aus dem URL-Namespace und einer Datensatz-URL, Schritt für Schritt
Leiten Sie einen v5 UUID konzeptionell aus dem URL-Namespace und dem Namen https://example.com/api/users/42. ab. Der Namespace UUID als 16 Bytes ist 6b a7 b8 11 9d ad 11 d1 80 b4 00 c0 4f d4 30 c8. Der Name ist die Zeichenfolge UTF-8 https://example.com/api/users/42,, die 30 Bytes umfasst. Verketten Sie die Namespace-Bytes (16) und Namensbytes (30), um insgesamt 46 Bytes zu erhalten. Berechnen Sie den SHA-1-Hash und erzeugen Sie einen 20-Byte-Hash. Nehmen Sie die ersten 16-Bytes und interpretieren Sie sie als UUID, wobei das Versionsnibble auf 5 und die Variantenbits auf den RFC-Standard gesetzt sind. Eine erneute Berechnung mit identischen Eingaben führt zum identischen Ergebnis. Die meisten Entwickler verwenden ihre Sprachbibliothek UUID, um v5 zu berechnen.
Wo das Muster bricht – wenn sich Namen ändern, wenn der Namespace zwischen den Teams inkonsistent ist und wenn Eingaben geheim sind
Namensbasierte UUIDs gehen davon aus, dass der Name über Systeme und Importläufe hinweg stabil und konsistent ist. Wenn derselbe externe Datensatz in verschiedenen Systemen unterschiedliche Namen hat, führt die Generierung von v5 aus jedem Namen zu unterschiedlichen UUIDs und die Identifizierung derselben Person ist fehlgeschlagen. Wenn sich die Teams nicht auf einen Namensraum einigen (jedes Team prägt seinen eigenen Namensraum für die tatsächlich gleiche Quelle), generieren sie unterschiedliche UUIDs und stimmen nicht mit den Datensätzen überein. Wenn es sich bei der Eingabe um vertrauliche Daten handelt, bedeutet die Generierung eines v5-UUID, dass UUID ein öffentlicher, deterministischer Wert ist, den jeder nachschlagen kann, wenn er die Eingaben kennt. Der Determinismus wird unterbrochen, wenn sich Eingaben ändern oder Namespacedefinitionen inkonsistent sind.
Was dies nicht abdeckt – der ToolAcre-Generator greift auf das CSPRNG zurück, daher benötigen namensbasierte IDs die UUID-Bibliothek Ihrer Sprache
ToolAcre generiert aus Unabhängigkeitsgründen nur v4-UUIDs, die aus dem kryptografisch sicheren Generator des Browsers stammen. Für die namensbasierte UUID-Ableitung ist Ihre Sprachbibliothek UUID oder eine Implementierung erforderlich, die SHA-1 berechnet und das Ergebnis korrekt formatiert. In diesem Beitrag werden das Konzept und die Anwendungsfälle erläutert. Die Implementierung der v5-Generierung ist in jeder Sprache mit Zugriff auf standardmäßige kryptografische Bibliotheken unkompliziert. Die Mechanik der v5-Ableitung ist einfach; Die Herausforderung besteht darin, es in ein Systemschema zu integrieren, in dem der Namespace stabil, der Name konsistent und der Ansatz für Ihr Team gut dokumentiert ist. Entwicklungsteams sollten die Auswahl von Namespaces dokumentieren.
Takeaway: deterministisch, wenn Sie es brauchen, ansonsten zufällig – verwenden Sie v5 für stabile Zuordnungen und den ToolAcre-Generator für alles, was unvorhersehbar sein sollte
Verwenden Sie v5 für stabile Zuordnungen zwischen externen Identifikatoren und Ihren internen Datensätzen. Der Determinismus verhindert doppelte Importe und macht den systemübergreifenden Abgleich von Datensätzen einfach und zuverlässig. Verwenden Sie keine namensbasierten UUIDs für Kennungen, die nicht erraten werden müssen, oder für Szenarien, die strenge Vertraulichkeit und Geheimnisse erfordern. ToolAcre generiert zufällige v4-UUIDs für Bezeichner, die unabhängig und eindeutig ohne Vorhersagbarkeit sein müssen. Wenn Ihre Systeme deterministische IDs benötigen, die Eingaben festen Bezeichnern zuordnen, kann Ihre Sprachbibliothek UUID diese berechnen. Determinismus ist eine leistungsstarke Funktion, wenn Sie die Eingabe steuern.