SRP tránh gửi mật khẩu trong trao đổi đăng nhập; nó không khiến giá trị xác minh bị đánh cắp trở nên vô hại.
Secure Remote Password, hay SRP, cho phép máy khách và máy chủ xác thực bằng mật khẩu mà không gửi mật khẩu đó trong trao đổi thông thường của giao thức. Nó có thể giảm việc tiết lộ mật khẩu cho máy chủ vốn sẽ nhận mật khẩu khi đăng nhập.
Nó không loại bỏ mọi bí mật liên quan đến mật khẩu khỏi máy chủ. Máy chủ giữ một giá trị xác minh, và giá trị xác minh bị đánh cắp có thể hỗ trợ đoán mật khẩu ngoại tuyến. Phân biệt này rất quan trọng khi đánh giá tuyên bố về “đăng nhập không kiến thức”.
Điều gì thay đổi so với đăng nhập bằng mật khẩu thông thường?
Trong thiết kế thông thường, máy khách gửi mật khẩu qua kết nối TLS được xác thực. Máy chủ được thiết kế tốt so sánh giá trị băm mật khẩu có salt phù hợp, tránh ghi thông tin xác thực vào nhật ký và áp dụng biện pháp chống đoán. TLS bảo vệ kết nối; giá trị băm bảo vệ thông tin xác thực được lưu theo một cách khác.
SRP thay đổi quá trình trao đổi. Khi đăng ký, hệ thống thiết lập salt và vật liệu xác minh. Khi đăng nhập, hai bên dùng các giá trị giao thức mới cùng bí mật riêng của mình để thiết lập và xác nhận vật liệu khóa chung. Máy khách dùng mật khẩu; máy chủ dùng giá trị xác minh. Máy khách trung thực không gửi chính mật khẩu làm nội dung đăng nhập.
Đặc tả SRP trong RFC 2945 giải thích nền tảng của giao thức. Các cấu hình và triển khai về sau cần được rà soát tham số chính xác cùng việc kiểm tra thông điệp; gọi thiết kế là “SRP” không chứng minh mọi lựa chọn triển khai đều đúng đắn.
| Câu hỏi | Đăng nhập mật khẩu qua TLS thông thường | Trao đổi SRP triển khai đúng |
|---|---|---|
| Máy chủ ứng dụng có nhận mật khẩu đã nhập lúc đăng nhập không? | Thông thường là có | Không phải trong trao đổi giao thức |
| Vật liệu xác thực nhạy cảm nào được lưu? | Thường là giá trị băm mật khẩu có salt | Salt và giá trị xác minh dẫn xuất từ mật khẩu |
| Cơ sở dữ liệu bị đánh cắp có hỗ trợ đoán ngoại tuyến không? | Có, tùy vật liệu được lưu | Có, vật liệu xác minh SRP bị đánh cắp có thể hỗ trợ đoán |
| Có bảo vệ trước trình ghi phím không? | Không | Không |
| Có tự động mã hóa lịch sử tin nhắn không? | Không | Không |
Vì sao giá trị xác minh bị đánh cắp vẫn đáng lo
Mục 3.3 của RFC 5054 bàn rõ về giá trị xác minh bị đánh cắp. Mục này giải thích rằng giá trị xác minh có thể cho phép kẻ tấn công giả làm máy chủ và thực hiện tấn công từ điển để khôi phục mật khẩu.
Điểm phân biệt quan trọng là giá trị xác minh không đơn thuần là token đăng nhập máy khách có thể tái sử dụng. Điều đó không khiến nó vô hại. Kẻ tấn công có thể thử các mật khẩu ứng viên với vật liệu bị đánh cắp thay vì giải bài toán logarit rời rạc cho mỗi bí mật có thể có. Mật khẩu yếu hoặc dùng lại vẫn là rủi ro nghiêm trọng.
Giới hạn tốc độ trực tuyến có thể làm chậm các lần thử vào dịch vụ đang chạy, nhưng không kiểm soát tính toán trên cơ sở dữ liệu bị đánh cắp. Bảo vệ cơ sở dữ liệu, xử lý mật khẩu cẩn thận và mật khẩu mạnh, riêng biệt vẫn cần thiết.
Những gì SRP không bảo vệ
Thiết bị đầu cuối bị xâm phạm: Phần mềm độc hại có thể lấy mật khẩu trước khi giao thức bắt đầu hoặc đánh cắp phiên đã xác thực sau đó.
Trang đăng nhập độc hại: Nếu chính trang yêu cầu mật khẩu là thù địch, nó có thể gửi nội dung đã nhập đi nơi khác. Ứng dụng web vẫn cần một đường phân phối đáng tin cậy.
Mọi đường khôi phục: Quy trình email, SMS hoặc hỗ trợ cấp quyền truy cập tài khoản có những yêu cầu riêng. Phương thức đăng nhập thông thường mạnh nhất vẫn có thể bị suy yếu bởi đường dự phòng kém hơn.
Mọi tấn công mạng chủ động: Tham số giao thức, xác thực đầu vào, xác nhận lẫn nhau và kết nối được xác thực bao quanh đều quan trọng. Đừng thay các biện pháp TLS được quy định cho triển khai bằng khẩu hiệu “mật khẩu không bao giờ được truyền đi”.
Siêu dữ liệu hay mã hóa trò chuyện: Xác thực trả lời câu hỏi có nên cho phép một phiên hay không. Nó không quyết định những bản ghi cuộc trò chuyện nào tồn tại hoặc ai nắm khóa giải mã tin nhắn.
Cách Livara tách đăng nhập khỏi khôi phục danh tính
Tổng quan bảo mật của Livara mô tả xác thực SRP tách biệt với giao thức nhắn tin LVR1. Tài liệu cũng mô tả bản sao lưu danh tính được mã hóa phiên bản 7, bảo vệ bằng khóa khôi phục ngẫu nhiên 256 bit riêng biệt.
Bản sao lưu được niêm phong trước khi tải lên và phục hồi danh tính mật mã, không phải lịch sử trò chuyện. Chỉ biết mật khẩu tài khoản không khôi phục được các khóa mã hóa đó. Ngược lại, tuyên bố rằng bộ phận hỗ trợ không thể tái tạo bí mật mã hóa không chứng minh rằng không thể có hành động quản lý tài khoản hay quy trình đổi mật khẩu nào.
Mô hình đe dọa cũng giữ việc thiết bị bị xâm phạm và siêu dữ liệu liên lạc nhìn thấy được trong phạm vi xem xét. Không nên dùng SRP để gán nhãn toàn bộ dịch vụ là “không kiến thức” về mọi khía cạnh hoạt động của người dùng.
Danh mục đánh giá thực tế
Với tư cách người dùng, hãy chọn mật khẩu mạnh, riêng biệt, bảo vệ thiết bị, giữ vật liệu khôi phục ở vị trí riêng phù hợp và hiểu cách thu hồi phiên. Đừng nhập bí mật vào trang không đáng tin chỉ vì trang đó tuyên bố dùng SRP.
Với tư cách người rà soát kỹ thuật, hãy yêu cầu cấu hình giao thức chính xác, cách xử lý mật khẩu thành giá trị xác minh, xác thực đầu vào, xử lý lỗi, quy trình đăng ký và thiết kế đặt lại. Rà soát cả máy khách lẫn máy chủ cùng nhau. Bao gồm kiểm thử giá trị công khai không hợp lệ, phát lại và phiên bị gián đoạn, thay vì chỉ dựa vào một lần kiểm thử đăng nhập thành công.
SRP là công cụ hữu ích để hạn chế tiết lộ mật khẩu khi xác thực. Giá trị của nó rõ hơn khi lợi ích thực được mô tả cùng rủi ro đánh cắp giá trị xác minh, xâm phạm thiết bị đầu cuối và khôi phục, thay vì được trình bày như dấu chấm hết cho các vấn đề bảo mật mật khẩu.
