¿Se necesita el cifrado de contraseñas para un sitio web HTTPS? [duplicar]

Es probable que el cifrado de la contraseña antes de enviarla a través de HTTPS no agregue más seguridad.

Considere: ¿cómo se encripta la contraseña con el remitente y cómo se descifra con el receptor?
Si utiliza un algoritmo simétrico, ¿cómo negociaron la clave? Si la clave está integrada en el cliente, cualquier persona que realice una ingeniería inversa tendrá acceso al cliente.
Si usa un algoritmo asimétrico (es decir, de clave pública), ya sea para cifrar la clave o para negociar una clave para un algoritmo simétrico ... simplemente está haciendo lo mismo que SSL / TLS está haciendo por usted.

Simplemente use la versión más alta disponible de TLS, con la clave más larga que tanto el servidor como los clientes tienen disponible.

Solo para completar: HTTPS usa SSL / TLS. Originalmente significaba "HTTP sobre SSL". Hoy en día, SSL se ha encontrado vulnerable, y debería usar su TLS sucesor.

En el servidor, hace un hash de (contraseña + valor de sal). Hay mucha información sobre cómo realizar una autenticación segura basada en la web en la Guía definitiva para la autenticación de sitios web basada en formularios .

La generalización de Frederics responde un poco, podría ser necesario cifrar la contraseña en el cliente si la solución no utiliza HTTPS de extremo a extremo en el flujo de datos de credenciales.

Algunas razones para no usar HTTPS de extremo a extremo son:

• El HTTPS termina en algún servidor perimetral, como un equilibrador de carga o un proxy inverso, con HTTP simple entre el servidor perimetral y el servidor de destino final (la situación de Frederics sería otro ejemplo de esto).
• Las solicitudes se mantienen en reposo en algún momento de su flujo, como en una cola de mensajes para nivelar la carga

En este caso, podría tener sentido utilizar el cifrado de nivel de mensaje como lo describe.

He visto solicitudes de este tipo de clientes a los que se les vendió el concepto de cifrado de extremo a extremo para las contraseñas.

La configuración es la siguiente: hay un servidor dedicado que valida las contraseñas y otras credenciales, y nada más. El servidor que aloja la aplicación delega la autenticación a ese servidor dedicado, pasando las credenciales cifradas.

El cifrado HTTPS se detiene en el servidor de la aplicación, pero las credenciales cifradas aún están protegidas hasta que llegan al servidor de autenticación.

Ahora no estoy seguro de que eso tenga mucho sentido, pero como dije, he conocido a clientes que solicitan tal cosa.

Por lo general, una arquitectura de software consta de un frontend, un middleware (para lógica de negocios) y un backend (por ejemplo, una base de datos) y todos esos componentes procesan la contraseña. Un atacante que haya comprometido uno de esos componentes podría interceptar contraseñas.

Una mitigación es cifrar las contraseñas. Con el cifrado de clave pública sería posible el siguiente escenario:

• el backend crea una clave pública y privada
• la clave pública se incluirá en el formulario donde el usuario ingresa su contraseña
• cuando el usuario envía el formulario, un código JavaScript encripta la contraseña usando la clave pública
• el frontend recibe la contraseña cifrada, la envía al middleware que la envía al backend
• solo el backend puede descifrarlo

Por lo tanto, un atacante que comprometió la interfaz o el middleware no puede ver la contraseña de texto sin formato.