WebAuthn, otra propuesta para un mundo sin contraseñas

Ya hemos hablado en numerosas ocasiones acerca del estado de la autenticación, de cómo la combinación usuario/contraseña se nos está quedando anticuada. No sólo por las debilidades inherentes tanto en la elección de una buena contraseña como en el de su almacenamiento. Dentro de la buena cantidad de propuestas para solucionar estos problemas, WebAuthn parece una propuesta interesante.

Hasta el día de hoy, todas las contramedidas aportadas a este esquema de autenticación han sido parches o paños calientes. ¿Los atacantes pueden exfiltrar la base de datos con los hashes y recuperar las contraseñas mediante ataques por tablas arcoíris? Agreguemos una sal. ¿Las contraseñas que eligen los usuarios son débiles y predecibles? Impongamos un conjunto de reglas, mayúsculas, números, símbolos…que al final, y como efecto paradójico, hacen que el usuario las olvide y en cada autenticación resetee la contraseña.

Pero si hay una constante en la ciencia y la tecnología es que todo cambia. No nos referimos a mantener el mismo sistema y agregar un segundo factor de seguridad, o a los proveedores de identidad que al fin y al cabo, desplazan y centralizan el “problema”. Si bien la completa desaparición del combo usuario y contraseña no va suceder en el corto y medio plazo, las nuevas propuestas parten del reconocimiento tácito de la debilidad de estos y exploran alternativas que permitan, progresivamente, ir librándonos del uso farragoso de aquellas.

Hablamos de WebAuthn iniciativa arropada por Microsoft, Mozilla, Google y Yubico, entre otros. La idea es simple: sustituir la creación y autenticación de cuentas en aplicaciones webs basadas en contraseñas por un esquema centrado en la criptografía de clave pública y apoyado en los mecanismos de autenticación ya existentes en los sistemas, tales como Windows Hello o Apple Touch ID.

Esto tiene un efecto disuasorio importante (aunque no definitivo) respecto al almacenamiento de credenciales en la parte del servidor. Ya no se almacena secreto alguno del usuario en base de datos. Lo que se encontrarían los atacantes es un conjunto de claves públicas que no tienen utilidad alguna para acceder a la cuenta de un usuario, y mucho menos pretender usarlas en múltiples sitios (algo que sí ocurre con las contraseñas: obtienes una, pruebas en múltiples sitios y obtienes acceso). Así que ataca a uno de los grandes males de la dejadez de los usuarios: reutilizar la misma contraseña para todo.

Así pues, cuando el usuario se registra en una aplicación web, no se le preguntaría por contraseña alguna. En ese proceso, y de forma transparente, se van a generar dos claves, una pública que almacenará la aplicación y otra privada (esta es la importante) que permanecerá a buen recaudo en el dispositivo del usuario. Esta última es la que servirá para firmar todo lo que salga del dispositivo y la pública se encargará, en la parte del servidor, de constatar la autenticidad de las peticiones.

En el siguiente esquema, podemos ver el ciclo de registro en una aplicación web:

Como vemos, el papel central se reserva al navegador (en realidad cualquier “User-agent”, que implemente la API especificada), el cual incorpora las API especificadas de WebAuth. Estas son las que se comunican con el Relaying (aplicación en la que queremos efectuar el registro) y el “Autenticador” que podría ser, por ejemplo, el lector de huellas o el sistema de reconocimiento facial que es quien prueba quienes somos y nuestra intención.

Tras este registro, el sistema está listo para autenticarnos de nuevo en la aplicación:

Como podemos contemplar en el esquema, las partes siguen siendo las mismas. Se trata en este caso de un ciclo muy similar al registro pero simplificado y que da respuesta a un desafío generado por el sitio web al que queremos acceder y del que ya disponemos de registro. El “Autenticador”, por ejemplo, el lector de huellas, nos pedirá que procedamos a probar nuestra identidad y dará respuesta a dicho desafío. Sin contraseñas de por medio.

Además de esto, se aprovecharían las capacidades de pareado de los dispositivos del usuario. De este modo, aunque nos demos de alta en un sitio web con uno de nuestros dispositivos (supongamos un teléfono móvil) podríamos delegar la autenticación usando el mecanismo de autorización de este cuando accediésemos con otro sistema distinto, pero de nuestra propiedad. El sitio accedería a autenticarnos, pero la solicitud sería desviada al teléfono móvil del usuario, que es el que originó la creación de la cuenta y posee la clave privada; similar al concepto de algunas aplicaciones móviles que se usan como segundo factor de autenticación, esto es el ya típico: “pulse aquí si has abierto sesión en tal sitio”.

Sin lugar a dudas, es una ventaja no tener usuarios que tengan que elegir una contraseña fuerte, que no la compartan en más de un sitio, que la deban recordar (en caso de no usar un gestor de contraseñas) y que además sigue siendo un secreto compartido con todas las consecuencias que conlleva. Por un lado, una credencial en texto plano puede ser robada (keylogger, descuido, etc.) o se puede dar con ella si es débil o sigue un patrón, por otro lado, la forma actual (ya sea segura o no) de almacenar esa contraseña (o su hash) en una base de datos sigue siendo un quebradero de cabeza para los desarrolladores y sobre todo cuando la base de datos termina siendo publicada debido a una intrusión.

Con la capacidad biométrica que están recibiendo los dispositivos móviles en cada nueva actualización, su potencial está siendo adaptado para integrarse en todo tipo de sistemas, aprovechando la relativa ubicuidad de los smartphones. Aunque no esté cerca el fin de los contraseñas, iniciativas como WebAuthn van marcando la dirección a tomar: una autenticación más segura sin dejar de ser menos cómoda.