¿El hashing de contraseña de BCrypt con el correo electrónico del usuario como sal?

Un bcrypt salt debe tener una longitud de 128 bits, por eso el uso de direcciones de correo electrónico no puede funcionar, ya que su longitud no es fija.

Además, las sales utilizadas para el hashing de contraseñas deben ser únicas . Una dirección de correo electrónico, incluso si está marcada como única en su base de datos, también podría usarse como una sal en otra base de datos en otro sitio web. Es por eso que debes generar uno al azar.

Debido a que las sales no son secretas, puede obtener la sal asociada con la dirección de correo electrónico con la que el usuario desea iniciar sesión (a través de AJAX), realizar el primer cálculo de bcrypt y enviar el resultado al servidor.

Pero eso no es una buena idea desde una perspectiva de seguridad. Consulte esta pregunta para comprender por qué el hashing de la contraseña del lado del cliente no es necesario.

Las sales deben ser globales únicas

Aunque es posible que esto no se aplique a su caso, existen buenas razones por las que las sales no pueden derivarse simplemente de un nombre de usuario u otra información constante sobre el usuario.

Considere a una usuaria Alice que usa la misma contraseña en varios sitios, los cuales usan su nombre de usuario como el salt. Esto llevará a que aparezca el mismo hash en ambos. El uso de una combinación del nombre de usuario y el sitio en sí para la sal debe abordar esa preocupación específica.

Formato de sal

Como han señalado otros, su sal está en el formato incorrecto. Puede realizar un hash de la dirección de correo electrónico y el nombre del sitio y luego truncar ese hash a 16 bytes.

El hash del lado del servidor todavía es necesario

Hay algunas cosas que el hashing del lado del cliente ofrece, pero nunca puede (bueno, casi nunca) ser un reemplazo para el hashing del lado del servidor. Y a menos que, junto con otras construcciones útiles, el hashing del lado del cliente realmente no ofrezca mucho. Sobre todo ayuda a ahorrar algo de trabajo al servidor.

La ventaja aparente más obvia del hashing del lado del cliente es que dificulta que el servicio aprenda la contraseña del usuario ya que la contraseña en sí no se envía. Pero esa ventaja solo funciona bajo un modelo de amenaza muy limitado. Necesita un atacante que pueda capturar el lado del servidor de contraseñas cuando se envía desde el cliente, pero no puede modificar el JavaScript en la página de inicio de sesión.

También hay una especie de pasar la hash aquí. El hash que el cliente envía es un secreto. Si es capturado (digamos en tránsito), puede ser utilizado por un atacante para iniciar sesión en el servicio tal como lo haría el conocimiento de la contraseña de origen. Entonces, solo porque el hash no parece un secreto (mientras que la contraseña de origen lo hace), es una prueba de autenticación.

No estoy diciendo que el hashing del lado del cliente no sea útil, pero es mucho menos útil de lo que la gente espera en la mayoría de las circunstancias.