Permintaan MFA VPN ditolak: apa yang harus dilakukan klien

Permintaan MFA yang ditolak terlihat seperti masalah jaringan dan bukan begitu. Server meminta faktor kedua, faktor itu kembali negatif atau tidak pernah tiba, dan sesi ditolak sebelum ada terowongan apa pun. Apa yang terjadi setelahnya adalah soal perilaku klien: tampilkan kegagalan dan biarkan pengguna memulai percobaan bersih, atau ulangi dengan cara yang menghasilkan lebih banyak permintaan dan akhirnya memicu perlindungan akun. Jalur kedua itulah cara satu kode yang salah ketik menjadi akun terkunci.

Periksa permintaan mana yang gagal

Mulailah dengan mengidentifikasi permintaan mana yang gagal. Notifikasi push, kode TOTP, pernyataan FIDO, dan alur SAML masing-masing gagal dengan cara berbeda, dan klien biasanya tahu mana yang dimintanya. Penolakan, tantangan yang kedaluwarsa, dan kegagalan pengiriman yang tidak pernah sampai ke perangkat semuanya berakhir pada galat generik yang sama, jadi status klien sendiri sering menjadi satu-satunya tempat perbedaannya bertahan.

Status itu layak dicatat dengan tepat. Catat pengenal tantangan atau referensi transaksi, jenis faktor, stempel waktu, dan hasilnya, tetapi jangan pernah mencatat kode atau pernyataannya. Pengenal tantangan adalah yang memungkinkan administrator menemukan peristiwa di sisi penyedia identitas; tanpanya, percakapan dukungan dimulai dengan “suatu waktu dalam satu jam terakhir” dan biasanya berakhir di situ. Perlakukan sebagai metadata diagnostik, bukan rahasia.

Coba ulang sekali, dengan sengaja, memakai tantangan baru

Percobaan ulang harus berupa percobaan baru dengan tantangan baru, bukan pemutaran ulang tantangan lama. Ketika klien memakai kembali tantangan sebelumnya, penyedia identitas menolaknya sebagai kedaluwarsa atau, lebih buruk, menerima persetujuan yang dimaksudkan untuk percobaan sebelumnya. Minta tantangan baru, tampilkan, dan biarkan pengguna bertindak atas tantangan yang sekarang ada di layar.

Dua percobaan dengan jeda singkat di antaranya adalah nilai bawaan yang wajar; loop tanpa batas bukan. Jika percobaan kedua gagal dengan cara yang sama, berhentilah dan laporkan alih-alih melanjutkan.

Apa yang tidak boleh dilakukan klien

Klien tidak boleh melakukan beberapa hal yang tampak membantu dan sebenarnya tidak. Klien tidak boleh terus mengirim notifikasi push sampai seseorang mengetuk “setujui”, karena itu melatih pengguna menyetujui permintaan yang tidak mereka mulai dan itulah tepatnya perilaku yang diandalkan kit phishing. Klien tidak boleh beralih ke faktor yang lebih lemah karena faktor kuat gagal, dan tidak boleh menonaktifkan pemeriksaan identitas server untuk melewati keluhan sertifikat yang muncul pada saat bersamaan. Ketiga jalan pintas itu masing-masing mengubah kegagalan autentikasi menjadi insiden keamanan.

Klien juga tidak boleh menelan kegagalan itu diam-diam. Klien yang menutup koneksi dan menampilkan pemutar berputar membuat pengguna tidak tahu apakah harus mencoba lagi, menunggu, atau menelepon dukungan. Tampilkan kegagalannya bersama jenis faktor dan kode singkat, jaga pesannya bebas rahasia, dan buat tindakan coba ulang menjadi eksplisit, bukan otomatis.

Jika permintaan tidak dimulai oleh orang di depan papan ketik, tindakan yang benar adalah membiarkannya ditolak dan melaporkannya melalui jalur dukungan yang terverifikasi. Menyetujui permintaan demi menghentikan kebisingan adalah pola kegagalan, bukan perbaikannya.

Apa yang perlu dicatat untuk dukungan

Bagi tim dukungan, catatan yang berguna itu kecil. Perkiraan waktu dengan zona waktu, akun, klien dan versi, jenis faktor, serta status non-rahasia setiap percobaan: diminta, ditolak, kedaluwarsa, disetujui tetapi ditolak oleh kebijakan.

Perhatikan juga jam klien dan server. TOTP adalah pemeriksaan jendela waktu, sehingga perangkat yang jamnya bergeser menghasilkan kode yang tampak sah dan gagal setiap kali, dan klien yang melaporkan kode tidak sah tanpa menyebut pergeserannya mengirim orang untuk mengatur ulang kredensial yang tidak pernah salah. Pengguna yang loginnya berulang kali gagal harus memeriksa versi klien yang didukung, status pendaftaran, dan alur pemulihan yang didokumentasikan sebelum menghasilkan lebih banyak permintaan.

Jalur pemulihan layak mendapat perhatian yang sama dengan jalur login. Alur kerja untuk perangkat yang hilang ada justru agar penolakan tidak menjadi izin untuk melewati autentikasi, dan klien harus menautkan proses organisasi yang didokumentasikan alih-alih mengarang sendiri.

Aturan yang harus menjadi dasar adalah penolakan itu hasil, bukan hambatan. Laporkan sekali, dengan jelas, dengan konteks cukup untuk bertindak, dan biarkan percobaan berikutnya menjadi baru. Panduan CISA tentang MFA yang tahan phishing menjelaskan mengapa pola “tanya sampai disetujui” berbahaya sejak awal, dan itulah rujukan yang layak dikutip ketika seseorang mengusulkan loop percobaan ulang. Segala yang ditambahkan klien setelah penolakan harus membuat keputusan berikutnya lebih mudah bagi manusia, bukan mengambil keputusan itu darinya.