seguridad https: ¿la contraseña debe estar oculta en el lado del servidor o del lado del cliente?

Si hash en el lado del cliente, la contraseña con hash se convierte en la contraseña real (con el algoritmo de hash no es más que un medio para convertir un mnemónico de usuario a la contraseña real). / p>

Esto significa que almacenará la contraseña completa "texto sin formato" (el hash) en la base de datos, y habrá perdido todo el beneficio del hashing en primer lugar.

Si decides ir por esta ruta, también deberías renunciar a cualquier hash y simplemente transmitir y almacenar la contraseña sin formato del usuario (que, por cierto, no recomendaría especialmente).

El hash en el cliente solo tiene sentido si no confía en el servidor de alguna manera y no quiere mostrarle la contraseña "real" (la que recuerda el usuario humano). ¿Por qué no querría mostrar la contraseña al sitio en el que dicha contraseña tiene algún uso? Debido a que ha reutilizado la contraseña en otro lugar! Ahora, por lo general, es mala, pero existe una versión relativamente segura que se encarna en innumerables extensiones de navegador o marcadores como esta o esa (no 'No responda por su calidad). Estas son herramientas donde el usuario humano recuerda una "contraseña maestra", a partir de la cual se genera una contraseña específica del sitio, utilizando el nombre de dominio del sitio como una especie de sal, para que dos sitios distintos obtengan contraseñas distintas.

Si bien este escenario tiene sentido, hacerlo con Javascript enviado por el propio servidor no lo hace. De hecho, el punto del hashing del lado del cliente de contraseña es que el servidor es potencialmente hostil (por ejemplo, subvertido por un atacante) y, por lo tanto, el código de Javascript enviado por ese servidor es, como mínimo, sospechoso. No desea ingresar su contraseña valiosa en un Javascript hostil ...

Otro caso para el hashing del lado del cliente es sobre hashing lento . Dado que las contraseñas son, por definición, débiles, usted quiere frustrar los ataques de diccionario . Usted asume que el malvado obtuvo una copia de la base de datos del servidor y "intentará las contraseñas" en sus propias máquinas (consulte esta entrada de blog para una discusión sobre esto). Para ralentizar al adversario, emplea un proceso de hashing inherentemente lento (como bcrypt ), pero esto hará que el procesamiento sea lento para todos, incluido el servidor. Para ayudar al servidor, es posible que desee descargar parte del trabajo en el cliente, por lo tanto, realice al menos parte de él en algún código Javascript que se ejecute en el navegador del cliente ...

Desafortunadamente, Javascript es muy lento en este tipo de trabajo (generalmente de 20 a 100 veces más lento que el código C decente), y el sistema cliente no podrá contribuir una parte sustancial al esfuerzo de hashing. La idea es sólida pero tendrá que esperar por una mejor tecnología (habría funcionado con un cliente Java , sin embargo: con una JVM decente, el código Java optimizado es de 2 a 4 veces más lento que el código C optimizado , para un trabajo de hashing).

Para resumir, no hay un caso realmente bueno para realizar el hashing de contraseñas del lado del cliente, a partir del código Javascript enviado por el propio servidor. Simplemente envíe la contraseña "tal como está" al servidor a través de un túnel HTTPS (la página de inicio de sesión, la URL de destino del formulario y cualquier página que esté protegida por la contraseña, todas se entregarán a través de SSL; de lo contrario, tienen más problemas de seguridad que el uso de contraseñas).

Me parecen acertadas todas sus inquietudes, pero mi recomendación sería hacerlo desde el lado del servidor.

Siempre hay una posibilidad bastante grande de que un usuario deje su terminal desbloqueada, lo que permite la manipulación. Y también; si tu lógica de hash es del lado del cliente, la estás exponiendo.

Otra opción sería generar las contraseñas del lado del servidor; entonces no estás enviando una contraseña de texto simple. Pero todavía necesitarías comunicar la contraseña al usuario. Y dado que la mayoría de los usuarios aún no utilizan el correo electrónico cifrado, considero que es menos seguro.

He visto soluciones para enviar contraseñas a través de un túnel cifrado a un teléfono celular; Pero dudo que la seguridad sea mejor que la SSL. Quizás alguien podría probar / refutar esto?

Hashing del lado del servidor es importante como lo han indicado todas las demás respuestas, pero me gustaría agregar que el hashing del lado del cliente sería una buena característica de seguridad además de al hashing del lado del servidor.

El hashing del lado del cliente tiene ventajas en los siguientes escenarios:

1. Protege la contraseña del usuario cuando el servidor está comprometido. Es decir. si el cliente no está comprometido, pero el servidor sí lo está, si el cliente utiliza la contraseña, el servidor podría obtener acceso al sistema único, pero usted ha protegido la contraseña del usuario, lo cual es importante si usan esa contraseña en otro lugar.
2. Protege la contraseña del usuario cuando el usuario cree que está iniciando sesión en un servidor pero realmente está iniciando sesión en otro (error de usuario). Por ejemplo, si tengo dos cuentas bancarias, y accidentalmente escribo una de las contraseñas de mi banco en el sitio web del banco equivocado, si el banco introdujo la contraseña del lado del cliente, ese banco no sabría la contraseña de mi otro banco. Creo que sería una cosa "educada" hacer el hash del lado del cliente para que su contraseña de texto simple nunca se transmita por el cable.

Sobre todo muestra respeto por la contraseña del usuario. El usuario está compartiendo un secreto que puede no ser exclusivo de su software, por lo que si respeta ese secreto, debe hacer todo lo que esté a su alcance para protegerlo.

Si estás en un túnel HTTPS, la contraseña o el hash deben estar protegidos de la vigilancia de Ethernet.

En el lado del cliente, tal vez podría agregar el hash a un ID de sesión.
Esto podría ser más difícil de simular con Javascript malicioso.

La respuesta aceptada de @Nicole Calinoiu es, por supuesto, correcta pero quizás difícil de entender al principio.

El punto es que la contraseña debe estar oculta en el servidor para que la persona maliciosa no pueda usar los hashes que ha pirateado de la base de datos del servidor para obtener acceso a su cuenta o datos.

Como ya se dijo, si hash en el lado del cliente y el back-end lo admite, entonces el hash se convierte en tu contraseña y si el hash es robado a través de un hack, entonces el hacker tiene la contraseña.

@Thomas Pornin también ha llegado a un muy buen punto por qué usted querría utilizar la contraseña en el cliente, pero lo que describe en su primera historia solo se puede hacer si el servidor del servidor no admite el manejo de contraseñas con hash (es decir, no hash la contraseña si ya está hash, pero que alguien intente apoyar algo así es altamente improbable), lo que la mayoría de las veces no será el caso, supongo. La segunda historia de él es muy buena.

Hashing la contraseña del lado del cliente requerirá Javascript. Algunas personas deshabilitan Javascript en su navegador. Tienes que manejar este escenario.

He visto el software del foro que realiza el hash de contraseña del lado del cliente y lo envía al iniciar sesión si es posible , de lo contrario, la contraseña se envía en texto sin formato. Así que funciona en cualquier situación.

Enviar la contraseña en claro no es una preocupación importante si va a utilizar https. Idealmente, su servidor debería entonces rehusarse a servir páginas en http para evitar el ataque en el medio. El razonamiento es: un atacante podría "degradar" forzosamente su conexión de https a http y comenzar a rastrear el tráfico (por ejemplo, con una herramienta como SSL Strip).

Si su servidor va a tener varios administradores posibles y no necesariamente puede confiar en que todos ellos no obtendrán volcados de memoria, realmente debería controlar el lado del cliente para proteger a los administradores del robo de contraseñas de usuarios [que pueden ser reutilizados en otros sitios web] -a pesar de que se trata de una mala práctica, los usuarios lo hacen y continuarán haciéndolo], y luego hash ese lado del servidor hash para que el robo de la tabla no le dé automáticamente a los atacantes la llamada contraseña de texto simple para el propio sitio web.

Y mientras esté usando la función hash segura, puede usar la misma sal para ambos lados.

Para todos los intentos, solo querrá hacer hash en el lado del cliente. La idea detrás de un hash es evitar que nadie, excepto el usuario, sepa la contraseña. Como cualquier buen sitio debería usar TLS, el hecho de que el hash se envíe al servidor es irrelevante (tenga en cuenta que incluso si esto fuera un problema, el envío de la contraseña de texto simple sería igual de malo).

Finalmente, las respuestas enumeradas parecen no darse cuenta de que, si alguna vez se compromete el servidor, cada persona en la contraseña del servidor se verá comprometida ya que las contraseñas se le enviarán en texto sin formato.