Review Keamanan Reset Password: Token, Enumerasi, dan Kedaluwarsa

Penerbitan token reset dan redemption atomik

Perlakukan permintaan reset sebagai penerbitan capability sebelum autentikasi. Bandingkan request akun terdaftar dan tidak dikenal pada kondisi sama: pesan eksternal serta timing yang terlihat harus seragam, sementara monitoring internal dapat menyimpan kategori hasil yang aman. Kontrol rate melindungi pengiriman email atau SMS tetapi tidak boleh membuka apakah penerima ada. Jangan mencatat token mentah, password, atau URL reset.

Terbitkan nilai acak kriptografis yang opaque, simpan representasi terlindungi, ikat ke satu akun dan tujuan reset, tetapkan expiry, lalu konsumsi atomik bersama perubahan password. Jangan percaya identifier akun yang ditambahkan ke link; dapatkan akun hanya dari record token tervalidasi. Uji link lama, redemption kedua, redemption ganda yang bersaing, token disalin ke akun lain, serta reset diikuti replay sesi lama.

Output yang diharapkan ialah respons request seragam, paling banyak satu redemption berhasil, pembatalan sesi yang dimaksud, dan notifikasi setelah perubahan. Bukti mencakup capture berpasangan, desain storage, hasil transaksi, hasil expiry terkontrol, dan respons replay sesi. Perbaiki dengan hash atau perlindungan lain untuk token tersimpan, state one-use unik, serta konsumsi dalam transaksi. Reset yang dibantu support adalah proses identity-proofing terpisah dengan audit dan eskalasi sendiri, bukan fallback untuk token otomatis yang gagal.

Tautan pengiriman menciptakan surface paparan sendiri. Gunakan HTTPS, hindari konten pihak ketiga pada halaman reset, dan cegah token masuk ke analytics atau data referrer. Kontrol rate request harus mencakup biaya pengirim serta gangguan penerima; akun valid tidak boleh dibombardir email reset berulang. Uji request setelah akun dihapus atau email berubah dan tetapkan respons aman yang diharapkan. Perubahan password harus mengikuti kebijakan password normal serta pemeriksaan kompromi, bukan menerima pengganti apa pun hanya karena token valid.

Menerbitkan capability reset terikat akun

Reset password dimulai sebelum autentikasi dan tidak boleh mengungkap keberadaan akun. Kirim request berbentuk sama untuk email terdaftar dan email sintetis tidak dikenal. Status eksternal, pesan, dan timing terlihat harus mengikuti satu pola yang dirancang. Monitoring internal dapat mencatat kategori hasil aman, tetapi email mentah, URL reset, password, dan token tidak boleh masuk log. Kontrol rate melindungi biaya pengiriman serta gangguan penerima; kontrol tersebut tidak boleh mengubah respons menjadi oracle keberadaan akun.

Buat capability reset dari nilai acak kriptografis kuat. Kirim nilai opaque hanya melalui kanal pengiriman terlindungi yang dituju, simpan representasi terlindungi di server, ikat ke satu akun serta tujuan reset, tetapkan expiry pendek yang dipilih policy, dan konsumsi secara atomik bersama perubahan password. Jangan percaya ID akun yang ditambahkan ke link; dapatkan akun dari record reset tervalidasi. Halaman reset membutuhkan HTTPS, perilaku referrer ketat, tanpa konten pihak ketiga yang dapat menerima URL, dan token tidak ditampilkan sesudah submit.

Kasus sekali pakai dan expiry

Gunakan akun terkontrol untuk meminta link, tukarkan sekali, lalu ulangi penukaran. Hasil yang diharapkan paling banyak satu perubahan password, respons aman generik untuk replay, dan tidak ada sesi baru kecuali aplikasi menerbitkannya setelah autentikasi normal. Uji token kedaluwarsa memakai waktu terkontrol, token disalin ke akun lain, dua request penukaran bersamaan, request reset setelah akun dihapus, dan request reset setelah email berubah. Pastikan transaksi meninggalkan state konsisten: tidak ada token dikonsumsi dengan password tidak berubah, serta tidak ada password berubah dengan token tetap dapat dipakai setelah error server.

Validasi password tetap mengikuti policy autentikasi normal setelah token tervalidasi. Periksa panjang dan kebijakan secret bocor bila diterapkan; token reset valid bukan izin memilih pengganti lemah. Setelah sukses, batalkan capability reset, catat event keamanan yang meminimalkan PII, kirim notifikasi pasca-reset tanpa password atau link mentah, dan batalkan sesi sesuai policy akun terdokumentasi. Putar ulang sesi browser lama serta token API bila sesuai untuk membuktikan aftermath.

Reset support dan penutupan

Reset dibantu support adalah proses identity-proofing terpisah, bukan fallback untuk link gagal. Proses membutuhkan owner kasus, kategori bukti, batas persetujuan, dan hasil audit. Uji bahwa support tidak dapat menetapkan password, melihat token reset mentah, atau melewati persetujuan kedua bila policy mensyaratkannya. Untuk flow otomatis, bukti mencakup capture enumerasi berpasangan, desain token terlindungi, review sumber entropy, hasil expiry, hasil transaksi redemption, hasil notifikasi, dan hasil replay sesi.

Perbaiki enumerasi dengan penanganan eksternal seragam, masalah token dengan storage terlindungi serta state one-use atomik, dan paparan pengiriman dengan penanganan URL ketat. Penutupan mengulangi request akun tidak dikenal, redemption paralel, link kedaluwarsa, substitusi akun, dan replay sesi pra-reset. Pengecualian migrasi pendek menyebut route, konsumen pengiriman, tanggal akhir, serta kontrol transport kompensasi; pengecualian tidak pernah mengizinkan token reset bearer yang dapat dipakai ulang.

Catatan redemption token reset

Kasus reset	Owner	Bukti	Hasil yang diharapkan	Hasil teramati / status	Pengecualian	Penutupan
Redemption bersamaan satu token untuk akun sintetis `acct-reset-09`	Owner autentikasi	Capture berpasangan `PR-144`; trace transaksi; hasil state token dan replay sesi	Satu perubahan password; token dikonsumsi atomik; sesi lama ditolak	1 sukses, 1 penolakan generik; token dikonsumsi; 3 sesi lama ditolak — ditutup	Tidak ada	Retest expiry, substitusi akun, dan respons akun tidak dikenal lulus 2026-06-19