Generator UUID

• UUID v1 combină un timestamp cu adresa MAC a dispozitivului — garantează unicitatea, dar dezvăluie momentul creării și identitatea hardware-ului, generând probleme de confidențialitate.
• UUID v3 și v5 sunt hash-uri deterministe: v3 folosește MD5, iar v5 folosește SHA-1. Pentru același spațiu de nume și același nume, generează întotdeauna același UUID — utile pentru obținerea de identificatori consecvenți din chei naturale (de exemplu, convertirea adreselor de e-mail în ID-uri de utilizator).
• UUID v4 utilizează 122 de biți de date aleatorii, oferind cea mai solidă garanție de unicitate fără a expune nicio informație.
• UUID v7 (RFC 9562, 2024) integrează un timestamp Unix în primii 48 de biți, păstrând în același timp 74 de biți aleatorii — este sortabil după momentul creării, fiind ideal pentru cheile primare din bazele de date unde performanța indexării este critică.

Pentru majoritatea aplicațiilor, v4 este alegerea implicită; alegeți v7 pentru chei primare în baze de date unde ordinea inserării contează.

UUID v4 folosește 122 de biți aleatorii, rezultând 5,3 × 10^36 de valori posibile. Paradoxul zilei de naștere determină probabilitatea de coliziune: abia după generarea a 2,7 × 10^18 (2,7 cvintilioane) de UUID-uri există o șansă de 50% să apară o singură coliziune.

În termeni practici, generarea a 1 miliard de UUID-uri pe secundă timp de 85 de ani ar atinge acest prag. La o scară mai realistă — un sistem care generează 1 milion de UUID-uri pe zi — probabilitatea oricărei coliziuni în 100 de ani este de aproximativ 1 la 10^24.

Această estimare presupune un generator de numere aleatorii adecvat (CSPRNG); utilizarea Math.random() în JavaScript (care nu este sigur din punct de vedere criptografic) reduce entropia și crește riscul de coliziune. Folosiți întotdeauna crypto.randomUUID(), biblioteci uuid v4 sau funcții UUID native ale bazelor de date pentru sistemele de producție.

Folosirea UUID-urilor ca și chei primare permite generarea descentralizată a ID-urilor (aplicațiile creează ID-uri fără interogări suplimentare în baza de date) și previne atacurile de enumerare (utilizatorii nu pot ghici ID-urile altor înregistrări).

Totuși, valorile aleatorii UUID v4 afectează performanța indicilor B-tree — inserările aleatorii provoacă fragmentare și divizarea paginilor (page splits), crescând amplificarea scrierilor de 2-5 ori comparativ cu cheile întregi secvențiale. UUID v7 rezolvă această problemă printr-un prefix bazat pe timestamp urmat de date aleatorii, oferind atât unicitate, cât și ordine secvențială.

Costul de stocare este, de asemenea, mai mare: 16 octeți față de 4-8 octeți pentru numere întregi, o diferență semnificativă în tabelele cu miliarde de rânduri și indici multipli.

O practică frecventă combină UUID-urile ca identificatori publici cu chei întregi auto-incrementate la nivel intern, realizând legăturile între tabele pe baza întregului eficient și expunând doar UUID-ul securizat către API-uri și URL-uri.

Un UUID (Universally Unique Identifier) este o valoare pe 128 de biți concepută pentru a fi unică în spațiu și timp, fără a necesita o autoritate centrală de înregistrare, așa cum este definit de standardul IETF RFC 9562 (care înlocuiește vechiul RFC 4122).

Cei 128 de biți ai săi sunt reprezentați prin 32 de caractere hexazecimale grupate într-un format 8-4-4-4-12, cum ar fi 550e8400-e29b-41d4-a716-446655440000. Anumiți biți sunt rezervați: a 13-a cifră hexazecimală indică versiunea, iar primii biți ai celei de-a 17-a cifre hexazecimale indică varianta.

Biții rămași conțin date aleatorii, o marcă temporală sau un hash al unui nume, în funcție de versiune. Deoarece spațiul de adrese este de 2^122, generatoarele independente pot crea identificatori în siguranță, fără a fi nevoie să se sincronizeze vreodată între ele.

Cea mai simplă cale de a genera un UUID este folosirea unei funcții integrate în limbaj care apelează o sursă aleatorie sigură din punct de vedere criptografic.

• În JavaScript, crypto.randomUUID() returnează un UUID v4 și este documentat pe MDN Web Docs ca parte din Web Crypto API, fiind disponibil în browserele moderne și în Node.js 14.17+.
• În Python, modulul uuid din biblioteca standard oferă uuid.uuid4() pentru valori aleatorii și uuid.uuid1() pentru valori bazate pe amprentă temporală (timestamp).
• În PostgreSQL, gen_random_uuid() generează un UUID v4, în timp ce MySQL 8 oferă UUID() pentru o valoare de tip v1.

Toate acestea emit șiruri de caractere conforme cu RFC 9562, astfel încât ID-urile generate într-un limbaj sunt pe deplin interoperabile cu altul.

Da, un GUID și un UUID sunt același identificator pe 128 de biți; GUID (Globally Unique Identifier) este doar terminologia utilizată de Microsoft pentru UUID-ul standard definit de IETF RFC 9562. Acestea sunt compatibile la nivel binar, astfel încât o valoare creată de Windows sau .NET poate fi utilizată de orice sistem conform cu standardul RFC și invers.

Singura diferență obișnuită este modul de afișare: instrumentele Microsoft încadrează adesea valoarea între paranteze acolade, de exemplu {550e8400-e29b-41d4-a716-446655440000}, iar unele API-uri COM foloseau în trecut litere mari pentru valorile hexazecimale.

O nuanță fină este ordinea octeților (byte order) — GUID-ul binar de la Microsoft stochează primele trei câmpuri în format little-endian, aspect relevant doar la analizarea octeților cruzi, nu și la forma canonică de șir de caractere cu cratime.

Un UUID nu este un secret și nu ar trebui tratat niciodată ca atare, chiar și atunci când biții săi aleatorii provin dintr-un generator sigur din punct de vedere criptografic. RFC 9562 avertizează în mod explicit că UUID-urile nu oferă nicio securitate integrată și nu trebuie considerate greu de ghicit; OWASP avertizează în mod similar împotriva utilizării identificatorilor drept tokenuri de autorizare.

Versiunea 4 folosește 122 de biți dintr-un CSPRNG, fiind practic imposibil de prevăzut, dar versiunea 1 și versiunea 7 includ amprente temporale care divulgă momentul creării, iar versiunea 3 și versiunea 5 sunt hash-uri deterministe ale unui spațiu de nume și nume cunoscute.

Pentru tokenuri de sesiune, resetări de parolă sau chei API, generați secrete dedicate cu entropie ridicată în loc să vă bazați pe structura unui UUID pentru protecție.

Câmpurile de versiune și variantă sunt tipare fixe de biți integrate în fiecare UUID conform RFC 9562, care indică parserelor modul în care a fost generată valoarea.

Versiunea ocupă cei mai semnificativi patru biți din al șaptelea octet (a 13-a cifră hexazecimală), astfel încât un UUID v4 afișează întotdeauna cifra 4 în acel loc, iar un v7 afișează 7. Varianta se află în cei mai semnificativi doi sau trei biți ai celui de-al nouălea octet (a 17-a cifră hexazecimală), ceea ce, pentru varianta standard IETF, face ca acea cifră să fie una dintre 8, 9, a sau b.

Acesta este motivul pentru care un UUID v4 valid respectă tiparul xxxxxxxx-xxxx-4xxx-[89ab]xxx-xxxxxxxxxxxx. Verificarea acestor poziții fixe este modalitatea corectă de a valida sau clasifica un UUID, în loc de o simplă verificare a lungimii.

Generarea de UUID-uri în masă este utilă pentru popularea bazelor de date, crearea datelor de test, testarea de performanță și furnizarea de date mock pentru API-uri, iar acest instrument poate genera mulți identificatori valizi printr-un singur clic. Deoarece fiecare UUID este creat independent dintr-o sursă aleatorie sau temporală conform RFC 9562, generarea unui lot nu prezintă un risc semnificativ de coliziune, chiar și la un volum mare.

Pentru date de test reproductibile, preferați UUID-uri deterministe de versiune 5 derivate dintr-un spațiu de nume și un nume fixe, astfel încât aceeași intrare să genereze întotdeauna același identificator la fiecare rulare.

Când populați tabele la scară de producție, luați în considerare versiunea 7, astfel încât rândurile introduse în masă să fie orânduite aproximativ secvențial în index, menținând paginile B-tree compacte și reducând amplificarea scrierilor în timpul importului.

Stocați UUID-urile într-un tip binar nativ pe 16 octeți ori de câte ori baza de date permite acest lucru, deoarece păstrarea lor ca text de 36 de caractere risipește mai mult decât dublul spațiului și încetinește compararea indeșilor. PostgreSQL oferă un tip de coloană dedicat uuid, în timp ce MySQL și SQL Server folosesc de obicei BINARY(16) cu funcții de conversie din și în șirul cu cratime.

După cum notează RFC 9562, UUID-urile nu fac diferență între litere mari și mici (sunt case-insensitive) și ar trebui normalizate — de obicei în litere mici — înainte de stocare, pentru ca căutările să rămână consecvente.

Dacă folosiți UUID-uri ca chei primare, preferați versiunea 7 pentru a păstra localitatea inserărilor; dacă trebuie să folosiți versiunea 4, unele motoare vă permit să rearanjați octeții amprentei temporale, deși versiunea 7 este soluția bazată pe standarde la aceeași problemă de fragmentare.

Cea mai frecventă greșeală în lucrul cu UUID-uri este utilizarea unei surse de numere aleatorii necriptografice, cum ar fi Math.random() din JavaScript, care nu este un CSPRNG și poate produce valori părtinitoare sau previzibile; MDN recomandă în schimb crypto.randomUUID() sau Web Crypto API.

Alte erori frecvente includ:

• tratarea UUID-ului nil (numai din zerouri) ca fiind un identificator real
• presupunerea că UUID-urile sunt suficient de secrete pentru a autoriza accesul
• stocarea acestora ca text când o coloană binară pe 16 octeți ar fi mult mai eficientă

De asemenea, dezvoltatorii amestecă versiunile în mod neconsecvent sau se bazează pe versiunea 1 în contexte sensibile la confidențialitate, unde amprenta temporală inclusă și adresa MAC istorică pot divulga informații. În cele din urmă, compararea UUID-urilor ținând cont de litere mari și mici (case-sensitive) duce la potriviri eșuate eronate, deoarece RFC 9562 le definește ca fiind insensibile la majuscule.