Yêu cầu MFA của VPN bị từ chối: ứng dụng khách nên làm gì

Một yêu cầu MFA bị từ chối trông như sự cố mạng và không phải vậy. Máy chủ yêu cầu yếu tố thứ hai, yếu tố đó trả về phủ định hoặc không bao giờ đến, và phiên bị từ chối trước khi có bất kỳ đường hầm nào. Điều xảy ra sau đó là câu hỏi về hành vi của ứng dụng khách: hiển thị lỗi và để người dùng bắt đầu một lần thử sạch, hay thử lại theo những cách tạo thêm yêu cầu và cuối cùng kích hoạt cơ chế bảo vệ tài khoản. Con đường thứ hai chính là cách một mã bị gõ sai trở thành một tài khoản bị khóa.

Kiểm tra yêu cầu nào đã thất bại

Hãy bắt đầu bằng việc xác định yêu cầu nào đã thất bại. Thông báo đẩy, mã TOTP, xác nhận FIDO và luồng SAML mỗi loại thất bại theo cách khác nhau, và ứng dụng khách thường biết mình đã yêu cầu loại nào. Việc từ chối, thách thức hết hạn và lỗi phân phối không bao giờ đến thiết bị đều kết thúc bằng cùng một lỗi chung, nên sự khác biệt thường chỉ còn tồn tại trong trạng thái của chính ứng dụng khách.

Trạng thái đó đáng được ghi lại chính xác. Ghi lại mã định danh thách thức hoặc tham chiếu giao dịch, loại yếu tố, dấu thời gian và kết quả, nhưng không bao giờ ghi mã hay xác nhận. Mã định danh thách thức là thứ cho phép quản trị viên tìm thấy sự kiện phía nhà cung cấp danh tính; nếu không có nó, cuộc trò chuyện với hỗ trợ bắt đầu bằng «đâu đó trong giờ qua» và thường kết thúc ở đó. Hãy coi đó là siêu dữ liệu chẩn đoán, không phải bí mật.

Thử lại một lần, có chủ đích, với thách thức mới

Một lần thử lại nên là lần thử mới với thách thức mới, không phải phát lại thách thức cũ. Khi ứng dụng khách dùng lại thách thức trước đó, nhà cung cấp danh tính hoặc từ chối vì đã cũ, hoặc tệ hơn, chấp nhận một phê duyệt vốn dành cho lần thử trước. Hãy yêu cầu thách thức mới, hiển thị nó và để người dùng thao tác trên thứ đang ở trên màn hình ngay lúc này.

Hai lần thử với khoảng nghỉ ngắn ở giữa là mặc định hợp lý; vòng lặp không giới hạn thì không. Nếu lần thử thứ hai thất bại theo cùng cách, hãy dừng lại và báo cáo thay vì tiếp tục.

Những gì ứng dụng khách không được làm

Ứng dụng khách không được làm vài việc trông có vẻ hữu ích mà không hữu ích. Không được tiếp tục gửi thông báo đẩy cho đến khi ai đó nhấn «phê duyệt», vì điều đó huấn luyện người dùng phê duyệt những yêu cầu họ không khởi tạo, và đó chính là hành vi mà các bộ công cụ lừa đảo dựa vào. Không được chuyển sang yếu tố yếu hơn chỉ vì yếu tố mạnh đã thất bại, và không được tắt kiểm tra danh tính máy chủ để lách một khiếu nại chứng chỉ xuất hiện cùng lúc. Mỗi một trong ba lối tắt đó biến một lỗi xác thực thành sự cố bảo mật.

Cũng không được nuốt lỗi trong im lặng. Ứng dụng khách đóng kết nối và hiện vòng xoay để người dùng không biết nên thử lại, chờ hay gọi hỗ trợ. Hãy hiển thị lỗi kèm loại yếu tố và mã ngắn, giữ thông báo không chứa bí mật, và làm cho hành động thử lại trở nên rõ ràng thay vì tự động.

Nếu yêu cầu không do người ngồi trước bàn phím khởi tạo, hành động đúng là để nó bị từ chối và báo cáo qua kênh hỗ trợ đã xác minh. Phê duyệt một yêu cầu để dừng tiếng ồn là kiểu thất bại, không phải cách khắc phục.

Những gì cần ghi lại cho bộ phận hỗ trợ

Với bộ phận hỗ trợ, bản ghi hữu ích thì nhỏ. Thời gian ước chừng kèm múi giờ, tài khoản, ứng dụng khách và phiên bản, loại yếu tố, và trạng thái không bí mật của từng lần thử: đã yêu cầu, bị từ chối, hết hạn, được phê duyệt nhưng bị chính sách từ chối.

Cũng hãy để ý đồng hồ của ứng dụng khách và máy chủ. TOTP là kiểm tra cửa sổ thời gian, nên thiết bị có đồng hồ bị lệch tạo ra những mã trông hợp lệ và thất bại mỗi lần, và ứng dụng khách báo mã không hợp lệ mà không nêu độ lệch sẽ khiến người ta đặt lại thông tin đăng nhập vốn chưa bao giờ sai. Người dùng có lần đăng nhập thất bại lặp lại nên kiểm tra phiên bản ứng dụng khách được hỗ trợ, trạng thái đăng ký và luồng khôi phục đã được ghi tài liệu trước khi tạo thêm yêu cầu.

Con đường khôi phục xứng đáng được chăm sóc như con đường đăng nhập. Quy trình cho thiết bị bị mất tồn tại chính xác để việc từ chối không trở thành quyền bỏ qua xác thực, và ứng dụng khách nên liên kết tới quy trình đã được ghi tài liệu của tổ chức thay vì tự nghĩ ra một quy trình.

Nguyên tắc để xây dựng là việc từ chối là một kết quả, không phải chướng ngại. Hãy báo cáo một lần, rõ ràng, với đủ ngữ cảnh để hành động, và để lần thử tiếp theo là lần mới. Hướng dẫn của CISA về MFA chống lừa đảo giải thích vì sao kiểu «hỏi cho đến khi được phê duyệt» ngay từ đầu đã nguy hiểm, và đó là tài liệu đáng trích dẫn khi ai đó đề xuất vòng lặp thử lại. Mọi thứ ứng dụng khách thêm vào sau khi bị từ chối nên làm cho quyết định tiếp theo dễ hơn với con người, không phải lấy đi quyết định của họ.