Hash, sal y mejores prácticas [duplicar]

4

Leyendo sobre el hashing, la sal y la pimienta, no puedo entender el siguiente escenario:

Si hay una aplicación web y te registras en ese sitio, ¿la contraseña debe estar oculta en el cliente o en el servidor? Si consideras el hash en el lado del cliente, también tienes que generar un salt individual que luego se adjunta a tu contraseña y esa combinación se hash y luego se envía al servidor junto con el salt o También puede hacer un hash de la contraseña, enviarlo al servidor y la sal se agrega al hash por el servidor, que luego vuelve a ser hash. Pero si un atacante puede interceptar la conexión entre el cliente y el servidor durante el inicio de sesión, no está interesado en la sal, porque el cliente simplemente envía la contraseña de hash (o texto sin cifrar) al servidor ... Y si el atacante puede romper en la base de datos, todavía puede hacer fuerza bruta el hash. Por lo que sé, las sales solo son útiles contra los ataques de RainbowTable (?)

¿Cuál es la mejor práctica entonces? ¿Quién debe escribir la contraseña y dónde se debe agregar el salt?

    
pregunta N. Groß 23.10.2017 - 18:40
fuente

1 respuesta

2

En general, las sales y los hashes se realizan en el lado del servidor, no del lado del cliente. La comunicación entre el servidor y el cliente debe estar protegida con cifrado (TLS). Como lo menciona Anders en un comentario, esto puede responder muchas de sus preguntas: Para una aplicación web HTTPS, ¿vale la pena cifrar la contraseña antes de enviarla por POST, para evitar que un atacante MITM la capture?

Sobre las sales y el hash en general: la idea detrás de las sales y los hashes a menudo se reduce a obligar al atacante a realizar un algoritmo de fuerza bruta. Este (a) compra el tiempo de servicio para proteger la red y cambiar las contraseñas de los usuarios, y (b) evita que los actores malos dentro de la empresa / sitio web adquieran la contraseña del usuario (para cosas malas como probar esa contraseña en otros sitios).

Las sales hacen muchas cosas. (1) protege contra ataques de la tabla del arco iris, como usted dijo, (2) en el caso de violación de datos, hace que el craqueo de contraseñas sea más difícil que el hash de vainilla (es decir, no hay forma de que un atacante pueda construir una base de datos de todos los hashes para un algoritmo; tendrían que tener esa base de datos para cada hash, lo cual no es factible); esto le da tiempo al sitio / a los usuarios para cambiar el algoritmo y las contraseñas, (3) evita que las personas que trabajan en el sitio puedan robar fácilmente la contraseña de un usuario y (4) otorga más opciones de arquitectura para asegurar el proceso de autenticación.

Para hablar de (4) por un minuto, un cliente mío (internacional muy grande) tenía una arquitectura de microservicio, y sus procesos de autenticación funcionaron al mezclar la contraseña con una de las muchas sales (basadas en el nombre de usuario) antes enviándolo al microservicio que verificó la base de datos real. Este tipo de separación impidió que el código que maneja la base de datos conozca tanto el salt como la contraseña, y el microservicio que sabía que el salt no mantendría los hashes (ni en la memoria ni en el disco). Un atacante no pudo usar un volcado de base de datos; necesitarían software de base de datos y de más de un servidor . Esto aumenta la complejidad, ya que una base de datos robada no los acerca al hash de la base de datos; también necesitarían la lista de sales (de otro servidor). Ningún empleado tuvo acceso a ambos servidores, lo que ayudó con (3).

Por qué el hashing del lado del cliente no es super útil : Un hombre en el ataque central puede capturar lo que se transmite entre el cliente y el servidor. Hashear la contraseña antes de enviar hace muy poco; el atacante no tiene que ser capaz de generar el hash, solo tendría que enviar la misma solicitud de nuevo para obtener acceso.

Por ejemplo, veamos las siguientes solicitudes y parámetros (no estoy usando encabezados HTTP reales para facilitar la lectura):

POST /auth/login
[email protected]
pass=mypassword

versus:

POST /auth/login
[email protected]
pass=89e01536ac207279409d4de1e5253e01f4a1769e696db0d6062ca9b8f56767c8

El servidor no puede saber por el hash que la contraseña real es "mypassword", por lo que solo usará el hash como está para verificar la cuenta del usuario. Un atacante que puede leer esa solicitud no necesita saber que su contraseña es "mypassword", solo necesita tomar el hash; Eso no da ninguna protección para la cuenta. Lo único que esto impide es que el atacante pueda probar la contraseña en otros sitios (por ejemplo, muchas personas usan tontamente el mismo correo electrónico y contraseña para google y su banco).

    
respondido por el cegfault 23.10.2017 - 19:46
fuente

Lea otras preguntas en las etiquetas