Review Keamanan Pendaftaran MFA dan Pemulihan Akun

Seremoni perubahan authenticator dan tantangan pemulihan

Review pendaftaran, penghapusan, penggantian, penerbitan backup code, recovery perangkat hilang, dan override support sebagai perubahan akun berdampak tinggi. Wajibkan autentikasi terbaru atau seremoni recovery terdokumentasi sebelum mengubah authenticator. NIST SP 800-63B menjelaskan lifecycle authenticator serta konsep step-up; owner risiko menetapkan assurance sesuai dampak akun, bukan menganggap kepemilikan email sebagai bukti identitas universal.

Uji pendaftaran dari sesi lama, penyerang dengan sesi email aktif, recovery code dipakai ulang, penggantian faktor cepat, dan agent support yang bekerja sendiri. Status lulus berarti tidak ada passkey, perangkat OTP, atau backup code baru yang dapat dipakai sampai bukti serta persetujuan wajib selesai. Tampilkan backup code sekali, simpan hanya representasi terlindungi, konsumsi sekali, dan kirim notifikasi melalui kanal independen setelah faktor berubah. Catatan audit mencantumkan event, akun, approver, dan hasil tanpa menyimpan secret authenticator.

Perbaikan dapat menambah step-up, cooldown, dual approval, limit percobaan recovery, serta antrean review. Hindari lockout permanen dari satu sinyal jaringan bersama. Uji penutup memutar ulang recovery code yang sudah dipakai dan memastikan penghapusan faktor membatalkan sesi yang dimaksud. Pengecualian recovery darurat harus berakhir, memerlukan approver terpisah, dan membuat review pascakejadian wajib; pengecualian bukan jalan pintas support yang diam-diam.

Desain recovery harus menyatakan kanal mana yang independen. Notifikasi yang hanya dikirim ke email akun mungkin berguna tetapi tidak dapat memperingatkan orang yang sesi emailnya telah disusupi. Uji notifikasi tambah faktor, jalur pembatalan, dan perilaku delay dengan pengguna sintetis. Bukti support harus menunjukkan siapa memverifikasi kasus, siapa menyetujui perubahan, dan kanal terautentikasi mana yang menerima notifikasi. Jangan mengumpulkan secret recovery dalam tiket. Ukur false-positive lockout sebelum menambah friksi.

Mengikat enrollment ke assurance saat ini

Menambah, menghapus, atau mengganti authenticator mengubah siapa yang dapat mengendalikan akun. Wajibkan autentikasi terbaru atau seremoni recovery terdokumentasi sebelum menampilkan secret enrollment, mendaftarkan passkey, menerima seed OTP, atau menghapus faktor kuat terakhir. Ikat challenge enrollment ke akun saat ini, konteks browser atau perangkat bila sesuai, tipe authenticator tujuan, dan expiry pendek. Secret QR atau tautan aktivasi tidak boleh dipakai ulang setelah binding berhasil.

Gunakan akun sintetis dengan satu faktor yang ada untuk menjalankan enrollment normal. Bukti yang diharapkan mencakup hasil autentikasi terbaru, identifier faktor baru, waktu event, percobaan notifikasi independen, dan keputusan sesi. Setelah itu uji sesi lama, request yang mengganti ID akun lain, challenge enrollment kedaluwarsa, challenge berulang, dan dua enrollment bersamaan. Kasus tidak valid tidak boleh membuat record authenticator atau menghapus faktor yang ada. Bila penggantian lebih dulu menghapus perangkat lama, enrollment baru yang gagal harus meninggalkan state aman yang dapat dipulihkan, bukan tanpa faktor atau dua faktor tak diinginkan.

Recovery code dan penggantian faktor

Recovery code adalah lookup secret sekali pakai, bukan password berulang. Buat nilai tak dapat diprediksi, tampilkan hanya saat penerbitan, simpan representasi terlindungi, tandai konsumsi secara atomik, dan hindari log, cache browser, tangkapan layar sistem support, atau pengiriman email nilai plaintext. Tukarkan satu code, ulangi code itu, lalu gunakan code kedua. Hasil yang diharapkan adalah satu keberhasilan per code, bukti audit tanpa material secret, dan aksi sesi atau faktor sesuai policy.

Workflow penggantian faktor memerlukan challenge sebanding dengan dampak akun. NIST SP 800-63B membahas lifecycle authenticator; artikel ini tidak menetapkan metode proofing universal. Uji recovery perangkat hilang, penyerang dengan sesi email aktif, cooldown sebelum penggantian sensitif, pembatalan perubahan tertunda, dan kegagalan notifikasi. Notifikasi melalui kanal independen lebih kuat daripada notifikasi hanya ke kanal akun yang sedang dipulihkan. Bila notifikasi tidak dapat dikirim, catat state recovery untuk tindak lanjut berwenang, bukan menyatakan selesai secara diam-diam.

Helpdesk dan hasil sesi

Staf helpdesk harus mengikuti workflow identity-proofing terdokumentasi yang disetujui owner risiko; nomor akun dari penelepon atau data profil publik saja adalah bukti lemah. Pisahkan verifikasi pemohon dari persetujuan agent bila risiko memerlukannya, catat ID kasus, kategori bukti, approver, scope, dan hasil tanpa menyalin secret ke tiket. Uji bahwa satu agent tidak dapat melewati keputusan kedua yang wajib.

Setelah penambahan, penghapusan, recovery faktor, atau override support, putuskan sesi mana yang tetap valid. Putar ulang sesi sebelum perubahan dari dua perangkat dan periksa aksi terlindungi. Remediasi dapat menambah step-up, cooldown, dual approval, limit percobaan recovery, serta pencabutan. Penutupan menjalankan ulang kasus sesi curian, code dipakai ulang, penggantian tertunda, dan agent helpdesk tunggal. Pengecualian recovery sementara menyebut scope akun, metode proofing, expiration, review independen, serta kewajiban notifikasi pascakejadian.

Catatan kasus seremoni recovery

Event recovery	Owner	Bukti	Hasil yang diharapkan	Hasil teramati / status	Pengecualian	Penutupan
Penggantian faktor perangkat hilang untuk akun sintetis `acct-mfa-17`	Owner risiko identitas	Kasus `MFA-071`; kategori bukti, audit approver, bukti notifikasi, replay sesi	Penggantian menunggu persetujuan kedua; code terpakai gagal; sesi lama dicabut	Persetujuan diterapkan; replay ditolak; 2 sesi lama dicabut — ditutup	Tidak ada	Notifikasi independen terkirim; retest code terpakai dan agent tunggal lulus 2026-06-18