Generatore UUID

• UUID v1 combina un timestamp con l'indirizzo MAC della macchina — garantito come unico, ma rivela l'ora di creazione e l'identità dell'hardware, sollevando problemi di privacy.
• UUID v3 e v5 sono hash deterministici: v3 utilizza MD5, v5 utilizza SHA-1. A parità di namespace e nome, producono sempre lo stesso UUID — utile per generare identificatori coerenti da chiavi naturali (ad es. convertire indirizzi e-mail in ID utente).
• UUID v4 utilizza 122 bit di dati casuali, offrendo la massima garanzia di unicità senza far trapelare alcuna informazione.
• UUID v7 (RFC 9562, 2024) incorpora un timestamp Unix nei primi 48 bit mantenendo 74 bit casuali — ordinabile in base all'ora di creazione, il che lo rende ideale per le chiavi primarie dei database in cui le prestazioni degli indici sono fondamentali.

Per la maggior parte delle applicazioni, la v4 è la scelta predefinita; passa alla v7 per le chiavi primarie dei database in cui l'ordine di inserimento è importante.

UUID v4 utilizza 122 bit casuali, generando 5,3 × 10^36 valori possibili. Il paradosso del compleanno determina la probabilità di collisione: dopo aver generato 2,7 × 10^18 (2,7 quintilioni) di UUID, c'è una probabilità del 50% di avere una collisione.

In termini pratici, generando 1 miliardo di UUID al secondo per 85 anni si raggiunge questa soglia. Su scale più realistiche — un sistema che genera 1 milione di UUID al giorno — la probabilità di una qualsiasi collisione in 100 anni è approssimativamente di 1 su 10^24.

Questo presuppone un generatore di numeri casuali adeguato (CSPRNG); l'uso di Math.random() in JavaScript (che non è crittograficamente sicuro) riduce l'entropia e aumenta il rischio di collisioni. Utilizza sempre crypto.randomUUID(), librerie uuid v4 o funzioni UUID native del database per i sistemi di produzione.

Gli UUID come chiavi primarie consentono la generazione decentralizzata di ID (le applicazioni creano ID senza dover interrogare il database) e prevengono gli attacchi di enumerazione (gli utenti non possono indovinare gli ID degli altri record).

Tuttavia, i valori casuali di UUID v4 riducono le prestazioni degli indici B-tree — gli inserimenti casuali causano la divisione delle pagine e la frammentazione, aumentando l'amplificazione della scrittura di 2-5 volte rispetto alle chiavi intere sequenziali. L'UUID v7 risolve questo problema con la casualità preceduta da timestamp, offrendo sia l'unicità che l'ordinamento sequenziale.

Anche il costo di archiviazione è più elevato: 16 byte rispetto ai 4-8 byte per gli interi, un fattore significativo in tabelle con miliardi di righe e indici multipli.

Un pattern comune combina gli UUID come identificatori pubblici con chiavi intere ad incremento automatico per uso interno, unendo le tabelle sull'intero efficiente ed esponendo solo l'UUID sicuro ad API e URL.

Un UUID (Universally Unique Identifier) è un valore a 128 bit progettato per essere unico nello spazio e nel tempo senza un'autorità di registrazione centrale, come definito dalla norma IETF RFC 9562 (che rende obsoleta la precedente RFC 4122).

I suoi 128 bit sono scritti come 32 caratteri esadecimali raggruppati in uno schema 8-4-4-4-12, come 550e8400-e29b-41d4-a716-446655440000. Alcuni bit specifici sono riservati: la 13ª cifra esadecimale codifica la versione, mentre i bit superiori della 17ª cifra esadecimale codificano la variante.

I bit rimanenti contengono dati casuali, un timestamp o un nome con hash a seconda della versione. Poiché lo spazio indirizzabile è di 2^122, generatori indipendenti possono creare identificatori in tutta sicurezza senza doversi mai coordinare.

Il modo più semplice per generare un UUID è utilizzare una funzione integrata nel linguaggio che richiama una sorgente casuale crittograficamente sicura.

• In JavaScript, crypto.randomUUID() restituisce un UUID v4 ed è documentato su MDN Web Docs come parte della Web Crypto API, disponibile nei browser moderni e in Node.js 14.17+.
• In Python, il modulo uuid della libreria standard fornisce uuid.uuid4() per valori casuali e uuid.uuid1() per valori basati sul timestamp.
• In PostgreSQL, gen_random_uuid() produce un UUID v4, mentre MySQL 8 offre UUID() per un valore in stile v1.

Tutti questi metodi generano stringhe conformi allo standard RFC 9562, consentendo agli ID creati in un linguaggio di interoperare perfettamente con un altro.

Sì, un GUID e un UUID sono lo stesso identificativo a 128 bit; GUID (Globally Unique Identifier) è semplicemente la terminologia Microsoft per l'UUID standard definito da IETF RFC 9562. Sono compatibili a livello binario, quindi un valore creato da Windows o .NET può essere letto da qualsiasi sistema conforme a RFC e viceversa.

L'unica differenza abituale è la rappresentazione: gli strumenti Microsoft spesso racchiudono il valore tra parentesi graffe, ad esempio {550e8400-e29b-41d4-a716-446655440000}, e in passato alcune API COM usavano caratteri maiuscoli per l'esadecimale.

Un'altra sottile differenza riguarda l'ordine dei byte: il GUID binario di Microsoft memorizza i primi tre campi in little-endian, il che rileva soltanto quando si analizzano i byte grezzi e non la forma canonica con i trattini.

Un UUID non è un segreto e non dovrebbe mai essere trattato come tale, anche quando i suoi bit casuali provengono da un generatore crittograficamente sicuro. RFC 9562 avverte esplicitamente che gli UUID non offrono alcuna sicurezza integrata e non bisogna presupporre che siano difficili da indovinare; allo stesso modo, OWASP sconsiglia di utilizzare identificatori come token di autorizzazione.

La versione 4 trae 122 bit da un CSPRNG, rendendola impossibile da prevedere nella pratica, ma la versione 1 e la versione 7 integrano timestamp che rivelano l'ora di creazione, mentre la versione 3 e la versione 5 sono hash deterministici di un namespace e di un nome noti.

Per i token di sessione, il ripristino delle password o le chiavi API, è preferibile generare segreti dedicati ad alta entropia anziché affidarsi alla struttura di un UUID per la protezione.

I campi versione e variante sono sequenze fisse di bit integrate in ogni UUID RFC 9562 che indicano ai parser come è stato generato il valore.

La versione occupa i quattro bit più significativi del settimo byte (la 13ª cifra esadecimale), quindi un UUID v4 mostra sempre un 4 in quella posizione e un v7 mostra sempre un 7. La variante risiede nei due o tre bit più significativi del nono byte (la 17ª cifra esadecimale), che per la variante standard IETF rende tale cifra un valore tra 8, 9, a o b.

Ecco perché un UUID v4 valido rispetta il formato xxxxxxxx-xxxx-4xxx-[89ab]xxx-xxxxxxxxxxxx. Verificare queste posizioni fisse è il modo corretto per convalidare o classificare un UUID anziché eseguire un semplice controllo sulla lunghezza.

La generazione di UUID in blocco è utile per il popolamento di database, la creazione di fixture di test, i test di carico e il popolamento di API mock; questo strumento consente di generare numerosi identificativi validi con un solo clic. Poiché ciascun UUID viene creato in modo indipendente da una sorgente casuale o temporale secondo RFC 9562, la generazione in batch non comporta un rischio significativo di collisione anche con grandi quantitativi.

Per dati di test ripetibili, è preferibile utilizzare UUID deterministici di versione 5 derivati da un namespace e da un nome fissi, in modo che lo stesso input produca sempre lo stesso identificativo in esecuzioni diverse.

Quando si popolano tabelle di dimensioni reali per la produzione, valutare la versione 7 affinché le righe inserite in blocco seguano un ordine di indice approssimativamente sequenziale, mantenendo compatte le pagine B-tree e riducendo l'amplificazione della scrittura durante l'importazione.

Memorizza gli UUID in un tipo binario nativo a 16 byte ogni volta che il database lo supporta, poiché conservarli come testo di 36 caratteri spreca più del doppio dello spazio e rallenta i confronti sugli indici. PostgreSQL offre un tipo di colonna uuid dedicato, mentre MySQL e SQL Server utilizzano comunemente BINARY(16) con funzioni di conversione da e verso la stringa con trattini.

Come evidenziato da RFC 9562, gli UUID non fanno distinzione tra maiuscole e minuscole e dovrebbero essere normalizzati (solitamente in minuscolo) prima dell'archiviazione per garantire la coerenza delle ricerche.

Se utilizzi gli UUID come chiavi primarie, preferisci la versione 7 per preservare la localizzazione degli inserimenti; se devi usare la versione 4, alcuni engine consentono di riordinare i byte del timestamp, anche se la versione 7 rappresenta la soluzione basata su standard allo stesso problema di frammentazione.

L'errore più comune con gli UUID consiste nell'utilizzare una sorgente casuale non crittografica come Math.random() di JavaScript, che non è un CSPRNG e può produrre valori sbilanciati o prevedibili; MDN raccomanda invece crypto.randomUUID() o la Web Crypto API.

Altri errori frequenti includono:

• trattare l'UUID nil (tutti zeri) come un identificativo reale
• presupporre che gli UUID siano abbastanza segreti da autorizzare l'accesso
• memorizzarli come testo quando una colonna binaria a 16 byte sarebbe molto più efficiente

Inoltre, gli sviluppatori spesso combinano le versioni in modo incoerente o si affidano alla versione 1 in contesti riservati, nei quali il timestamp integrato e l'indirizzo MAC storico rivelano informazioni personali. Infine, il confronto di UUID con distinzione tra maiuscole e minuscole provoca falsi mancati riscontri, poiché RFC 9562 li definisce indipendenti dal maiuscolo/minuscolo.