Hashing credenciales. ¿Es suficientemente seguro el hash (correo electrónico + contraseña)?

Obligatorio: no lances tu propio criptográfico ...

Según sus comentarios, no está preguntando por ningún algoritmo específico, pero si cambiar la entrada de hash de password a email+password proporciona seguridad adicional.

Correo electrónico dado: [email protected] con contraseña My @wesome pa$$w0rd FTW YO!!!!

• Por lo tanto, su entrada en el algoritmo hash ahora es más larga y es menos probable que esté en una tabla de arco iris y tomará más tiempo para obtener el texto completo completo
• Como anotó en un comentario, podría usar el correo electrónico como un salt, pero probablemente sea mejor usar un valor aleatorio y aquí
• Dependiendo de algunos detalles de la implementación, la dirección de correo electrónico aún podría estar expuesta; Si no necesita la dirección de correo electrónico y nunca usará el valor en ningún otro lugar, ¿por qué necesita una dirección de correo electrónico en lugar de solo un nombre de usuario? También puede tener problemas con restablecimientos de contraseñas o administración de usuarios.

  

Haga que la autenticación del cliente del servidor sea más eficiente.

¿Por qué es esto más eficiente? Una implementación de Javascript en el navegador podría ser bastante lenta y estar sujeta a un compromiso, ya que tiene el mismo nivel de seguridad en el navegador del usuario (que no está bajo su control) que en su servidor. Desea que su hash sea lento en general, no rápido cuando se trata de contraseñas.

También, para esta última parte:

  

Almacene el mismo hash en el servidor y en el cliente (solo calcule el hash una vez en cada lado)

¿Parece que desea reducir la carga del servidor calculando el hash en el cliente y enviándolo al servidor? Entonces, en su base de datos, ¿busca ese valor con el valor en la base de datos? Es posible que esto no esté haciendo lo que piensa, dependiendo de la implementación, por ejemplo, enviar el hash a través de la red para compararlo con el valor en la base de datos; si el DB está comprometido, el atacante tiene el valor de entrada, por lo que es lo mismo que hacer un texto sin formato. Desea evitar que alguien que obtiene la base de datos pueda iniciar sesión a través del canal legítimo. Consulte " Desafío desafiante: cliente- hash de contraseña lateral y verificación de contraseña del servidor "

La implementación donde se usa el correo electrónico como sal no es buena. Una sal es preferentemente criptográficamente generada al azar. Esto asegura que la sal sea única a nivel mundial. Esto significa que si tiene una persona que usa la misma contraseña en dos aplicaciones diferentes, ambas contraseñas se verán diferentes. Con su esquema en el que utiliza la dirección de correo electrónico como sal, la contraseña de hash entre dos aplicaciones será la misma.

Además, creo que debería leer sobre el hash de contraseñas y qué algoritmos son aceptables. Actualmente puedes usar:

• scrypt
• bcrypt
• pbkdf2

Cualquiera de estos es bueno y la mayoría de las bibliotecas realmente generarán la sal correctamente para ti.

No utilice un hash md5 / sha / smth para almacenar contraseñas, con sal o de otra manera. Los hashes genéricos están diseñados para ser rápidos: puedo en un 20%, md5 un archivo de 9 Gb en mi computadora portátil. No desea que los hashes de su contraseña sean rápidos para su cálculo.

Utilice algo que realmente está destinado a hacer hash de forma segura las contraseñas - ¿Algún experto en seguridad recomienda bcrypt para el almacenamiento de contraseñas?

Si su único objetivo es hacer que las cosas sean rápidas y sencillas, también puede almacenar la contraseña como texto sin formato; sha1(email + password) se puede romper muy rápidamente en el hardware de hoy en día, por lo que casi no vale la pena el "problema".