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

Question

Estoy a punto de comenzar a configurar una aplicación de 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 duraran hacer lo siguiente:

• cuentas de bloqueo después de un pequeño número de intentos de acceso fallidos
• Uso config.paranoid lo que un atacante no puede decir si han adivinado una válida dirección de correo electrónico
• ¿Tal vez desactivar la contraseña restablece por correo electrónico?

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

• Peppers. 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 "contraseña123" en algo como "contraseña123K # (! @ Akdlwekdf" o "*%! Kd39gpassword123" o lo que sea antes del hash. frustrar ataques de tabla arcoiris, pero mi entendimiento del this article es que no es tan bueno como una sal única por contraseña. Por otra parte, this article y this paper dicen que bcrypt tiene sales incorporadas. ¿Usar algo con pimienta con brypt realmente agrega algo? y ¿hay alguna necesidad de hacerlo, también tienen una columna de sal?
• Estiramientos. "para bcrypt, este es el costo para el hash de la contraseña y por defecto a 10." sobre la base dethis question, estoy pensando utilizando 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 de 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 hace falta?

Answer 1

Pimientos: si usted es correcto. No hay mucha seguridad adicional con un pimiento si está usando sal.

Estiramientos: 12 es razonable, sin embargo, bcrypt solo garantiza 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.

SSL Cookies: ú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.

Answer 2

Para las contraseñas, puede realizar el pago https://github.com/bitzesty/devise_zxcvbn que rechaza contraseñas con entropía débil y verificaciones contra contraseñas crackeadas conocidas.