Validación de contraseña en el navegador

Por qué entonces

Dar respuesta inmediata al usuario mientras teclea era, y sigue siendo, buena experiencia de uso: la barra que sube anima a poner una contraseña mejor. El problema es que en su día se confundieron dos cosas distintas —'validar la contraseña' y 'validar en el navegador'— cuando el modelo de amenazas todavía no estaba tan asentado. Y existía un atajo: hacia 2007 circulaba un medidor de contraseñas en JavaScript (The Password Meter) que casi todo el mundo copiaba y pegaba. Poner esas líneas era cuestión de minutos y parecía que reforzaba la seguridad.

Qué pasó

La seguridad web maduró alrededor de un principio que hoy es de manual: nunca te fíes del cliente. Todo lo que ocurre en el navegador —cada cálculo, cada validación, cada campo— está bajo el control de quien tiene el navegador delante, y puede cambiarse. La validación de seguridad tiene que hacerse, sí o sí, en el servidor. Esto pasó a ser una de las primeras lecciones de cualquier formación en seguridad.

Por qué está mal hoy

Si el servidor vuelve a validar la contraseña por su cuenta, las cientos de líneas de cálculo del navegador son solo comodidad visual —perfecto, pero entonces no son seguridad—. Si el servidor se fía del número que le manda el navegador, no protegen nada, porque ese número es un dato que el usuario controla. En cualquiera de los dos casos, tener un valor con aspecto de seguridad calculado en el cliente y devuelto al servidor es una señal de que el modelo mental no era el correcto. Y hay una capa más: al ser un copia-pega de 2007, arrastra ideas sobre contraseñas —penalizar secuencias, exigir símbolos obligatorios— que las guías actuales (NIST, 2017) han desaconsejado en favor de premiar sobre todo la longitud.

En lo público

Aquí es la puerta de contraseña de una plataforma por la que las empresas acceden para licitar en contratos públicos. Lo inquietante no son las líneas de JavaScript en sí: es lo que revelan sobre cómo se pensó la seguridad del sistema. Un cálculo de seguridad hecho en el navegador dice que, en algún momento, se dio por bueno confiar en el lado que no se debe.

El arreglo

La regla es simple: validar siempre en el servidor. La comprobación del navegador se queda solo como ayuda visual, y nada relevante para la seguridad debería viajar jamás en un campo que el cliente puede editar. De paso, conviene revisar la política de contraseñas contra las guías actuales: longitud por encima de reglas de composición.