Mã thử thách tĩnh nằm ở đâu trong một lần đăng nhập OpenVPN

Ứng dụng hiển thị ô thứ hai sau trường mật khẩu, bạn gõ mã từ token phần cứng, và đăng nhập vẫn thất bại với lỗi xác thực. Ô đó tồn tại, nghĩa là hồ sơ đã yêu cầu nó. Việc máy chủ có bao giờ nhận được giá trị ở dạng nó hiểu hay không là câu hỏi khác, và đó là câu hỏi đáng trả lời trước.

Hãy bắt đầu từ lời nhắc mà ứng dụng của bạn thực sự hiển thị

Một hồ sơ có thể mang chỉ thị thử thách tĩnh với chuỗi lời nhắc và một cờ kiểm soát việc phản hồi có được hiển thị khi bạn gõ hay không. Lời nhắc là thứ bạn thấy trong hộp thoại; cờ là tùy chọn hiển thị cho chính ô nhập đó. Không cái nào cho máy chủ biết cách xác minh bất cứ điều gì.

Hãy đếm các trường bạn thực sự được cấp. Một trường cho tên người dùng cộng một trường bị che là đăng nhập mật khẩu thông thường không có thử thách nào. Trường thứ hai xuất hiện sau mật khẩu, với nhãn riêng, là ứng dụng đang triển khai tương tác thử thách.

Nếu ô thứ hai không bao giờ xuất hiện trong ứng dụng bạn dùng, ứng dụng đó có thể không triển khai tương tác, hoặc chỉ triển khai qua một giao diện khác như giao diện quản trị. Kiểm tra ứng dụng rẻ hơn viết lại hồ sơ, và thường đó chính là nơi sự không khớp thực sự nằm.

Những gì máy chủ phải hỗ trợ sẵn

Hồ sơ mô tả những gì ứng dụng nên thu thập. Nó không bật xác minh trên máy chủ, và một máy chủ thiếu tích hợp xác thực tương ứng sẽ chỉ nhận được một mật khẩu mà nó không nhận ra. Đó là lý do một số triển khai hiển thị lời nhắc và từ chối mọi mã, và cũng là lý do câu trả lời của người vận hành về việc cơ chế nào thực hiện kiểm tra mới là câu trả lời quan trọng.

Hãy hỏi người vận hành cơ chế nào thực hiện kiểm tra. Đó có thể là một plugin nói chuyện với PAM, một móc script xác thực phản hồi với dịch vụ token, hoặc một tích hợp dựa trên quản trị tự phân tích giá trị đã đóng gói. Mỗi loại mong đợi một đầu vào hơi khác.

Ở đây cũng cần hiệu chỉnh kỳ vọng. Lời nhắc thứ hai là một cơ chế nhập liệu, không phải bằng chứng rằng yếu tố thứ hai đang được áp dụng, vì việc áp dụng diễn ra ở phía máy chủ và chỉ lộ ra khi bạn thử một mã sai.

Trường được mã hóa mà giao diện quản trị gửi đi

Khi giao diện điều khiển kết nối qua giao diện quản trị, mật khẩu và phản hồi thử thách được đóng gói vào một giá trị duy nhất trước khi gửi. Tài liệu tham chiếu giao diện quản trị mô tả định dạng: một tiền tố, rồi mật khẩu và phản hồi như các thành phần Base64 riêng biệt.

Base64 là mã hóa, không phải bảo vệ. Nó không giấu gì với bất kỳ ai đọc được trường đó, và nó không biến một mã dùng một lần thành thứ tái sử dụng được. Giá trị đã đóng gói xứng đáng được đối xử như mật khẩu: ra khỏi hồ sơ chia sẻ, ra khỏi dòng lệnh và ra khỏi nhật ký chẩn đoán.

Cách mã hóa đó cũng là nguồn nhầm lẫn phổ biến nhất, vì hiện có ba dạng trông giống nhau và không thể hoán đổi. Một tệp thông tin đăng nhập đơn giản chứa mật khẩu. Việc nối nguyên văn mật khẩu và mã chứa một chuỗi khác. Phản hồi đã đóng gói của ứng dụng quản trị chứa dạng thứ ba. Hãy xác nhận đường xác minh của bạn mong đợi dạng nào trước khi thay đổi một trường chỉ vì một lỗi đã biến mất.

Tĩnh và động: thời điểm khác nhau

Thử thách tĩnh được biết trước khi thông tin đăng nhập đầu tiên được gửi, nên ứng dụng có thể hỏi trước. Thử thách động đến muộn hơn, do luồng xác thực gửi sau khi một cuộc trao đổi đã bắt đầu, và nó cần một ứng dụng có thể xử lý yêu cầu giữa cuộc trò chuyện.

Hỗ trợ cái này không cho bạn cái kia. Một chỉ thị hồ sơ cấu hình lời nhắc tĩnh không triển khai thử thách do máy chủ khởi xướng, và một giao diện xử lý yêu cầu động có thể vẫn không hiển thị loại tĩnh. Đọc xem bên nào khởi xướng yêu cầu là cách nhanh nhất để phân biệt chúng.

Vận hành không giám sát là nơi điều này trở thành câu hỏi thiết kế chứ không phải câu hỏi giao diện. Một mã đã lưu không phải là thông tin đăng nhập bền vững lúc khởi động, và việc kết nối lại sau nhiều giờ sẽ cần nhập mới, trừ khi triển khai hỗ trợ một cách bố trí token mà người vận hành đã chủ động bật.

Hãy kiểm tra cả thành công và thất bại, không chỉ hộp thoại

Chạy cả hai nửa của bài kiểm tra. Thông tin đăng nhập đúng với phản hồi hợp lệ phải thành công; thông tin đăng nhập đúng với phản hồi cố ý sai phải bị từ chối. Nếu cả hai đều thành công, ứng dụng đang thu thập đầu vào mà không gì xác minh, và hộp thoại đã bị nhầm là một biện pháp kiểm soát. Chỉ bài kiểm tra đó bắt được nhiều triển khai hơn bất kỳ cuộc rà soát hồ sơ nào.

Sau đó lặp lại kết nối sau khi kết nối lại, với một tài khoản chưa đăng ký, và qua ứng dụng mà người dùng của bạn thực sự chạy. Việc lời nhắc xuất hiện là hành vi của ứng dụng; việc một mã sai bị từ chối là máy chủ đang áp đặt điều gì đó.