He estado investigando varios protocolos utilizados para enviar nombres de usuario y contraseñas a servidores web para autenticar, y aunque obviamente todos ellos usan SSL / TLS, me sorprendió un poco ver que incluso con mi banca en línea los sitios en los que las contraseñas se incluyen literalmente "tal como están" en el cuerpo del formulario sin ningún intento de hash o protegerlos de otra manera. Lo que significa que si a) alguien ha puesto en peligro mi máquina, instalar nuevos certificados de autoridad raíz TLS y hacer que las solicitudes a mi banco en línea se envíen a otro servidor o b) me ha dirigido a un sitio que se parece tan convincentemente a mi sitio de banca en línea que no me doy cuenta de que no lo es (p. ej., ataque del homógrafo de IDN), pueden capturar fácilmente mi contraseña de banca en línea. Incluso podría incluir c) un operador malintencionado con acceso a los servidores de back-end también podría obtener mi contraseña.
El ahora popular protocolo OAuth 2.0 también incluye la contraseña no oculta o desprotegida como un campo de formulario o parámetro de consulta (el parámetro de consulta es posiblemente peor, ya que no es raro que las cadenas de consulta sean registradas por completo por los servidores web). Dado que existen protocolos bien conocidos y establecidos para el hashing y la protección de contraseñas (por ejemplo, Autenticación Digestiva) que parecen proporcionar algunos beneficios obvios para mantener las contraseñas protegidas, ¿por qué parece ser que nadie las está utilizando?
Incluso realizar un SHA256 básico en la contraseña + sal predeterminada (en el lado del cliente) sería mejor que nada; obviamente, si el hash está comprometido, un atacante podría usarlo para acceder a los servicios protegidos, pero al menos no tengo ninguna información sobre mi contraseña que pueda ser útil para determinar mis otras contraseñas, incluida la contraseña con la que reemplace la actual cuando debo cambiarla (¡todos sabemos cuál es la rutina más común!)
La única razón que puedo ver para pasar contraseñas no protegidas (aparte de TLS) es que permite que los backends realicen una validación de complejidad en ellas. Pero incluso entonces, esa contraseña solo se debe pasar una vez cuando la establezca por primera vez, no por cada vez que inicie sesión (además, el backend podría realizar verificaciones solo contra el hash, por ejemplo, verificar bien -hashes conocidos, utilizados anteriormente, etc., y dejar el resto al lado del cliente, aceptando que las validaciones del lado del cliente se pueden omitir, y me preocupa que incluso la validación de longitud no es algo que pueda hacer solo con el hash) .