Alat pengembang · generator UUID
UUID Berbasis Nama (v3 dan v5): ID deterministik dari Namespace
· Latar belakang
uuid kriptografi browser-apis
Ketika catatan eksternal yang sama harus selalu mendapatkan pengidentifikasi yang sama, UUID acak tidak akan berfungsi. Versi 3 dan 5 UUID meng-hash namespace dan nama ke dalam ID stabil; posting ini menjelaskan bagaimana dan kapan menggunakannya.
Mengimpor ulang pelanggan yang sama dua kali — masalah duplikasi yang dipecahkan oleh ID deterministik
Saluran impor data menerima catatan pelanggan dari sistem eksternal dengan ID eksternal yang stabil dalam sistem tersebut. Jika Anda membuat UUID acak baru untuk setiap proses impor, mengimpor pelanggan yang sama dua kali akan menghasilkan dua pengidentifikasi berbeda dan catatan duplikat. Duplikasi ini mengalir ke sistem pelaporan, penagihan, dan dukungan. Jika Anda memperoleh UUID dari ID eksternal pelanggan dan namespace stabil yang mewakili sumber impor Anda, setiap impor menghasilkan UUID yang sama untuk pelanggan yang sama, sehingga memungkinkan Anda mengidentifikasi dan memperbarui catatan yang ada. Determinisme ini adalah ciri khas dari UUID v3 dan v5: keduanya tidak dihasilkan secara independen namun berasal dari masukan, dan masukan yang sama selalu menghasilkan UUID yang identik.
Namespace plus name — bagaimana input digabungkan dan di-hash, dan mengapa namespace mencegah tabrakan antar sumber yang berbeda
UUID v3 atau v5 berasal dari tiga komponen: namespace UUID (biasanya ditentukan sebelumnya), nama (string byte apa pun), dan algoritma hash (MD5 untuk v3, SHA-1 untuk v5). Gabungkan 16 bytes dari namespace UUID dengan UTF-8 byte dari namanya, hash rangkaiannya, ambil 16 bytes pertama dari keluaran hash, dan tafsirkan byte tersebut sebagai UUID dengan versi nibble yang disetel ke 3 atau 5. Namespace mempartisi ruang ID: UUID v5 dari namespace DNS tidak pernah bertabrakan dengan UUID v5 dari namespace URL. RFC 9562 mendefinisikan empat ruang nama yang telah ditentukan sebelumnya: berdasarkan nama DNS, oleh URL, oleh OID, dan oleh X.500 nama istimewa. Organisasi dapat membuat namespace mereka sendiri dengan membuat v4 UUID.
MD5 di v3 dan SHA-1 di v5 — mengapa hash yang dilemahkan dapat diterima di sini, karena ID bukan merupakan kontrol keamanan
Versi 3 menggunakan MD5 dan versi 5 menggunakan SHA-1, pilihannya sesuai dengan tanggal spesifikasi dan implementasi yang tersedia. Untuk UUID berbasis nama, perbedaan ini tidak penting karena fungsi hash bukan merupakan batas keamanan atau kontrol kriptografi. UUID tidak membuktikan keaslian atau integritas; itu hanya mengubah string dengan panjang variabel menjadi nilai 128-bit yang tetap. Model serangan tidak relevan karena UUID disimpan dan dibandingkan sebagai nilai yang tidak jelas, bukan sebagai bukti atau kontrol keamanan. Implementasi baru harus menggunakan v5 (SHA-1) daripada v3 (MD5), bukan karena alasan keamanan yang memaksa tetapi karena v5 adalah standar modern dan tersedia secara luas.
Namespace yang telah ditentukan sebelumnya — DNS, URL, OID dan X.500, dan kapan harus membuat namespace Anda sendiri
RFC 9562 menentukan empat UUID namespace yang telah ditentukan sebelumnya dengan representasi byte spesifik: 6ba7b810-9dad-11d1-80b4-00c04fd430c8 untuk DNS, 6ba7b811-9dad-11d1-80b4-00c04fd430c8 untuk URL, 6ba7b812-9dad-11d1-80b4-00c04fd430c8 untuk OID, dan 6ba7b814-9dad-11d1-80b4-00c04fd430c8 untuk X.500 nama-nama terhormat. V5 UUID yang berasal dari namespace DNS dan nama www.example.com akan selalu identik dan tidak akan pernah bertabrakan dengan namespace v5 UUID dari namespace URL. Penggunaan namespace yang telah ditentukan sebelumnya memastikan interoperabilitas: jika beberapa tim secara independen menggunakan v5 dengan namespace DNS, mereka akan menghasilkan UUID yang identik untuk nama DNS yang sama. Memilih atau membuat namespace adalah bagian dari desain skema.
Contoh praktis — menurunkan UUID v5 secara konseptual dari namespace URL dan catatan URL, langkah demi langkah
Turunkan UUID v5 secara konseptual dari namespace URL dan nama https://example.com/api/users/42. Namespace UUID sebagai 16 bytes adalah 6b a7 b8 11 9d ad 11 d1 80 b4 00 c0 4f d4 30 c8. Namanya adalah string UTF-8 https://example.com/api/users/42, yaitu 30 bytes. Gabungkan byte namespace (16) dan byte nama (30) untuk mendapatkan total 46 bytes. Hitung hash SHA-1, yang menghasilkan hash 20-byte. Ambil 16 bytes pertama dan tafsirkan sebagai UUID dengan versi nibble disetel ke 5 dan bit varian disetel ke standar RFC. Menghitungnya lagi dengan masukan yang sama menghasilkan hasil yang sama. Sebagian besar pengembang menggunakan pustaka bahasa UUID mereka untuk menghitung v5.
Saat polanya rusak — saat nama berubah, saat namespace tidak konsisten di seluruh tim, dan saat masukan dirahasiakan
UUID berbasis nama berasumsi bahwa nama tersebut stabil dan konsisten di seluruh sistem dan proses impor. Jika catatan eksternal yang sama memiliki nama berbeda di sistem berbeda, menghasilkan v5 dari setiap nama menghasilkan UUID berbeda dan gagal mengidentifikasi orang yang sama. Jika namespace tidak disepakati di seluruh tim (setiap tim membuat namespace sendiri untuk sumber yang sebenarnya sama), mereka menghasilkan UUID yang berbeda dan gagal mencocokkan catatan. Jika masukannya adalah data sensitif, menghasilkan v5 UUID berarti UUID adalah nilai deterministik publik yang dapat dicari siapa pun jika mereka mengetahui masukannya. Determinisme rusak ketika input berubah atau definisi namespace tidak konsisten.
Apa yang tidak tercakup di sini — generator ToolAcre diambil dari CSPRNG, jadi ID berbasis nama memerlukan pustaka UUID bahasa Anda
ToolAcre hanya menghasilkan UUID v4, yang diambil dari generator yang aman secara kriptografis browser untuk kemandirian. Derivasi UUID berbasis nama memerlukan pustaka UUID bahasa Anda atau implementasi yang menghitung SHA-1 dan memformat hasilnya dengan benar. Posting ini menjelaskan konsep dan kasus penggunaan; mengimplementasikan generasi v5 sangatlah mudah dalam bahasa apa pun dengan akses ke perpustakaan kriptografi standar. Mekanisme derivasi v5 sederhana; tantangannya adalah mengintegrasikannya ke dalam skema sistem yang namespacenya stabil, namanya konsisten, dan pendekatannya terdokumentasi dengan baik untuk tim Anda. Tim pengembangan harus mendokumentasikan pilihan namespace.
Kesimpulan: deterministik saat Anda membutuhkannya, acak jika tidak — gunakan v5 untuk pemetaan stabil dan generator ToolAcre untuk segala sesuatu yang seharusnya tidak dapat diprediksi
Gunakan v5 untuk pemetaan stabil antara pengidentifikasi eksternal dan catatan internal Anda. Determinisme mencegah impor duplikat dan membuat catatan pencocokan di seluruh sistem menjadi mudah dan dapat diandalkan. Jangan gunakan UUID berbasis nama untuk pengidentifikasi yang tidak dapat ditebak atau untuk skenario yang memerlukan kerahasiaan dan rahasia yang kuat. ToolAcre menghasilkan UUID v4 acak untuk pengidentifikasi yang harus independen dan berbeda tanpa dapat diprediksi. Saat sistem Anda memerlukan ID deterministik yang memetakan masukan ke pengenal tetap, pustaka UUID bahasa Anda dapat menghitungnya. Determinisme adalah fitur canggih saat Anda mengontrol input..