Alat pengembang · generator UUID
Apakah UUID Acak Aman sebagai Reset Kata Sandi atau Token Sesi?
· Mengapa itu penting
uuid kriptografi browser-apis
UUID v4 dari CSPRNG memiliki banyak entropi, jadi mengapa peninjau keamanan masih tidak menyukai token UUID? Posting ini memisahkan pertanyaan entropi dari pertanyaan desain.
Tautan setel ulang yang menggunakan UUID baris — pintasan umum dan dua alasan yang sangat berbeda mengapa hal itu mungkin tidak aman
Pintasan umum: gunakan pengidentifikasi baris UUID pengguna sebagai token pengaturan ulang kata sandi. Tabel memiliki kolom uuid; itu unik; sulit ditebak (jika itu v4). URL adalah /reset? token=550e8400-e29b-41d4-a716-446655440000. Peninjau keamanan langsung menolaknya, bukan karena UUID lemah, namun karena hal ini memadukan dua kekhawatiran yang harus independen. Baris UUID stabil dan biasanya terlihat oleh publik (dalam URL, API, log). Token reset harus sekali pakai dan rahasia. Menggunakan kembali baris UUID sebagai token berarti identitas pengguna dan kredensial penyetelannya memiliki nilai yang sama, dan kredensial tersebut tetap berlaku selamanya, bukan kedaluwarsa. Penyerang yang mengetahui ID pengguna dapat melakukan reset. Pengguna yang menyalin-menempelkan tautan setel ulang lima tahun lalu masih dapat menggunakannya. Ini adalah kelemahan desain, bukan kelemahan entropi.
Pemeriksaan entropi: 122 bit acak — mengapa v4 yang dihasilkan CSPRNG tidak dapat ditebak dengan kekerasan
Pemeriksaan keacakan diperlukan tetapi tidak cukup. Versi 4 mencadangkan empat bit versi dan dua bit varian, meninggalkan 128 - 4 - 2 = 122 posisi acak ketika implementasi mengisi kolom lain secara acak. Derivasi tersebut tidak menjelaskan apa pun tentang masa berlaku, penyimpanan, atau otorisasi. Pemeriksaan generator menanyakan apakah kolom tersebut berasal dari CSPRNG, bukan Math.random atau stempel waktu. ToolAcre memenuhi batas generator tersebut. Pemeriksaan desain tetap spesifik untuk aplikasi: kredensial penyetelan ulang memerlukan siklus hidup terpisah, representasi tersimpan satu arah, pembatalan validasi setelah penggunaan berhasil, dan masa berlaku yang dipilih dari kebijakan risiko layanan. Menggunakan kembali ID catatan permanen pengguna akan menggagalkan pemisahan tersebut bahkan ketika ID dibuat dengan aman.
Pemeriksaan generator: di mana token UUID benar-benar gagal — pembuatan berbasis Math.random, stempel waktu v1 dan alamat MAC, serta benih yang dapat diprediksi
Contoh praktis: skema pengaturan ulang kata sandi yang gagal, lalu lolos, ketiga pemeriksaan tersebut. Gagal dalam pemeriksaan entropi: server mengeluarkan token reset melalui Math.random(), dikemas sebagai v4 UUID. Seorang penyerang mengamati tiga token dan memprediksi token keempat. Gagal dalam pemeriksaan generator: server menggunakan v1 UUID sebagai token reset, termasuk stempel waktu pembuatan dan alamat MAC dalam nilainya. Penyerang membaca stempel waktu, mengetahui kapan pengaturan ulang dilakukan, dan mempersempit jendela pencarian. Lulus pemeriksaan entropi tetapi gagal dalam pemeriksaan desain: server menggunakan v4 UUID dari crypto.getRandomValues, tetapi menyimpannya dalam teks biasa di database dan tidak menetapkan masa berlaku. Penyerang yang membobol database membaca token reset dan menggunakannya untuk mereset akun beberapa minggu kemudian. Ketiga pemeriksaan tersebut bersifat independen; kamu harus melewati ketiganya.
Pemeriksaan desain: pengidentifikasi versus kredensial — mengapa menggunakan kembali kunci utama catatan sebagai rahasia memasangkan dua hal yang harus diputar secara independen
Skema token reset yang lolos pemeriksaan entropi dan generator tetapi gagal dalam pemeriksaan desain (tidak ada hash, tidak ada masa kadaluwarsa, tidak ada pembatalan per penggunaan) masih rentan. Menangani sisi server token: ketika pengguna meminta pengaturan ulang kata sandi, buat token acak baru (bukan baris UUID) dari crypto.getRandomValues. Simpan representasi satu arah, bukan nilai yang disajikan, tetapkan masa berlaku spesifik kebijakan, dan batalkan catatan setelah penggunaan berhasil. Saat pengguna mengeklik tautan, cari pengguna melalui email, ambil hash yang disimpan, bandingkan token yang diberikan dengan hash, periksa masa berlakunya, dan jalankan pengaturan ulang hanya jika token tersebut valid dan belum kedaluwarsa. Segera batalkan token tersebut (hapus atau tandai sudah dipakai) agar tidak dapat digunakan kembali. Jangan pernah mencatat token mentah; hanya mencatat ID pengguna dan tindakannya.
Menangani token di sisi server — menyimpan hash, menetapkan masa berlaku, membatalkan penggunaan, dan tidak pernah mencatat nilai mentah
Token tidak boleh muncul dalam pesan kesalahan atau dalam database kecuali jika di-hash. Desain autentikasi lengkap berada di luar cakupan artikel UUID, namun prinsipnya tetap berlaku: token acak 122-bit pada dasarnya bukanlah token akses. Keacakan adalah bagian yang mudah; generator ToolAcre memberi Anda UUID yang didukung CSPRNG. Bagian tersulitnya adalah desainnya: hashing sebelum penyimpanan, mengatur waktu kedaluwarsa, membatalkan penggunaan, mencegah penggunaan kembali ID permanen sebagai rahasia sementara, mengaudit siapa yang mengakses apa dan kapan. Peninjau keamanan yang menyetujui skema tautan setel ulang berdasarkan entropi token saja melewatkan analisis selanjutnya. Pengembang yang menganggap UUID yang didukung CSPRNG cukup untuk membuat tautan penyetelan ulang kata sandi tanpa hashing, kedaluwarsa, dan pembatalan, berarti meremehkan ancaman tersebut. Keacakan melindungi terhadap tebakan; desainnya melindungi dari pemutaran ulang, kedaluwarsa, dan penyalahgunaan.
Contoh praktis - meninjau skema tautan ulang terhadap setiap pemeriksaan dan menulis ulang bagian yang lemah
Generator ToolAcre melakukan bagian keacakan dengan benar; aplikasi harus melakukan bagian desain dengan benar. Uji kode tautan setel ulang Anda terhadap ketiga pemeriksaan tersebut: apakah kode tersebut menggunakan CSPRNG (crypto.getRandomValues, crypto.randomUUID, atau perpustakaan kriptografi), bukan Math.random? Apakah token mempunyai masa kadaluwarsa? Apakah token di-hash sebelum disimpan? Apakah token menjadi tidak valid setelah digunakan? Apakah kode tersebut menghindari penggunaan kembali ID permanen pengguna sebagai token sementara? Jika Anda menjawab ya untuk semua ini, desain tautan reset Anda bagus. Generator ToolAcre adalah bagian CSPRNG; selebihnya adalah kode aplikasi yang harus Anda tinjau dengan cermat. Memahami tiga lapisan keamanan membantu Anda mengaudit pustaka dan kerangka kerja UUID pihak ketiga. Saat Anda mengevaluasi perpustakaan, periksa apakah perpustakaan tersebut menggunakan CSPRNG (pemeriksaan entropi), bukan sumber acak yang lemah. Periksa apakah ia mendokumentasikan sumber mana yang digunakan dan alasannya (pemeriksaan generator).
Apa yang tidak tercakup dalam hal ini — desain autentikasi penuh, MFA dan pembatasan laju, yang sama pentingnya dengan entropi token
Periksa apakah kode contoh dan dokumentasi menekankan prinsip desain: hashing, kadaluwarsa, pembatalan (pemeriksaan desain). Perpustakaan yang lolos ketiga pemeriksaan tersebut jarang terjadi; kebanyakan fokus pada entropi saja. Generator ToolAcre melewati pemeriksaan entropi dan generator dengan menggunakan crypto.getRandomValues. Pemeriksaan desain adalah tanggung jawab Anda; perpustakaan tidak dapat mengetahui persyaratan kedaluwarsa atau strategi hashing Anda. Men-debug sistem tautan reset yang rusak biasanya menunjukkan salah satu dari tiga kegagalan. Jika pengguna melaporkan menerima tautan setel ulang yang tidak lagi berfungsi, kemungkinan masalahnya adalah masa berlakunya sudah habis: token telah diterbitkan tetapi masa berlakunya sudah habis sebelum pengguna mengeklik tautan tersebut. Jika token digunakan kembali beberapa kali, pembatalan validasi akan rusak. Jika token muncul dalam pesan kesalahan atau keluaran debug, logging akan membocorkannya. Jika tautan penyetelan ulang berfungsi untuk satu pengguna tetapi tidak untuk pengguna lain, mungkin ada kelambatan replikasi database atau masalah zona waktu dengan perhitungan kedaluwarsa. Jika permintaan penyetelan ulang yang sah gagal secara acak, CSPRNG mungkin rusak (jarang terjadi).
Kesimpulan: keacakan adalah bagian yang mudah — generator ToolAcre memberi Anda UUID yang didukung CSPRNG; sisanya adalah disiplin desain
Mulailah dengan logging: aktifkan log audit terperinci untuk pembuatan dan verifikasi tautan setel ulang, lalu buat ulang masalahnya dan lacak alurnya. Generator ToolAcre memastikan dua pemeriksaan pertama lolos; pemecahan masalah masalah reset-link hampir selalu termasuk dalam kategori desain. Praktik terbaik untuk sistem tautan penyetelan ulang produksi meliputi: menghasilkan token acak baru untuk setiap permintaan penyetelan ulang, bukan menggunakan kembali token lama. Simpan representasi satu arah di samping akun dan metadata pembuatan, lalu pilih masa berlaku dari kebijakan risiko layanan yang terdokumentasi. Batalkan validasi token segera setelah verifikasi berhasil. Catat permintaan pengaturan ulang dan keberhasilan audit. Terapkan pembatasan kecepatan untuk mencegah serangan brute force. Kirim tautan penyetelan ulang hanya melalui email, bukan SMS atau saluran tidak terenkripsi. Beri tahu pengguna tentang upaya penyetelan ulang kata sandi (sehingga mereka dapat mendeteksi penyetelan ulang yang tidak sah). Generator ToolAcre memberi Anda keacakan; mengikuti praktik ini memberi Anda keamanan.