OpenVPN rớt một phiên OTP về sau: xác thực lại cần gì

Về phía máy khách, nó giống như một lần ngắt kết nối ngẫu nhiên sau một giờ làm việc. Biểu tượng trên khay biến mất, đường hầm được dựng lại, và nhật ký hiển thị lỗi xác thực thay vì lỗi mạng. Điều thực sự xảy ra là phiên đã thương lượng lại và lần bắt tay thứ hai cần thông tin đăng nhập mà máy khách không còn bản sao hợp lệ. Một mã dùng một lần đã hoạt động khi đăng nhập không thể hoạt động lần nữa, nên việc đổi khóa thất bại đúng như thiết kế.

Cách sửa là quyết định lần bắt tay thứ hai sẽ trình bày gì, chứ không phải một bộ đếm thử lại dài hơn.

Đi qua cuộc trao đổi từ góc nhìn của máy khách

Khi đăng nhập, máy khách gửi tên người dùng, mật khẩu và một mã từ thiết bị token, và máy chủ chấp nhận tổ hợp đó. Sau đó phiên chạy cho đến khi một tác nhân thương lượng lại kích hoạt, khởi động một lần bắt tay TLS mới bên trong đường hầm hiện có. Lần bắt tay đó yêu cầu xác thực lần nữa. Nếu đường xác thực của máy chủ chờ một mật khẩu cộng một mã dùng một lần hiện hành, máy khách không có mã mới để trình bày trừ khi người dùng có mặt để gõ.

Hầu hết máy khách không mở hộp nhắc giữa phiên, nên lần bắt tay hết thời gian và đường hầm rớt. Người dùng thấy việc kết nối lại, không phải hộp nhắc xác thực, đó là lý do báo cáo đầu tiên thường đổ lỗi cho mạng.

auth-gen-token thay đổi ai trả lời câu hỏi thứ hai

Tùy chọn auth-gen-token cho phép máy chủ cấp một token sau khi đăng nhập thành công, và các lần thương lượng lại sau đó trình bày token đó thay vì lặp lại mật khẩu và mã. Tài liệu hướng dẫn ghi thời hạn và hành vi gia hạn của nó, và token phải được xem như thông tin đăng nhập có ngày hết hạn riêng. Trên đường mặc định, máy chủ tự xác thực token thay vì gọi lại bộ xác thực mật khẩu bên ngoài.

Với một tích hợp xác thực bên ngoài, sự phân chia đó thay đổi. Plugin phải hiểu trạng thái token và áp dụng các kiểm tra riêng, vì máy chủ không còn là thành phần duy nhất quyết định phiên có tiếp tục hay không. Coi token như một mã dùng một lần dạng số nữa không phải là cách triển khai tính năng này.

Quyết định điều gì xảy ra với trạng thái tài khoản

Một token sống lâu hơn quyền truy cập của tài khoản là một lỗ hổng chính sách. Hãy quyết định tài khoản bị vô hiệu hóa, tư cách thành viên nhóm bị gỡ bỏ hay thiết bị bị thu hồi có hiệu lực thế nào khi token vẫn còn hợp lệ. Thời hạn token ngắn làm cửa sổ nhỏ lại; một đường thu hồi rõ ràng khiến nó trở thành có chủ đích. Hãy viết câu trả lời trước khi bật tùy chọn, vì đường mặc định không hỏi bộ xác thực bên ngoài ở mỗi lần thương lượng lại.

Trong một triển khai nhiều máy chủ, bí mật ký token phải được chia sẻ, nếu không máy khách có thể bị gửi đến một nút không thể xác thực token của nó.

Hãy kiểm tra hết hạn và kết nối lại, không chỉ đăng nhập

Giảm khoảng thương lượng lại trong một hồ sơ thử nghiệm để lần bắt tay thứ hai diễn ra ngay trước mắt bạn, rồi theo dõi cả hai nhật ký. Xác nhận token được cấp khi đăng nhập, được trình bày khi đổi khóa, và được gia hạn hoặc cấp lại theo thời hạn đã cấu hình. Sau đó ép token hết hạn và một lần kết nối lại đầy đủ, vì một máy khách kết nối lại sạch vẫn có thể thất bại trên đường đổi khóa.

Hãy kiểm tra việc gỡ tài khoản sau cùng. Trường hợp đó cho bạn biết chính sách bạn viết có được thực thi hay chỉ được ghi thành tài liệu.

Đừng sửa nó bằng cách tắt gia hạn

Đặt khoảng thương lượng lại về không trên cả hai đầu loại bỏ triệu chứng và kéo theo cả việc luân chuyển khóa. Điều đó giấu một vấn đề phát lại thông tin đăng nhập sau một thay đổi chính sách mà không ai xem xét. Hãy giữ việc gia hạn, và chọn giữa token do máy chủ cấp và một thử thách tương tác mới dựa trên việc có người dùng hiện diện hay không.

Một bộ đếm thử lại dài hơn không làm một mã đã tiêu thành hợp lệ lần nữa. Nó chỉ trì hoãn việc ngắt kết nối và khiến nhật ký khó đọc hơn.