tutorial rails has_secure_password authenticate ruby-on-rails-3 security encryption devise bcrypt

ruby-on-rails-3 - has_secure_password - bcrypt rails 4



¿Cuál es la configuración de diseño más segura posible? (2)

Estoy a punto de comenzar a configurar una aplicación Rails solo para empleados en nuestra empresa para trabajar con información confidencial. Habrá un firewall, medidas físicas de seguridad, etc. Mi preocupación ahora es el proceso de inicio de sesión para la aplicación.

Me gustaría utilizar Devise para la autenticación. ¿Cuál es la configuración más segura posible para Devise?

Estoy pensando que haré lo siguiente:

  • Bloquear cuentas después de un pequeño número de intentos de inicio de sesión fallidos
  • Use config.paranoid para que un atacante no sepa si ha adivinado una dirección de correo electrónico válida.
  • Tal vez desactivar restablecimientos de contraseña por correo electrónico?

Algunas de las cosas específicas de las que no estoy seguro, con citas de devise.rb en cursiva:

  • Pimientos. Devise tiene una opción para "Configurar un pimiento para generar la contraseña encriptada". Según tengo entendido, este es un valor único específico de la aplicación que transforma una contraseña estúpida como "password123" en algo como "password123K # (! @ Akdlwekdf" o "*%! Kd39gpassword123" o lo que sea antes del hash. Rainbow Table Attacks, pero mi comprensión de este artículo es que no es tan bueno como una sal única por contraseña. Por otra parte, este artículo y este documento dicen que bcrypt tiene sales incorporadas. ¿El uso de un pimiento con brypt realmente agrega algo? ¿Puedo, y hay alguna necesidad, también tener una columna de sal?
  • Estira . "Para bcrypt, este es el costo de hash la contraseña y el valor predeterminado es 10." Basado en esta pregunta , estoy pensando en usar un factor de trabajo de 12. ¿Eso parece razonable?
  • Longitud de la contraseña Una contraseña más larga parece más segura en general, pero no quiero que sea tan difícil que el usuario la escriba en un papel en alguna parte. ¿Importa la longitud de la contraseña mucho si usamos bcrypt?
  • Cookies SSL Para las aplicaciones públicas con SSL habilitado, marcar las cookies como "esto solo se puede transmitir a través de HTTPS" protege contra los ataques al estilo Firesheep . Pero no estoy seguro de lo mucho que tiene sentido tener un certificado de seguridad para una aplicación interna. ¿Eso es tonto?

¿Qué más me estoy perdiendo?

Pimientos : sí, estás en lo cierto. No hay mucha seguridad adicional con un pimiento si está usando sal.

Estira : 12 es razonable, sin embargo, bcrypt solo asegura un tiempo constante. Debería considerar usar el nuevo scrypt, ya que le permite especificar tanto un tiempo constante como la cantidad de memoria que debe usar. La criptación criptográfica y la criptografía son más o menos las mismas, pero el scrypt hace que la fuerza bruta sea más difícil.

Longitud de la contraseña : forzar cualquier tipo de reglas de contraseña reduce la entropía de las contraseñas. La única restricción debe ser una longitud mínima y numerosos estudios han sugerido al menos 8 caracteres.

Cookies SSL : úsalas si puedes. La seguridad siempre debe construirse desde el principio y no agregarse más tarde. Nunca puede estar seguro de quién podría estar olfateando su red interna. El hecho de que usted suponga que ningún extraño puede oler datos, no significa que los empleados no lo hagan por una razón u otra. Usted tiene la responsabilidad de proteger a sus empleados entre sí, así como a las amenazas externas.