Cấu hình Devise an toàn nhất có thể là gì?

Question

Tôi sắp bắt đầu thiết lập ứng dụng Rails chỉ dành cho nhân viên tại công ty của chúng tôi để làm việc với thông tin nhạy cảm. Sẽ có một bức tường lửa, các biện pháp an ninh vật lý, vv Vấn đề của tôi bây giờ là quá trình đăng nhập cho ứng dụng.

Tôi muốn sử dụng Devise để xác thực. Cấu hình an toàn nhất có thể cho Devise là gì?

Tôi nghĩ tôi wil làm như sau:

• tài khoản Khóa sau khi một số ít nỗ lực đăng nhập thất bại
• Sử dụng config.paranoid vì vậy một kẻ tấn công không thể nói nếu họ đã đoán một giá trị địa chỉ email
• Có thể vô hiệu hóa đặt lại mật khẩu qua email?

Một số trong những điều cụ thể tôi không rõ, với dấu ngoặc kép từ devise.rb in nghiêng:

• Peppers. Devise có tùy chọn để "Thiết lập hạt tiêu để tạo mật khẩu được mã hóa". Sự hiểu biết của tôi là đây là một giá trị cụ thể cho từng ứng dụng, biến đổi mật khẩu ngu ngốc như "password123" thành "password123K # (! @ Akdlwekdf" hoặc "*%! Kd39gpassword123" hoặc bất kỳ nội dung nào trước khi băm. ngăn chặn các cuộc tấn công bảng cầu vồng, nhưng sự hiểu biết của tôi từ this article là nó không tốt bằng một muối duy nhất cho mỗi mật khẩu. Sau đó, một lần nữa, this article và this paper nói rằng bcrypt có muối được tích hợp sẵn. , và có bất kỳ nhu cầu, cũng có một cột muối?
• Trải dài. "đối với bcrypt, đây là chi phí cho băm mật khẩu và mặc định là 10." Dựa trên this question, tôi nghĩ đến việc sử dụng hệ số công việc là 12. Điều đó có vẻ hợp lý không?
• Độ dài mật khẩu. Một mật khẩu dài hơn có vẻ an toàn hơn nói chung, nhưng tôi không muốn nó quá khó để người dùng viết nó lên một mảnh giấy ở đâu đó. Độ dài mật khẩu có quan trọng không nếu chúng ta sử dụng bcrypt?
• Cookie SSL. Đối với các ứng dụng công khai đã bật SSL, đánh dấu cookie là "điều này chỉ có thể được truyền qua HTTPS" bảo vệ chống lại các cuộc tấn công kiểu Firesheep. Nhưng tôi không chắc chắn nó có ý nghĩa như thế nào khi có chứng chỉ bảo mật cho một ứng dụng nội bộ. Đó là ngớ ngẩn?

Tôi còn thiếu gì nữa?

Answer 1

Ớt: có bạn là chính xác. Không có nhiều bảo mật bổ sung đạt được với hạt tiêu nếu bạn đang sử dụng muối.

Kéo dài: 12 là hợp lý, tuy nhiên bcrypt chỉ đảm bảo thời gian không đổi. Bạn nên cân nhắc sử dụng scrypt mới hơn vì nó cho phép bạn chỉ định cả thời gian cố định và dung lượng bộ nhớ cần sử dụng. Cryptyograhpically bcrypt và scrypt là về cùng một nhưng scrypt làm cho brute buộc khó hơn.

Chiều dài mật khẩu: buộc bất kỳ loại quy tắc mật khẩu nào làm giảm entropy mật khẩu. Hạn chế duy nhất nên có độ dài tối thiểu và nhiều nghiên cứu đã đề xuất ít nhất 8 ký tự.

Cookie SSL: sử dụng chúng nếu bạn có thể. Bảo mật luôn được xây dựng ngay từ đầu và không được thêm vào sau. Bạn không bao giờ có thể chắc chắn ai có thể đánh lừa bạn mạng nội bộ. Chỉ vì bạn cho rằng không có người ngoài nào có thể đánh cắp dữ liệu, không có nghĩa là nhân viên bên trong sẽ không vì lý do này hay lý do khác. Bạn có trách nhiệm bảo vệ nhân viên của bạn khỏi nhau cũng như các mối đe dọa từ bên ngoài.

Answer 2

Đối với mật khẩu, bạn có thể thanh toán https://github.com/bitzesty/devise_zxcvbn từ chối mật khẩu với entropy yếu và kiểm tra đối với các mật khẩu đã bị nứt đã biết.