คำขอ MFA ของ VPN ถูกปฏิเสธ: ไคลเอนต์ควรทำอย่างไร

คำขอ MFA ที่ถูกปฏิเสธดูเหมือนปัญหาเครือข่ายและไม่ใช่เช่นนั้น เซิร์ฟเวอร์ขอปัจจัยที่สอง ปัจจัยนั้นกลับมาเป็นลบหรือไม่เคยมาถึง และเซสชันถูกปฏิเสธก่อนที่จะมีอุโมงค์ใด ๆ สิ่งที่เกิดขึ้นต่อไปคือคำถามเรื่องพฤติกรรมของไคลเอนต์: แสดงความล้มเหลวและให้ผู้ใช้เริ่มความพยายามใหม่ที่สะอาด หรือลองใหม่ในลักษณะที่สร้างคำขอเพิ่มขึ้นและในที่สุดก็กระตุ้นการป้องกันบัญชี เส้นทางที่สองคือวิธีที่รหัสที่พิมพ์ผิดหนึ่งครั้งกลายเป็นบัญชีที่ถูกล็อก

ตรวจสอบว่าคำขอใดล้มเหลว

เริ่มด้วยการระบุว่าคำขอใดล้มเหลว การแจ้งเตือนแบบพุช รหัส TOTP ข้อความยืนยัน FIDO และโฟลว์ SAML ล้มเหลวต่างกันไป และไคลเอนต์มักรู้ว่าตนขอสิ่งใด การปฏิเสธ ความท้าทายที่หมดอายุ และความล้มเหลวในการส่งที่ไม่เคยถึงอุปกรณ์ล้วนจบลงด้วยข้อผิดพลาดทั่วไปเดียวกัน ดังนั้นความแตกต่างมักอยู่รอดเฉพาะในสถานะของไคลเอนต์เอง

สถานะนั้นควรบันทึกอย่างแม่นยำ บันทึกตัวระบุความท้าทายหรือข้อมูลอ้างอิงธุรกรรม ประเภทปัจจัย เวลาประทับ และผลลัพธ์ แต่ไม่บันทึกรหัสหรือข้อความยืนยันเลย ตัวระบุความท้าทายคือสิ่งที่ทำให้ผู้ดูแลระบบค้นหาเหตุการณ์ฝั่งผู้ให้บริการระบุตัวตนได้ หากไม่มี การสนทนากับฝ่ายสนับสนุนจะเริ่มด้วย «ช่วงใดช่วงหนึ่งในชั่วโมงที่ผ่านมา» และมักจบลงตรงนั้น มองว่าเป็นข้อมูลเมตาสำหรับการวินิจฉัย ไม่ใช่ความลับ

ลองใหม่หนึ่งครั้งอย่างตั้งใจด้วยความท้าทายใหม่

การลองใหม่ควรเป็นการพยายามใหม่ด้วยความท้าทายใหม่ ไม่ใช่การเล่นซ้ำของอันเก่า เมื่อไคลเอนต์ใช้ความท้าทายก่อนหน้าใหม่ ผู้ให้บริการระบุตัวตนจะปฏิเสธว่าเก่าหรือแย่กว่านั้นคือยอมรับการอนุมัติที่ตั้งใจไว้สำหรับความพยายามก่อนหน้า ขอความท้าทายใหม่ แสดงมัน และให้ผู้ใช้ดำเนินการกับสิ่งที่อยู่บนหน้าจอตอนนี้

สองความพยายามโดยมีช่วงพักสั้น ๆ ระหว่างกันเป็นค่าเริ่มต้นที่สมเหตุสมผล ลูปที่ไม่จำกัดไม่ใช่ หากความพยายามที่สองล้มเหลวในลักษณะเดียวกัน ให้หยุดและรายงานแทนที่จะทำต่อ

สิ่งที่ไคลเอนต์ไม่ควรทำ

ไคลเอนต์ไม่ควรทำหลายสิ่งซึ่งดูเหมือนเป็นประโยชน์แต่ไม่ใช่ ไคลเอนต์ไม่ควรส่งการแจ้งเตือนแบบพุชซ้ำ ๆ จนกว่าจะมีคนแตะ «อนุมัติ» เพราะนั่นฝึกให้ผู้ใช้อนุมัติคำขอที่พวกเขาไม่ได้เริ่มเอง และเป็นพฤติกรรมที่ชุดเครื่องมือฟิชชิงอาศัยอยู่พอดี ไคลเอนต์ไม่ควรถอยไปใช้ปัจจัยที่อ่อนกว่าเพียงเพราะปัจจัยที่แข็งแรงล้มเหลว และไม่ควรปิดการตรวจสอบตัวตนของเซิร์ฟเวอร์เพื่อหลีกเลี่ยงข้อร้องเรียนเรื่องใบรับรองที่ปรากฏขึ้นในเวลาเดียวกัน แต่ละทางลัดทั้งสามนี้เปลี่ยนความล้มเหลวในการยืนยันตัวตนให้เป็นเหตุการณ์ด้านความปลอดภัย

ไคลเอนต์ไม่ควรกลืนความล้มเหลวอย่างเงียบ ๆ เช่นกัน ไคลเอนต์ที่ปิดการเชื่อมต่อและแสดงตัวหมุนทำให้ผู้ใช้ไม่รู้ว่าควรลองใหม่ รอ หรือโทรหาฝ่ายสนับสนุน แสดงความล้มเหลวพร้อมประเภทปัจจัยและรหัสสั้น ๆ รักษาข้อความให้ปลอดความลับ และทำให้การลองใหม่เป็นการกระทำที่ชัดเจนแทนที่จะเป็นอัตโนมัติ

หากคำขอไม่ได้เริ่มโดยบุคคลที่อยู่หน้าแป้นพิมพ์ การกระทำที่ถูกต้องคือปล่อยให้ถูกปฏิเสธและรายงานผ่านช่องทางสนับสนุนที่ผ่านการตรวจสอบ การอนุมัติคำขอเพื่อหยุดเสียงรบกวนคือรูปแบบของความล้มเหลว ไม่ใช่ทางแก้

สิ่งที่ต้องบันทึกสำหรับฝ่ายสนับสนุน

สำหรับฝ่ายสนับสนุน บันทึกที่มีประโยชน์นั้นเล็ก เวลาโดยประมาณพร้อมเขตเวลา บัญชี ไคลเอนต์และเวอร์ชัน ประเภทปัจจัย และสถานะที่ไม่เป็นความลับของแต่ละความพยายาม: ขอแล้ว ปฏิเสธแล้ว หมดอายุ อนุมัติแล้วแต่ถูกปฏิเสธโดยนโยบาย

ให้ความสนใจนาฬิกาของไคลเอนต์และเซิร์ฟเวอร์ด้วย TOTP คือการตรวจสอบหน้าต่างเวลา อุปกรณ์ที่นาฬิกาเคลื่อนไปจึงสร้างรหัสที่ดูเหมือนใช้ได้และล้มเหลวทุกครั้ง และไคลเอนต์ที่รายงานรหัสไม่ถูกต้องโดยไม่ระบุการเคลื่อนของนาฬิกาจะส่งคนไปรีเซ็ตข้อมูลรับรองที่ไม่เคยผิด ผู้ใช้ที่เข้าสู่ระบบล้มเหลวซ้ำ ๆ ควรตรวจสอบเวอร์ชันไคลเอนต์ที่รองรับ สถานะการลงทะเบียน และขั้นตอนการกู้คืนที่บันทึกไว้ก่อนสร้างคำขอเพิ่ม

เส้นทางการกู้คืนสมควรได้รับการดูแลเช่นเดียวกับเส้นทางการเข้าสู่ระบบ ขั้นตอนการทำงานสำหรับอุปกรณ์ที่สูญหาย มีอยู่เพื่อไม่ให้การปฏิเสธกลายเป็นสิทธิ์ในการข้ามการยืนยันตัวตน และไคลเอนต์ควรเชื่อมโยงไปยังกระบวนการที่บันทึกไว้ขององค์กรแทนที่จะคิดค้นขึ้นเอง

หลักการที่ควรยึดคือการปฏิเสธเป็นผลลัพธ์ ไม่ใช่อุปสรรค รายงานหนึ่งครั้งอย่างชัดเจนพร้อมบริบทเพียงพอต่อการดำเนินการ และปล่อยให้ความพยายามครั้งถัดไปเป็นครั้งใหม่ แนวทางของ CISA เกี่ยวกับMFA ที่ต้านทานฟิชชิง อธิบายว่าเหตุใดรูปแบบ «ถามจนกว่าจะอนุมัติ» จึงเป็นอันตรายตั้งแต่แรก และเป็นแหล่งอ้างอิงที่ควรค่าแก่การอ้างถึงเมื่อมีคนเสนอให้ใช้ลูปการลองใหม่ ทุกสิ่งที่ไคลเอนต์เพิ่มหลังการปฏิเสธควรทำให้การตัดสินใจครั้งถัดไปง่ายขึ้นสำหรับมนุษย์ ไม่ใช่พรากการตัดสินใจไปจากพวกเขา