Permintaan MFA VPN ditolak: apa yang patut dilakukan klien

Permintaan MFA yang ditolak kelihatan seperti masalah rangkaian dan memang bukan. Pelayan meminta faktor kedua, faktor itu kembali negatif atau tidak pernah tiba, dan sesi ditolak sebelum wujud sebarang terowong. Apa yang berlaku selepas itu ialah soal tingkah laku klien: tunjukkan kegagalan dan biarkan pengguna memulakan cubaan bersih, atau cuba semula dengan cara yang menghasilkan lebih banyak permintaan dan akhirnya mencetuskan perlindungan akaun. Laluan kedua itulah cara satu kod yang tersalah taip menjadi akaun terkunci.

Semak permintaan mana yang gagal

Mulakan dengan mengenal pasti permintaan mana yang gagal. Pemberitahuan push, kod TOTP, pernyataan FIDO dan aliran SAML masing-masing gagal secara berbeza, dan klien biasanya tahu yang mana dimintanya. Penolakan, cabaran yang tamat tempoh dan kegagalan penghantaran yang tidak pernah sampai ke peranti semuanya berakhir dengan ralat generik yang sama, jadi keadaan klien sendiri selalunya satu-satunya tempat perbezaan itu kekal.

Keadaan itu wajar direkodkan dengan tepat. Rekodkan pengecam cabaran atau rujukan transaksi, jenis faktor, cap masa dan hasilnya, tetapi jangan sekali-kali kod atau pernyataannya. Pengecam cabaran itulah yang membolehkan pentadbir mencari peristiwa di pihak pembekal identiti; tanpanya perbualan sokongan bermula dengan “suatu masa dalam sejam yang lalu” dan biasanya berakhir di situ. Anggapnya sebagai metadata diagnostik, bukan rahsia.

Cuba sekali lagi, dengan sengaja, menggunakan cabaran baharu

Cubaan semula sepatutnya cubaan baharu dengan cabaran baharu, bukan main semula cabaran lama. Apabila klien menggunakan semula cabaran sebelumnya, pembekal identiti sama ada menolaknya sebagai lapuk atau, lebih teruk, menerima kelulusan yang dimaksudkan untuk cubaan terdahulu. Minta cabaran baharu, tunjukkannya dan biarkan pengguna bertindak atas cabaran yang sedang ada di skrin.

Dua cubaan dengan jeda singkat antaranya ialah nilai lalai yang munasabah; gelung tanpa had bukan. Jika cubaan kedua gagal dengan cara yang sama, berhenti dan laporkan daripada meneruskan.

Apa yang tidak boleh dilakukan klien

Klien tidak boleh melakukan beberapa perkara yang kelihatan membantu tetapi sebenarnya tidak. Ia tidak boleh terus menghantar pemberitahuan push sehingga seseorang mengetik “luluskan”, kerana itu melatih pengguna meluluskan permintaan yang tidak mereka mulakan dan itulah tepat tingkah laku yang diharapkan oleh kit pancingan data. Ia tidak boleh beralih kepada faktor yang lebih lemah kerana faktor kuat gagal, dan tidak boleh mematikan pemeriksaan identiti pelayan untuk melepasi aduan sijil yang muncul pada masa yang sama. Ketiga-tiga jalan pintas itu masing-masing mengubah kegagalan pengesahan menjadi insiden keselamatan.

Ia juga tidak boleh menelan kegagalan itu secara senyap. Klien yang menutup sambungan dan memaparkan pemutar berputar membiarkan pengguna tanpa idea sama ada perlu cuba lagi, menunggu atau menghubungi sokongan. Tunjukkan kegagalan dengan jenis faktor dan kod pendek, pastikan mesej bebas daripada rahsia dan jadikan tindakan cuba semula eksplisit dan bukan automatik.

Jika permintaan itu tidak dimulakan oleh orang di papan kekunci, tindakan yang betul ialah membiarkannya ditolak dan melaporkannya melalui laluan sokongan yang disahkan. Meluluskan permintaan untuk menghentikan kebisingan ialah corak kegagalan, bukan penyelesaiannya.

Apa yang perlu direkodkan untuk sokongan

Bagi pihak sokongan, rekod yang berguna itu kecil. Masa anggaran dengan zon waktu, akaun, klien dan versi, jenis faktor, serta status bukan rahsia setiap cubaan: diminta, ditolak, tamat tempoh, diluluskan tetapi ditolak oleh dasar.

Perhatikan juga jam klien dan pelayan. TOTP ialah pemeriksaan tetingkap masa, jadi peranti yang jamnya terpesong menghasilkan kod yang kelihatan sah dan gagal setiap kali, dan klien yang melaporkan kod tidak sah tanpa menyebut pesongan itu menghantar orang untuk menetapkan semula kelayakan yang tidak pernah salah. Pengguna yang log masuknya berulang kali gagal patut menyemak versi klien yang disokong, status pendaftaran dan aliran pemulihan yang didokumenkan sebelum menghasilkan lebih banyak permintaan.

Laluan pemulihan wajar mendapat penjagaan yang sama seperti laluan log masuk. Aliran kerja untuk peranti hilang wujud semata-mata supaya penolakan tidak menjadi kebenaran untuk memintas pengesahan, dan klien patut memautkan proses organisasi yang didokumenkan dan bukannya mereka satu sendiri.

Peraturan yang harus menjadi asas ialah penolakan itu hasil, bukan halangan. Laporkan sekali, dengan jelas, dengan konteks yang cukup untuk bertindak, dan biarkan cubaan seterusnya menjadi baharu. Panduan CISA tentang MFA yang tahan pancingan data menjelaskan mengapa corak “tanya sehingga diluluskan” berbahaya sejak awal, dan itulah rujukan yang wajar dipetik apabila seseorang mencadangkan gelung cubaan semula. Segala yang ditambah klien selepas penolakan sepatutnya memudahkan keputusan seterusnya bagi manusia, bukan mengambil keputusan itu daripadanya.