Suy nghĩ tốt nhất là không phát minh lại bánh xe. Nhưng, tôi hiểu, trong thế giới PHP, có thể khó tìm thấy một thành phần chất lượng cao đã làm điều đó (thậm chí tôi khá chắc chắn rằng các khung công tác thực hiện những điều đó và việc triển khai của chúng đã được kiểm tra, vững chắc, được xem xét mã, v.v. )
Sử dụng PBKDF2 hoặc Bcrypt nếu bạn có thể . Nó đã được thực hiện cho điều đó.
Đặt vấn đề: cả hai thuật toán có thể làm cho quá trình băm chậm tùy ý, đó chính xác là những gì bạn muốn khi băm mật khẩu (các lựa chọn thay thế nhanh hơn có nghĩa là lực lượng vũ phu dễ dàng hơn). Tốt nhất, bạn nên điều chỉnh các tham số để quá trình trở nên chậm hơn và chậm hơn theo thời gian trên cùng một phần cứng, trong khi phần cứng mới, nhanh hơn được phát hành.
Nếu bạn không thể, ít nhất đừng sử dụng MD5 / SHA1. Không bao giờ. Hãy quên nó đi . Sử dụng SHA512 thay thế, ví dụ. Dùng muối cũng vậy.
Đặt vấn đề: MD5 và SHA1 quá nhanh. Nếu kẻ tấn công có quyền truy cập vào cơ sở dữ liệu của bạn có chứa các giá trị băm và có một máy mạnh mẽ (thậm chí không đặc biệt), thì việc buộc mật khẩu sẽ nhanh chóng và dễ dàng. Nếu không có muối, khả năng kẻ tấn công tìm thấy mật khẩu thực sự tăng lên (điều này có thể gây hại thêm nếu mật khẩu được sử dụng lại ở nơi khác).
Trong PHP 5.5.0 trở lên, sử dụng password_hashvà password_verify.
Đặt vấn đề: gọi một chức năng được cung cấp bởi khung là dễ dàng, vì vậy nguy cơ mắc lỗi sẽ giảm. Với hai hàm này, bạn không phải suy nghĩ về các tham số khác nhau, chẳng hạn như hàm băm. Hàm đầu tiên trả về một chuỗi đơn sau đó có thể được lưu trữ trong cơ sở dữ liệu. Hàm thứ hai sử dụng chuỗi này để xác minh mật khẩu.
Bảo vệ bạn khỏi lực lượng vũ phu . Nếu người dùng gửi mật khẩu sai khi cô ấy đã gửi một mật khẩu sai khác 0,01 giây trước, đó là một lý do tốt để chặn mật khẩu. Trong khi con người có thể đánh máy nhanh, có lẽ họ không thể mà nhanh.
Một biện pháp bảo vệ khác là đặt giới hạn thất bại mỗi giờ. Nếu người dùng gửi 3600 mật khẩu sai trong một giờ, 1 mật khẩu mỗi giây, thật khó để tin rằng đây là người dùng hợp pháp.
Đặt vấn đề: nếu mật khẩu của bạn được băm theo cách không an toàn, lực lượng vũ phu có thể rất hiệu quả. Nếu mật khẩu được lưu trữ an toàn, lực lượng vũ trang vẫn đang lãng phí tài nguyên và băng thông mạng của máy chủ của bạn, gây ra hiệu suất thấp hơn cho người dùng hợp pháp. Phát hiện lực lượng vũ phu không dễ để phát triển và làm cho đúng, nhưng đối với bất kỳ hệ thống nhỏ bé nào, nó hoàn toàn xứng đáng.
Đừng yêu cầu người dùng của bạn thay đổi mật khẩu của họ sau mỗi bốn tuần. Điều này cực kỳ khó chịu và làm giảm tính bảo mật, vì nó khuyến khích bảo mật dựa trên nó.
Đặt vấn đề: ý tưởng buộc mật khẩu thay đổi cứ sau n tuần bảo vệ hệ thống khỏi lực lượng vũ phu là sai. Các cuộc tấn công vũ phu thường thành công trong vòng vài giây, vài phút, vài giờ hoặc vài ngày, điều này làm cho các thay đổi mật khẩu hàng tháng không liên quan. Mặt khác, người dùng rất tệ trong việc ghi nhớ mật khẩu. Nếu, hơn nữa, họ cần thay đổi chúng, họ sẽ cố gắng sử dụng mật khẩu rất đơn giản hoặc chỉ lưu ý mật khẩu của họ trên post-it.
Kiểm toán mọi thứ, mọi lúc. Lưu trữ đăng nhập, nhưng không bao giờ lưu trữ mật khẩu trong nhật ký kiểm toán. Đảm bảo rằng nhật ký kiểm toán không thể được sửa đổi (nghĩa là bạn có thể thêm dữ liệu vào cuối, nhưng không sửa đổi dữ liệu hiện có). Hãy chắc chắn rằng nhật ký kiểm toán phải được sao lưu thường xuyên. Tốt nhất, các bản ghi nên được lưu trữ trên một máy chủ chuyên dụng có quyền truy cập rất hạn chế: nếu một máy chủ khác bị hack, kẻ tấn công sẽ không thể xóa sạch các bản ghi để che giấu sự hiện diện của anh ta (và đường dẫn được thực hiện trong cuộc tấn công).
Đừng nhớ thông tin xác thực người dùng trong cookie, trừ khi người dùng yêu cầu làm điều đó (Hộp kiểm Ghi nhớ tôi phải được bỏ chọn theo mặc định để tránh lỗi của con người).