security - cifrado - encriptar password php
¿Tiene sentido de seguridad el hash de contraseña en el cliente? (10)
Creo que tiene sentido en una circunstancia; ni siquiera quieres saber la contraseña de texto simple del cliente. Si hash en el lado del cliente, sal y hash iterativamente que hash de la misma manera que lo haría un pw de texto plano. Aparte de eso, es un poco tonto.
Si tuviera que marcar una contraseña de usuario antes de enviarla a través de la línea y dejarla en texto sin formato en la memoria, ¿mejoraría esto 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 de los clientes. Pero en realidad, si nos preocupa que alguien lea la memoria del cliente, es probable que haya problemas mayores que no podamos resolver.
Hay algo que no se siente bien sobre el hash en el extremo del cliente.
¿Es el hash de contraseña en el extremo del cliente una práctica común? ¿Existen otras ventajas o desventajas al hacerlo?
EDITAR: Dado que el canal de comunicación es seguro (SSL). Bajo qué condiciones sería aceptable y valioso utilizar este enfoque. Lo pregunto porque un "profesional de seguridad" me sugirió que usara ese esquema durante algunas funciones de la aplicación.
El envío de una contraseña con hash no mejorará la seguridad en su sitio, como han señalado otros (ya que acepta una contraseña con hash, todo lo que debe saber el mal es la versión con hash). Tampoco es realmente seguro, ya que el malo puede presumiblemente cargar su página de inicio de sesión y examinar el Javascript o Java implementado.
Lo que hace es evitar que alguien que mira los paquetes pueda extraer una contraseña, y eso es moderadamente útil. Muchas personas usan la misma contraseña en varios sitios (yo lo hago para todos, excepto 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 de seguridad adicional si su sitio está comprometido.
Por lo tanto, aunque considero que el hash del lado del usuario es potencialmente bueno, no vale la pena causarle muchos problemas.
Y, como otros te han dicho, no ruedes tu propia seguridad. Hay demasiadas cosas que pueden salir mal. No los notarás tan rápido como lo haría un tipo malo practicado.
El hash en el lado del cliente abre otro gran agujero: puede exponer el algoritmo de hash. No dices si esto está basado en la web (cliente = JavaScript) o cliente grueso, pero les estás dando más información. Dado que el canal es seguro, no tiene que preocuparse por el rastreo de la contraseña de texto simple.
Además, si su algoritmo de hash requiere un salt, estaría exponiendo su salt, lo que significa que si alguna vez tuvieran acceso a la base de datos, podrían descifrar todas las contraseñas.
El hash es idéntico a la contraseña de un punto de vista de seguridad en el escenario que describe: si intercepto el hash, no necesito saber la contraseña, solo puedo enviar al hash el servidor que intercepté.
Los protocolos de autenticación son demasiado largos para evitar este problema; la seguridad es difícil, y lo mejor es seleccionar e implementar un protocolo bien entendido en lugar de rodar el suyo.
Si su tráfico pasa por SSL, está seguro de la intercepción y el hash le brinda pocos beneficios adicionales.
Estaría mucho mejor si usara el protocolo de contraseña remota segura (SRP). Fue diseñado para esto.
No, el hashing en el cliente no protege la contraseña ''completamente''. Cuando uno opta por hacer un hash de la contraseña en el cliente, entonces el resumen enviado al servidor, esencialmente 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 comparara el hash enviado por el cliente con un hash almacenado en la base de datos sin realizar ninguna otra operación criptográfica (especialmente el hashing de los datos de entrada), la contraseña se almacena en texto sin cifrar 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 el mismo que el hash enviado) se filtrara a través de cualquier otra vulnerabilidad dentro de la aplicación (por ejemplo, mediante inyección de SQL), la aplicación tiene una vulnerabilidad en la que protege las contraseñas de manera inadecuada.
Si la vulnerabilidad subyacente debe solucionarse, entonces es necesario tratar el hash enviado como una contraseña en texto sin cifrar, que luego debe ser hash (preferiblemente con una sal) antes de la comparación con un hash almacenado.
No.
Cuando el cliente envía algo , ya sea P o H(P) o H(H(P)) cualquiera que intercepte esto puede simplemente reenviar exactamente lo mismo , haciendo que cualquier función como esta sea equivalente a usar la contraseña directamente.
Es por eso que debes usar un nonce ; El servidor puede dar algo de basura aleatorio 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.
Si deberías.
IEEE tuvo una brecha de datos en la cual 100K correos electrónicos y contraseñas fueron expuestos desde un weblog.
Obviamente, IEEE no debería haber expuesto su weblog! Pero si hubieran pirateado las contraseñas en el lado del cliente, esto no habría sido tan malo.
Como indica la primera respuesta, debe usar un nonce. Si usa un nonce lo suficientemente largo (por ejemplo, 128 bits), realmente no necesita preocuparse por la reutilización, ya que el servidor nunca pedirá el mismo nonce dos veces (suponiendo que haya CRNG correctamente sembrado, etc.).
Solo asegúrese de enviar su contraseña a través de un canal seguro (SSL). Si el cliente puede leer una memoria privada de la aplicación, lo más probable es que tengan problemas mayores, como por ejemplo un registrador de teclas.
Puedo darle un tipo de enfoque diferente Si no tiene SSL , puede usar la contraseña de hash en el lado del cliente y nuevamente en el lado del servidor con otro método de hash y almacenarlos en la base de datos, y cuando el usuario inicie sesión con la contraseña, realice el mismo proceso y haga doble clic. contraseña con hashes almacenados