¿Cuál es la mejor forma de cifrar la contraseña del usuario en el navegador del cliente antes de enviarla al servidor web, de modo que solo se elimine el hash, no la contraseña de texto sin formato?Hash de contraseñas en el navegador del cliente
EDITAR: suponiendo que se utiliza HTTP (no HTTPS)
uso javascript para calcular el hash. Consulte this para ver un ejemplo sobre cómo calcular los hashes SHA-1 en JS.
Tenga en cuenta que si se hace dependiente de Javascript, su sistema fallará tan pronto como alguien tenga JS deshabilitado. Debe usar HTTPS si esto le preocupa, que tiene sus propios contratiempos (por ejemplo, los certificados cuestan dinero si quiere que los navegadores los acepten inmediatamente).
No todas las personas tienen JavaScript habilitado en sus navegadores e incluso idea de enviar hashes en un canal de texto sin formato, creo que no es lo suficientemente seguro.
Yo recomendaría que considere una conexión segura SSL.
Intente utilizar este jQuery encryption plugin. Por curiosidad, ¿qué hay de malo con el uso de SSL/HTTPS y el cifrado en el lado del servidor?
Supongo que trabajo en HTTP simple – Andy
Este sitio tiene bastante amplia cosas hash/cripto: JavaScript Encryption Library
cifrado de JavaScript del lado como la biblioteca jQuery cifrado detiene fisgones. Sin embargo, aún puede ocurrir MITM (Man-in-the-Middle). SSL/TLS es la última opción que se recomienda tomar a menos que esté en alojamiento compartido (sin direcciones IP dedicado) o su sitio está recibiendo tanto tráfico que no se puede simplemente cifrar todas las conexiones (JS, CSS, HTML, .. .).
¿para qué molestarse haciendo esto? Efectivamente, el hash de la contraseña se ha convertido en la contraseña y un hombre en el medio que intercepta el hash puede usarlo para autenticarse y realizar cualquier acción como usuario. Por otro lado, si no crees en el man-in-the-middle, ¿por qué no solo enviar la contraseña?
Challenge-Response protege contra Eavesdropping, donde no se puede alterar ningún dato, solo escucharlo. Como los tokens son de una sola vez, los espías siempre llegarán tarde y no aprovecharán el token. – Tower
Sí, eso es cierto, supongo que detendría a un atacante que solo escuchara a escondidas descubrir la contraseña. Pero en ese caso, solo usaría autenticación HTTP Digest en lugar de hacer mi propia cuenta. – erickson
¿Por qué nos hash contraseñas? De modo que si se obtienen los hashes, son difíciles de usar.
¿Qué sucede en este modelo si los valores hash en el sistema están expuestos? El atacante simplemente los envía al servidor y se autentica como el usuario.
¡Esta es la razón por la que el hashing de contraseñas siempre ocurre en el servidor, no en el cliente!
espero que usted está planeando enviar el hash de más de un canal seguro, o esto es parte de un mecanismo de desafío/respuesta. De lo contrario, esto no es más seguro que enviar la propia contraseña en texto plano ... –
@Roger Lipscombe, este método puede ser en realidad una ligera mejora para el usuario. Incluso si no hay un canal seguro disponible (solo SSL funcionaría, ninguna alternativa de JS sería a prueba de balas), al menos haría que el hash fuera exclusivo del sitio. Para hacer el hash único, por supuesto, * tiene que ser salado *. – Inshallah
Concedió que haría que el hash fuera exclusivo del sitio; es útil si el usuario usa la misma contraseña en varios sitios; no impide la reproducción contra el mismo sitio. Y, seguramente, si el hash es salado, entonces la sal debe ir del cliente al servidor, no más segura que antes; o de otra manera, en cuyo caso es un desafío/respuesta. –