Email mật khẩu chứng minh khả năng đảo ngược, không phải một sơ đồ

Một dịch vụ gửi mật khẩu hiện tại của người dùng qua email đã chứng minh một điều: nó có thể lấy được bí mật đó ở dạng mà nó có thể gửi đi. Nó chưa chứng minh cột, thuật toán hay thư viện nào tạo ra bí mật ấy. Sự phân biệt này quan trọng vì phát hiện là có thật và kết luận mà người ta rút ra thường quá cụ thể. Khả năng đảo ngược ở đâu đó trên đường đi là cơ chế; một định dạng lưu trữ phỏng đoán thì không.

Hãy giữ bằng chứng ở mức đó, và phần còn lại của đánh giá sẽ vẫn chính xác.

Việc gửi lại bí mật cũ chứng minh điều gì

Một bộ xác minh một chiều không thể tạo ra mật khẩu gốc, vì nó được thiết kế để không thể đảo ngược. Nếu dịch vụ có thể gửi mật khẩu qua email, thì tại thời điểm đó nó giữ vật liệu mà từ đó mật khẩu có thể được khôi phục, hoặc nó chặn và lưu văn bản thuần trước khi băm. Dù thế nào, đường khôi phục là đảo ngược được, và đó là một phát hiện bảo mật thực sự. Điều đó không nói gì về việc cùng cơ sở dữ liệu có dùng hàm băm tốn kém cho các cột khác hay không.

Cũng hãy chú ý trường hợp trung gian: một khối đã mã hóa được lưu với khóa do ứng dụng giữ thì trên thực tế là đảo ngược được, dù từ đã mã hóa nghe có vẻ an tâm trong một báo cáo.

Vì sao đây là phát hiện về thiết kế, không phải bản đồ lưu trữ

Email chứng minh khả năng khôi phục và không xác định sơ đồ chính xác. Nó có thể là văn bản thuần, mã hóa tất định, một quy trình làm mờ của nhà cung cấp, hoặc một kho thông tin xác thực riêng chỉ dùng để khôi phục. Các phần khác nhau của một sản phẩm thường dùng cách lưu trữ khác nhau. Gán một thuật toán dựa trên một email duy nhất là kiểu khẳng định sẽ sụp đổ trong cuộc họp tiếp theo.

Điều bạn có thể nói thì hẹp hơn và hữu ích hơn: đường này có thể khôi phục bí mật, nên sản phẩm không thể khẳng định rằng không tồn tại thông tin xác thực nào có thể khôi phục. Mọi thứ xa hơn thế cần bằng chứng của nhà vận hành.

Xây dựng việc đặt lại quanh việc cấp quyền

Việc đặt lại giải quyết một vấn đề khác: chứng minh rằng người yêu cầu được phép chọn mật khẩu mới. Hướng dẫn của OWASP về việc này mô tả các token hoặc mã dùng một lần được tạo an toàn với thời hạn phù hợp, và coi giai đoạn yêu cầu là thứ cần bảo vệ khỏi việc liệt kê và tràn ngập. Một yêu cầu chưa xác thực không được tự nó thay đổi tài khoản. Hãy xác thực quyền trước khi chấp nhận phần thay thế, và làm cho token không dùng được sau một lần sử dụng thành công.

Kênh email là một phần của mô hình bảo mật. Việc sở hữu tên tài khoản không chứng minh gì, và một luồng đặt lại tiết lộ tài khoản có tồn tại hay không sẽ trao cho kẻ tấn công một danh mục để làm việc.

Vô hiệu hóa những gì mật khẩu đã bảo vệ

Đổi mật khẩu không tự động chấm dứt quyền truy cập mà nó đã cấp. Các phiên VPN đang hoạt động, thiết bị đã ghi nhớ và token do máy chủ phát hành có thể mỗi thứ có cách vô hiệu hóa riêng. Hãy quyết định có chủ đích thứ nào phải kết thúc, và xác minh rằng việc triển khai làm đúng như vậy, vì người dùng cho rằng việc đặt lại đã đăng xuất họ ở mọi nơi thường sai. Hãy ghi lại quyết định đó cùng với luồng.

Với nhà vận hành: ghi lại thành phần nào xác minh yêu cầu, thành phần nào thay đổi thông tin xác thực và các phiên liên quan được xử lý ra sao. Với người dùng: bảo vệ kênh khôi phục hợp pháp và coi mọi thông báo trả lại mật khẩu là đáng ngờ.

Đánh giá chính xác thì ngắn gọn: thông báo chứng minh điều gì, điều gì còn chưa biết và việc khôi phục có thay thế quyền truy cập bằng một quy trình được kiểm soát hay không.