2009-05-21 7 views
6

Por lo tanto, los hashes son útiles porque cambian las combinaciones de contraseña/nombre de usuario/valor de sal a un código que no se puede revertir. El cliente envía este hash al servidor. El servidor compara el hash con una lista de hashes almacenados para ver si se le puede otorgar acceso al usuario del cliente. Pero, ¿cómo evito que un usuario malintencionado intercepte la contraseña hash y escriba su propio cliente que envía este hash al servidor?Me falta algo sobre la utilidad de hash

Respuesta

10

Los hash son útiles si alguien obtiene una copia de seguridad de su base de datos o si obtiene acceso de solo lectura a la base de datos en vivo. No pueden resolver la contraseña y enviarla a su sistema en vivo. Es por eso que los salt, para que un hacker con acceso de solo lectura no pueda establecer su contraseña y luego verifique si alguien más tiene la misma contraseña.

Como ha señalado, no interrumpen la interceptación de solicitud (Man in the middle attacks) para detener la necesidad de utilizar conexiones seguras con el cifrado y la firma de paquetes. HTTPS & SSL son las formas más comunes de hacer esto.

+0

La respuesta de cartman fue la más directa, pero me ayudaste a entender el error en mi razonamiento. ¡Gracias! – Dabblernl

1

utiliza una conexión segura al servidor y envía su contraseña en texto plano sobre ella. el servidor lo mezcla y lo compara con el hash en el db. El punto de hashing es que si la contraseña del servidor db se ve comprometida, no se puede recuperar su contraseña.

1

Depende del método de interceptación.

Si la máquina del usuario está comprometida hasta el punto en que el software malicioso puede leer sus cookies, bueno, no hay mucho que pueda hacer.

Para detener la intercepción de la comunicación de red, asegúrese de utilizar SSL (es decir, HTTPS no HTTP). HTTP es probablemente más vulnerable en una red doméstica o de oficina, en particular una red inalámbrica poco segura. HTTPS le brindará cierta protección contra una red comprometida. Esto también incluye detectores de paquetes en redes locales.

La última opción a considerar son las computadoras utilizadas por varias personas. Los cibercafés son un ejemplo. Las PC de trabajo pueden ser otra. Puede establecer un tiempo de espera bajo para minimizar el riesgo de esto.

Una opción que algunos podrían argumentar es el filtrado de la dirección IP, lo que significa que invalida la sesión si recibe una solicitud desde una dirección IP diferente. Este es un enfoque crudo que probablemente cause más problemas de los que resuelve. Básicamente, hay muchos casos legítimos en los que cambiará la dirección IP de un usuario. Muchas redes corporativas funcionan de esta manera. El roaming inalámbrico, incluida la banda ancha móvil, con frecuencia cambiará la IP, particularmente cuando el usuario se está moviendo (por ejemplo, en un tren).

2

Sin hash no se utilizan de esa manera. El cliente primero envía la contraseña (sugiero que se use SSL), el servidor luego calcula el hash basado en esa contraseña con salt y lo compara con sus datos en el almacenamiento de contraseñas. De esta forma, no hay posibilidad de que usuarios incorrectos obtengan contraseñas.

4

En el caso de que la intercepción de hombre en el medio sea posible, una solución simple es un protocolo de desafío-respuesta.

La forma más simple es la siguiente: el usuario envía su nombre al servidor, el servidor selecciona un número aleatorio (desafío) y lo envía al cliente.El cliente combina la contraseña con el desafío de alguna manera predeterminada, evalúa el resultado y lo envía al servidor. El servidor hace lo mismo: combina y hash y comprueba si tiene el mismo resultado que el cliente enviado.

Cada vez que se selecciona una prueba diferente y, por lo tanto, el valor calculado será diferente incluso para la misma contraseña, por lo que reenviar el valor calculado más tarde no dará lugar a una autorización exitosa.

No es necesario almacenar la contraseña sin procesar en el servidor; podría almacenar el hash de contraseña solamente y el cliente también podría usar el hash y combinar ese hash con el desafío.

+0

¿No requiere eso que almacene la contraseña en su servidor? Esa no es una muy buena idea, ¿verdad? – sybreon

+0

No necesariamente, puede almacenar un hash de la contraseña solamente, y el cliente también usará el hash en lugar de la contraseña. El punto clave aquí es el desafío que cambia cada vez y se combina con la contraseña o el hash de la contraseña. – sharptooth

+0

Solo asegúrate de usar una fuente segura y aleatoria de aleatoriedad, de lo contrario, un hombre determinado en el medio podría deducir tu algoritmo de número aleatorio durante un período de desafíos de monitoreo y romper el sistema con solo un hash de contraseña y un número aleatorio :) – workmad3

1

En muchos sistemas, el valor que es hash no es estático, sino que usa un nonce cada vez que se solicita una acción que requiere autenticación. El servidor envía un valor único al cliente, que se combina con el secreto y el hash. Esto puede evitar la repetición de ataques de hombre en el medio.

Cuestiones relacionadas