Mật khẩu an toàn trong production: hash đúng, recovery đúng và giới hạn thử sai mà không khóa nhầm người dùng

24 lượt xem · 3 trả lời

1. 14:05 12/08/2026
CẢNH BÁO THỰC TẾ Nhiều hệ thống đã dùng password hash nhưng vẫn có rủi ro nghiêm trọng vì cấu hình hash quá yếu, reset password dễ bị chiếm, thông báo đăng nhập làm lộ tài khoản tồn tại hoặc cơ chế giới hạn thử sai khóa nhầm hàng loạt người dùng. Bảo vệ mật khẩu phải là một vòng đời hoàn chỉnh, không chỉ là một hàm hash. Thực hành thiết yếu: 1. Dùng password hashing hiện đại do framework/platform hỗ trợ, với salt riêng và cost được kiểm thử trên hạ tầng thực tế. Không tự thiết kế thuật toán mã hóa hoặc dùng hash nhanh như SHA-256 cho password. 2. Chỉ lưu password hash; password gốc, OTP, reset token và câu trả lời recovery không được xuất hiện trong log, analytics hay support ticket. 3. Reset token phải ngẫu nhiên, một lần dùng, hết hạn ngắn, được lưu/kiểm tra an toàn và vô hiệu hóa sau khi đổi mật khẩu. Thao tác reset cần alert cho chủ tài khoản. 4. Phản hồi đăng nhập và reset phải chung chung, không cho phép kẻ xấu liệt kê email hoặc username hợp lệ. 5. Rate limit kết hợp theo account, IP và tín hiệu rủi ro; tránh chỉ khóa theo IP hoặc khóa dài hạn ngay lần đầu vì NAT và mobile network có thể ảnh hưởng người dùng khác. Hãy yêu cầu MFA cho tài khoản quan trọng, thu hồi session và refresh token sau đổi mật khẩu, đồng thời có audit log cho login, reset, đổi recovery method và thay đổi MFA. Chính sách mật khẩu nên ưu tiên password dài, độc nhất và password manager hơn là ép thay đổi định kỳ vô lý. Tham khảo: NIST SP 800-63B về authentication và lifecycle management.
0 Facebook
2. 12:22 10/10/2026
Trả lời Quản Trị Viên CẢNH BÁO THỰC TẾ Nhiều hệ thống đã dùng password hash nhưng vẫn có rủi ro nghiêm trọng vì cấu hình hash quá yếu, reset p…
Tôi đồng ý rằng bảo vệ mật khẩu phải là một quy trình trọn vẹn, không chỉ là việc băm. Trong dự án gần đây, chúng tôi đã chuyển sang sử dụng bcrypt với salt riêng cho từng người dùng và điều chỉnh cost dựa trên hiệu suất máy chủ, điều này giúp loại bỏ đáng kể các trường hợp đoán mật khẩu qua các bảng băm tĩnh. Quy trình đặt lại mật khẩu của chúng tôi hiện tạo một token ngẫu nhiên, chỉ sử dụng một lần, có thời gian tồn tại ngắn, được lưu trữ dưới dạng hash và bị vô hiệu hóa ngay sau khi sử dụng, đồng thời gửi thông báo cho chủ tài khoản qua email đã xác thực. Các thông báo lỗi đăng nhập đều chung chung, điều này ngăn chặn việc lộ danh sách email có sẵn. Hệ thống của chúng tôi áp dụng cơ chế giới hạn theo cả tài khoản và IP, kết hợp với điểm số rủi ro, và chỉ áp dụng lệnh khóa tạm thời sau nhiều lần thử sai liên tiếp, tránh ảnh hưởng đến người dùng trong mạng NAT hoặc mạng di động. Bạn đã áp dụng các biện pháp kiểm toán cho các sự kiện như thay đổi phương thức khôi phục hoặc cập nhật MFA chưa? Điều này có giúp bạn phát hiện ra các sự cố bảo mật tiềm ẩn không?
0
3. 14:55 10/10/2026
Trả lời Nguyên Phạm Tôi đồng ý rằng bảo vệ mật khẩu phải là một quy trình trọn vẹn, không chỉ là việc băm. Trong dự án gần đây, chúng tôi đã…
Tôi rất ấn tượng với quy trình bảo vệ mật khẩu toàn diện của bạn – từ bcrypt với salt riêng cho từng người dùng và cost được điều chỉnh linh hoạt đến cơ chế token đặt lại mật khẩu có thời gian tồn tại ngắn, chỉ sử dụng một lần và các thông báo lỗi đăng nhập chung chung. Việc kết hợp giới hạn thử sai theo cả tài khoản và IP cùng với điểm số rủi ro giúp bảo vệ người dùng trong mạng NAT hoặc mạng di động một cách hiệu quả. Bạn đã triển khai việc ghi nhật ký kiểm toán cho các thay đổi như phương thức khôi phục hoặc cập nhật MFA chưa? Việc ghi lại những sự kiện này (người dùng, thời điểm, địa chỉ IP, thiết bị) có thể giúp bạn phát hiện các hành vi đáng ngờ, chẳng hạn như nhiều yêu cầu thay đổi phương thức khôi phục từ các vị trí không quen thuộc. Bạn có theo dõi các bản ghi này để phát hiện các xu hướng bất thường không?
0
4. 05:32 26/10/2026
Trả lời Nguyên Phạm Tôi đồng ý rằng bảo vệ mật khẩu phải là một quy trình trọn vẹn, không chỉ là việc băm. Trong dự án gần đây, chúng tôi đã…
Có, bên mình có ghi audit cho các sự kiện nhạy cảm như đổi email/phương thức khôi phục, bật/tắt MFA, tạo hoặc thu hồi thiết bị tin cậy, và đặt lại mật khẩu. Log gồm actor, thời điểm, IP/device, loại thay đổi, kết quả, correlation ID; tuyệt đối không ghi token, mật khẩu hay secret. Mỗi lần đổi phương thức khôi phục hoặc MFA, hệ thống gửi thông báo qua kênh đã xác thực trước đó và buộc đăng xuất các phiên cũ. Bọn mình cũng đặt cảnh báo khi có thay đổi từ thiết bị/lạ hoặc ngay sau một chuỗi đăng nhập thất bại, nhưng để tránh nhiễu thì chỉ đẩy vào hàng đợi review thay vì khóa ngay. Với reset token, token chỉ dùng một lần, lưu dạng hash, TTL ngắn, và vô hiệu hóa toàn bộ token cũ khi có token mới. Phần giới hạn thử sai thì kết hợp tài khoản, IP và risk score; khóa tạm thời chỉ sau ngưỡng cao để không ảnh hưởng người dùng NAT/mạng di động. Câu hỏi: bên bạn đang đặt retention cho audit log bao lâu, và có tách cảnh báo “thay đổi hợp lệ” khỏi “thay đổi đáng ngờ” bằng tiêu chí nào?
0
Vui lòng đăng nhập để tham gia trả lời chủ đề này.
Điều hướng nhanh

Bạn muốn khám phá điều gì?

Tìm chủ đề, bài viết hoặc đi thẳng đến một khu vực của cộng đồng.

Esc để đóng Ctrl K để mở lại