UUID v4 Generator
Menghasilkan UUID v4 acak yang aman secara kriptografis
…
Format
UUID v4 adalah versi UUID yang paling banyak digunakan dalam perangkat lunak modern. Tidak seperti versi lainnya yang mengambil bit dari timestamp atau hash namespace, UUID v4 sepenuhnya dibangun dari data acak — menjadikannya pilihan paling sederhana dan portabel ketika Anda membutuhkan identifier unik tanpa metadata tentang asal-usulnya.
Generator ini menggunakan crypto.randomUUID(), API browser dan Node.js native, yang mengambil entropi dari cryptographically secure random number generator sistem operasi — sumber yang sama yang digunakan untuk materi kunci TLS.
Apa itu UUID v4?
Universally Unique Identifier (UUID) adalah label 128-bit yang distandarisasi dalam RFC 4122. Biasanya direpresentasikan sebagai 32 digit heksadesimal yang dikelompokkan dengan tanda hubung dalam pola 8-4-4-4-12:
Dalam UUID v4, 122 dari 128 bit bersifat acak. 6 bit sisanya adalah field tetap yang diamanatkan oleh spec: 4 bit mengkodekan versi (0100 = 4) dan 2 bit mengkodekan varian RFC 4122 (10). Bit tetap tersebut adalah alasan mengapa grup ketiga selalu dimulai dengan 4 dan grup keempat selalu dimulai dengan 8, 9, a, atau b.
Anatomi UUID v4
Memecah 550e8400-e29b-41d4-a716-446655440000:
| Segmen | Bit | Makna |
|---|---|---|
| 550e8400 | 32 acak | time_low (nama historis — sepenuhnya acak di v4) |
| e29b | 16 acak | time_mid (nama historis — sepenuhnya acak di v4) |
| 41d4 | 4 tetap + 12 acak | Nibble versi 4 (biner 0100) + 12 bit acak |
| a716 | 2 tetap + 14 acak | Bit varian 10 (MSB byte pertama) + 14 bit acak |
| 446655440000 | 48 acak | node (sepenuhnya acak di v4) |
8, 9, a, atau b — karena dua bit tinggi byte tersebut dikunci ke 10 (penanda varian RFC 4122), sehingga dua bit sisanya bebas bervariasi.UUID v4 vs Versi Lainnya
RFC 4122 mendefinisikan lima versi UUID. Masing-masing memecahkan masalah berbeda:
Menggabungkan timestamp 60-bit (interval 100 nanodetik sejak Oktober 1582) dengan alamat MAC host. Monotonically increasing dalam satu mesin.
Use when: saat Anda membutuhkan ID berurutan waktu dan tidak keberatan mengekspos identitas server dan waktu pembuatan.
Deterministik: namespace + nama yang sama selalu menghasilkan UUID yang sama. Menggunakan hashing MD5.
Use when: saat Anda membutuhkan ID yang dapat direproduksi dari namespace yang diketahui (misalnya nama DNS). Lebih pilih v5 daripada v3.
122 bit keacakan yang aman secara kriptografi. Tanpa timestamp, MAC, atau namespace. Pilihan paling umum untuk tujuan umum.
Use when: saat Anda membutuhkan ID unik tanpa makna struktural dan privasi maksimal.
Seperti v3 tetapi menggunakan SHA-1. Masih deterministik dari namespace + nama.
Use when: saat Anda membutuhkan identifier yang dapat direproduksi dan berbasis konten (misalnya ID stabil untuk resource yang diidentifikasi oleh URL).
Lebih baru (RFC 9562, 2024). Mengkodekan timestamp Unix milidetik di bit tinggi, lalu bit acak. Dapat diurutkan dan ramah database.
Use when: saat Anda membutuhkan ID ramah indeks database dengan pengurutan waktu alami (lebih pilih dari v1 untuk proyek baru).
Kapan Menggunakan UUID v4
UUID v4 adalah alat yang tepat dalam sebagian besar situasi di mana Anda hanya membutuhkan "sebuah ID unik" tanpa batasan tambahan:
ID pengguna dan akun
ID pengguna yang buram dan tidak mengungkapkan apapun tentang waktu pembuatan akun atau identitas server. Tidak dapat dienumerasi atau ditebak.
Kunci primer database
Bekerja dengan mesin database apa pun. UUID v4 aman untuk dibuat di sisi klien dan digabungkan dari sumber terdistribusi tanpa koordinasi — tidak diperlukan sequence table maupun layanan ID terpusat.
ID sesi dan token
122 bit keacakan membuat tebakan brute-force tidak mungkin secara komputasi — setara kekuatannya dengan token acak 122-bit.
Nama file dan objek
Nama file aman untuk deduplikasi untuk unggahan, kunci objek S3, atau entri cache. Tidak ada risiko dua klien menulis ke kunci yang sama.
Kunci idempotency
Buat UUID di klien sebelum mengirimkan permintaan. Server dapat menghilangkan duplikat permintaan yang dicoba ulang dengan aman tanpa counter bersama.
ID korelasi dan jejak
Lampirkan UUID ke setiap baris log dan span jejak terdistribusi. Tidak diperlukan koordinasi antar layanan atau mesin.
Probabilitas Tabrakan
Dengan 122 bit acak, ruang UUID v4 mengandung 2122 ≈ 5,3 × 1036 nilai yang mungkin. Probabilitas tabrakan mengikuti masalah ulang tahun:
Benchmark yang sering dikutip: untuk memiliki peluang 50% dari satu tabrakan, Anda perlu menghasilkan sekitar 2,71 × 1018 UUID. Pada kecepatan 1 miliar UUID per detik, itu membutuhkan sekitar 85 tahun pembuatan berkelanjutan. Untuk aplikasi nyata apa pun, tabrakan bukan kekhawatiran yang praktis.
Contoh Kode
JavaScript — Browser dan Node.js 14.17+
Metode crypto.randomUUID() tersedia secara native di semua browser modern (Chrome 92+, Firefox 95+, Safari 15.4+) dan Node.js 14.17+. Tidak diperlukan instalasi paket.
// Browser or Node.js 14.17+
const id = crypto.randomUUID()
// → "110e8400-e29b-41d4-a716-446655440000"
// Generate multiple
const ids = Array.from({ length: 5 }, () => crypto.randomUUID())Node.js — versi lama (paket uuid)
const { v4: uuidv4 } = require('uuid')
const id = uuidv4()
// → "110e8400-e29b-41d4-a716-446655440000"Python
import uuid # Generate a UUID v4 id = str(uuid.uuid4()) # → '110e8400-e29b-41d4-a716-446655440000' # The uuid module uses os.urandom() — cryptographically secure print(uuid.uuid4().hex) # without hyphens # → '110e8400e29b41d4a716446655440000'
Go
import "github.com/google/uuid" id := uuid.New().String() // → "110e8400-e29b-41d4-a716-446655440000" // Or using the standard library (Go 1.20+ with math/rand/v2 is NOT cryptographic) // Always prefer github.com/google/uuid for production use
Rust
# Cargo.toml
[dependencies]
uuid = { version = "1", features = ["v4"] }use uuid::Uuid; let id = Uuid::new_v4().to_string(); // → "110e8400-e29b-41d4-a716-446655440000"
Pertanyaan yang Sering Diajukan
Apakah UUID v4 aman secara kriptografi?
UUID v4 sendiri bukanlah primitif keamanan — itu adalah format identifier. Namun, ketika dihasilkan melalui crypto.randomUUID() (browser atau Node.js) atau API setingkat OS yang setara, entropi yang mendasarinya aman secara kriptografi. Ini berarti nilai UUID v4 cocok digunakan sebagai token sesi atau kunci idempotency, di mana ketidakpastian sangat penting. Jangan gunakan generator UUID berbasis Math.random() untuk konteks sensitif keamanan — gunakan hanya API yang secara eksplisit mengambil dari OS CSPRNG.
Bisakah dua UUID v4 pernah sama?
Secara teoritis ya, tetapi secara praktis tidak. Probabilitas menghasilkan duplikat dalam dataset realistis apa pun (miliaran ID) sangat kecil secara astronomis — jauh lebih kecil kemungkinannya daripada kesalahan hardware yang menyebabkan kerusakan data. Tabrakan UUID v4 diperlakukan sebagai hal yang mustahil dalam desain sistem produksi. Jika Anda benar-benar membutuhkan jaminan tanpa tabrakan, gunakan counter terpusat atau sequence database.
UUID v4 vs nanoid — mana yang harus digunakan?
Keduanya adalah generator ID acak yang didukung CSPRNG. Perbedaan utama:
- UUID v4 mengikuti standar RFC 4122, dikenali oleh setiap database dan framework, dan memerlukan nol dependensi (native
crypto.randomUUID()). - nanoid menggunakan alfabet URL-safe dan lebih pendek secara default (21 karakter vs 36). Berguna ketika panjang URL atau keterbacaan penting. Memerlukan paket npm.
Pilih UUID v4 ketika interoperabilitas dengan sistem eksternal penting (API, database, infrastruktur logging). Pilih nanoid ketika Anda ingin ID yang lebih pendek dan mengontrol seluruh stack.
Haruskah saya menyimpan UUID sebagai string atau biner di database?
Untuk sebagian besar database, menyimpan sebagai kolom UUID atau BINARY(16) (16 byte) lebih efisien daripada string VARCHAR(36) (36 byte). PostgreSQL memiliki tipe uuid native. MySQL dan MariaDB bekerja baik dengan BINARY(16) dan helper UUID_TO_BIN() / BIN_TO_UUID(). Pengguna SQLite biasanya menyimpan sebagai TEXT. Pilihan penyimpanan tidak berpengaruh pada keunikan atau kebenaran.
Mengapa UUID v4 memiliki tanda hubung — dan dapatkah saya menghilangkannya?
Tanda hubung adalah bagian dari representasi UUID kanonik yang didefinisikan oleh RFC 4122. Murni kosmetik — tidak membawa informasi dan tidak mempengaruhi nilai 128-bit. Menghilangkannya menghasilkan string hex kompak 32 karakter yang secara fungsional setara. Sebagian besar parser UUID menerima kedua bentuk. Bila ragu, gunakan bentuk bertanda hubung kanonik untuk kompatibilitas maksimal dengan alat dan database pihak ketiga.
const id = crypto.randomUUID() // "550e8400-e29b-41d4-a716-446655440000"
const compact = id.replaceAll('-', '') // "550e8400e29b41d4a716446655440000"