¿Tiene sentido la seguridad de la contraseña hash en el extremo del cliente

Question

Si tuviera que hash la contraseña de un usuario antes de enviarla a través de la línea y dejarla en texto sin formato en la memoria, mejoraría la seguridad de la aplicación?

Supongo que esto mitiga una pequeña fracción de las vulnerabilidades al proteger los datos almacenados en la memoria del cliente. Pero realmente si nos preocupa que alguien lea la memoria del cliente, probablemente haya problemas mayores que no podamos resolver.

Hay algo que no se siente bien acerca de hashing en el extremo del cliente.

¿La práctica de hash de la contraseña en el cliente es una práctica común? ¿Hay otras ventajas o desventajas para hacerlo?

EDITAR: Dado que el canal de comunicación es seguro (SSL). ¿Bajo qué condiciones sería aceptable y valioso usar dicho enfoque? Pregunto esto porque un "profesional de la seguridad" me sugirió que utilicé dicho esquema durante algunas funciones de la aplicación.

Answer 1

Nº

Cuando el cliente envía algo, si es P o H(P)H(H(P)) o cualquier persona que intercepta esto puede simplemente volver a enviar exactamente lo mismo que, con lo que cualquier función como esto equivale a utilizar la contraseña directamente

Es por eso que debe usar un nonce; El servidor puede dar salida aleatoria a k y el cliente calculará H(P,k) y lo enviará al servidor. HMAC es una implementación popular de este método.

Siempre que el servidor nunca acepte el mismo nonce dos veces, esto es seguro contra un ataque de repetición.

Answer 2

Solo asegúrese de estar enviando su contraseña a través de un canal seguro (SSL). Si el cliente puede tener una aplicación de lectura de memoria privada, es muy probable que tenga problemas mayores, como por ejemplo un registrador de teclas.

Answer 3

El hash es idéntico a la contraseña de un POV de seguridad en el escenario que describe: si intercepto el hash, no necesito saber la contraseña, puedo enviar el hash al servidor que he interceptado.

Authentication protocols ir a cierta longitud para evitar este problema; la seguridad es difícil, y es mejor que selecciones e implementes un protocolo bien entendido en lugar de desarrollar el tuyo propio.

Si su tráfico pasa por SSL, está a salvo de la interceptación y el uso de hash le ofrece poco beneficio adicional.

Answer 4

El envío de una contraseña hash no mejorará la seguridad de su sitio, como otros han señalado (ya que acepta una contraseña hash, todo lo malo que necesita saber es la versión hash). Tampoco es realmente seguro, ya que es probable que el tipo malo cargue su página de inicio de sesión y examine el Javascript o Java desplegado.

Lo que hace es evitar que alguien que mira los paquetes pueda sacar una contraseña, y que es moderadamente útil. Muchas personas usan la misma contraseña en varios sitios (lo hago para todos menos para los sitios de mayor seguridad) y, por lo tanto, si puede obtener una contraseña de ellos, puede iniciar sesión en otras cuentas en otros sitios.

También evita que la contraseña real se almacene, incluso temporalmente, en su sitio, y eso puede proporcionar un poco más de seguridad si su sitio se ve comprometido.

Así que, si bien consideraría que el hash del lado del usuario podría ser algo bueno, no vale la pena tener demasiados problemas.

Y, como han dicho otros, no transfiera su propia seguridad. Hay demasiadas cosas que pueden salir mal. No los notarás casi tan rápido como lo hará un chico malo practicado.

Answer 5

Estará mucho mejor si usó el Secure Remote Password protocol (SRP). Fue diseñado para esto.

Answer 6

No, hash en el cliente no protege la contraseña 'completamente'. Cuando uno opta por cifrar la contraseña en el cliente, el resumen enviado al servidor, básicamente se convierte en la contraseña. Esto no es un problema en sí mismo si se implementa SSL.

Sin embargo, este esquema termina creando más problemas de los que resuelve. Si el servidor comparase el hash enviado por el cliente con un hash almacenado en la base de datos sin realizar ninguna otra operación criptográfica (especialmente hash de los datos de entrada), entonces la contraseña se almacena en texto claro para todos los propósitos prácticos. Cualquier persona con acceso al hash almacenado puede volver a enviarlo al servidor y obtener acceso a las cuentas.

En términos simples, si el hash enviado (que es lo mismo que el hash enviado) se filtró a través de cualquier otra vulnerabilidad dentro de la aplicación (mediante inyección SQL, por ejemplo) entonces la aplicación tiene una vulnerabilidad donde protege las contraseñas inadecuadamente

Si la vulnerabilidad subyacente debe ser reparada, entonces es necesario tratar el hash presentado como una contraseña en texto claro, que luego debe ser hash (preferiblemente con una sal) antes de la comparación con un hash almacenado.

Answer 7

Hashing en el lado del cliente abre otro gran agujero: puede exponer el algoritmo de hash. No dice si esto está basado en la web (cliente = JavaScript) o cliente grueso, pero les está dando más información. Dado que el canal es seguro, no tiene que preocuparse por la contraseña de texto claro que se olfatea.

Además, si su algoritmo hash requiere una sal, estaría exponiendo su sal, lo que significa que si alguna vez tienen acceso a la base de datos, podrían descifrar cada contraseña.

Answer 8

Sí, deberías.

IEEE tuvo una violación de datos en la que se expusieron 100K correos electrónicos y contraseñas de un weblog.

http://ieeelog.com/

Obviamente, IEEE no debería haber expuesto su blog! Pero si hubieran cifrado las contraseñas en el lado del cliente, esto no habría sido tan malo.

Como dice la primera respuesta, debería usar un nonce. Si usa un tiempo de espera suficientemente largo (por ejemplo, 128 bits), no necesita preocuparse por la reutilización, ya que el servidor nunca pedirá el mismo nonce dos veces (suponiendo que el CRNG se siembra correctamente, etc.).

Answer 9

Creo que tiene sentido en una circunstancia; no quiere ni siquiera saber la contraseña de texto sin formato del cliente. Si hash en el lado del cliente, sal y iterativamente hash ese hash de la misma manera que lo haría con un texto sin formato pw. Aparte de eso, es un poco tonto.

Answer 10

Te puedo dar diferentes tipos de enfoque Si tiene no SSL puede hash de la contraseña en el lado del cliente y de nuevo hash en el lado del servidor con cualquier otro método de hash y almacenarlos en la base de datos y cuando la conexión del usuario con la contraseña haga el mismo proceso y haga coincidir la contraseña doble hash con hashes almacenados