Strumenti per sviluppatori · Generatore UUID
UUID basati sul nome (v3 e v5): ID deterministici da uno spazio dei nomi
· Sfondo
uuid crittografia API del browser
Quando lo stesso record esterno deve avere sempre lo stesso identificatore, gli UUID casuali non vanno bene. Gli UUID della versione 3 e 5 eseguono l'hashing di uno spazio dei nomi e di un nome in un ID stabile; questo post spiega come e quando usarli.
Reimportare lo stesso cliente due volte: il problema della duplicazione risolto dagli ID deterministici
Una pipeline di importazione dati riceve i record dei clienti da un sistema esterno con ID esterni stabili all'interno di quel sistema. Se generi un nuovo UUID casuale per ogni esecuzione di importazione, l'importazione dello stesso cliente due volte produce due identificatori diversi e record duplicati. Questa duplicazione scorre a valle nei sistemi di reporting, fatturazione e supporto. Se ricavi un UUID dall'ID esterno del cliente e uno spazio dei nomi stabile che rappresenta la tua origine di importazione, ogni importazione produce lo stesso UUID per lo stesso cliente, consentendoti di identificare e aggiornare i record esistenti. Questo determinismo è la caratteristica distintiva degli UUID v3 e v5: non sono generati in modo indipendente ma derivati da input e lo stesso input produce sempre l'identico UUID.
Spazio dei nomi più nome: come l'input viene concatenato e sottoposto ad hashing e perché lo spazio dei nomi impedisce collisioni tra origini diverse
Un UUID v3 o v5 deriva da tre componenti: uno spazio dei nomi UUID (tipicamente predefinito), un nome (qualsiasi stringa di byte) e un algoritmo hash (MD5 per v3, SHA-1 per v5). Concatenare il 16 bytes dello spazio dei nomi UUID con i UTF-8 byte del nome, eseguire l'hashing della concatenazione, prendere il primo 16 bytes dell'output hash e interpretare tali byte come UUID con il nibble della versione impostato su 3 o 5. Lo spazio dei nomi suddivide lo spazio degli ID: gli UUID v5 dello spazio dei nomi DNS non entrano mai in conflitto con gli UUID v5 dello spazio dei nomi URL. RFC 9562 definisce quattro spazi dei nomi predefiniti: per nome DNS, per URL, per OID e per X.500 nome distinto. Le organizzazioni possono creare il proprio spazio dei nomi generando un file v4 UUID.
MD5 in v3 e SHA-1 in v5: perché qui è accettabile un hash indebolito, poiché l'ID non è un controllo di sicurezza
La versione 3 utilizza MD5 e la versione 5 utilizza SHA-1, scelte risalenti alle date delle specifiche e alle implementazioni disponibili. Per gli UUID basati sul nome, questa distinzione non è rilevante perché la funzione hash non è un limite di sicurezza o un controllo crittografico. Il UUID non dimostra l'autenticità o l'integrità; sta semplicemente convertendo una stringa di lunghezza variabile in un valore fisso di 128bit. Il modello di attacco è irrilevante perché gli UUID vengono archiviati e confrontati come valori opachi, non come prove o controlli di sicurezza. Le nuove implementazioni dovrebbero utilizzare la v5 (SHA-1) anziché la v3 (MD5), non per motivi di sicurezza convincenti ma perché v5 è lo standard moderno e ampiamente disponibile.
Gli spazi dei nomi predefiniti: DNS, URL, OID e X.500 e quando coniarne uno tuo
RFC 9562 specifica esattamente quattro UUID dello spazio dei nomi predefiniti con rappresentazioni di byte specifiche: 6ba7b810-9dad-11d1-80b4-00c04fd430c8 per DNS, 6ba7b811-9dad-11d1-80b4-00c04fd430c8 per gli URL, 6ba7b812-9dad-11d1-80b4-00c04fd430c8 per gli OID e 6ba7b814-9dad-11d1-80b4-00c04fd430c8 per X.500 nomi distinti. Un UUID v5 derivato dallo spazio dei nomi DNS e il nome www.example.com saranno sempre identici e non entreranno mai in conflitto con un v5 UUID dallo spazio dei nomi URL. L'utilizzo di uno spazio dei nomi predefinito garantisce l'interoperabilità: se più team utilizzano in modo indipendente la v5 con lo spazio dei nomi DNS, generano UUID identici per gli stessi nomi DNS. La scelta o la creazione di uno spazio dei nomi fa parte della progettazione dello schema.
Esempio pratico: derivare concettualmente un v5 UUID dallo spazio dei nomi URL e un record URL, passo dopo passo
Derivare concettualmente un v5 UUID dallo spazio dei nomi URL e dal nome https://example.com/api/users/42. Lo spazio dei nomi UUID poiché 16 bytes è 6b a7 b8 11 9d ad 11 d1 80 b4 00 c0 4f d4 30 c8. Il nome è la stringa UTF-8 https://example.com/api/users/42, che è 30 bytes. Concatena i byte dello spazio dei nomi (16) e i byte del nome (30) per ottenere 46 bytes totale. Calcola l'hash SHA-1, producendo un hash di 20 byte. Prendi il primo 16 bytes e interpretalo come UUID con il bocconcino della versione impostato su 5 e i bit della variante impostati su RFC standard. Calcolarlo nuovamente con input identici produce lo stesso risultato. La maggior parte degli sviluppatori utilizza la libreria UUID del linguaggio per calcolare la versione v5.
Dove lo schema si interrompe: quando i nomi cambiano, quando lo spazio dei nomi non è coerente tra i team e quando gli input sono segreti
Gli UUID basati sul nome presuppongono che il nome sia stabile e coerente tra i sistemi e le esecuzioni di importazione. Se lo stesso record esterno ha nomi diversi in sistemi diversi, la generazione di v5 da ciascun nome produce UUID diversi e non riesce a identificare la stessa persona. Se uno spazio dei nomi non viene concordato tra i team (ogni squadra conia il proprio spazio dei nomi per quella che in realtà è la stessa fonte), generano UUID diversi e non riescono a far corrispondere i record. Se l'input è un dato sensibile, generare un v5 UUID significa che UUID è un valore pubblico e deterministico che chiunque può cercare se conosce gli input. Il determinismo si interrompe quando gli input cambiano o le definizioni dello spazio dei nomi sono incoerenti.
Cosa non copre: il generatore ToolAcre attinge da CSPRNG, quindi gli ID basati sul nome necessitano della libreria UUID della tua lingua
ToolAcre genera solo UUID v4, estratti dal generatore crittograficamente sicuro del browser per l'indipendenza. La derivazione UUID basata sul nome richiede la libreria UUID della lingua o un'implementazione che calcola SHA-1 e formatta correttamente il risultato. Questo post spiega il concetto e i casi d'uso; l'implementazione della generazione v5 è semplice in qualsiasi linguaggio con accesso alle librerie crittografiche standard. I meccanismi della derivazione v5 sono semplici; la sfida è integrarlo in uno schema di sistema in cui lo spazio dei nomi è stabile, il nome è coerente e l'approccio è ben documentato per il tuo team. I team di sviluppo dovrebbero documentare le scelte dello spazio dei nomi.
Conclusione: deterministico quando ne hai bisogno, casuale altrimenti: usa la v5 per mappature stabili e il generatore ToolAcre per tutto ciò che dovrebbe essere impercettibile
Utilizza la v5 per mappature stabili tra identificatori esterni e record interni. Il determinismo impedisce importazioni duplicate e rende la corrispondenza dei record tra i sistemi semplice e affidabile. Non utilizzare UUID basati sul nome per identificatori che devono essere impercettibili o per scenari che richiedono riservatezza e segreti elevati. ToolAcre genera UUID v4 casuali per identificatori che devono essere indipendenti e distinti senza prevedibilità. Quando i tuoi sistemi necessitano di ID deterministici che associno gli input a identificatori fissi, la tua libreria di linguaggio UUID può calcolarli. Il determinismo è una funzionalità potente quando controlli l'input.