Los tokens de autenticación que un servidor entrega al iniciar sesión son la prueba de identidad del usuario: quien los posea será tratado como el legítimo titular. En los últimos años, malware especializado del tipo infostealer (LummaC2, entre otros) ha aprendido a exfiltrar esos tokens, lo que permite a los atacantes acceder a cuentas protegidas con autenticación multifactor o passkeys, pues basta con presentar el token. Cifrar los tokens en disco no resuelve el problema, porque el malware puede extraerlos de la memoria del navegador u obtener la clave de descifrado.
Este artículo repasa casi quince años de intentos por atar criptográficamente los tokens a la sesión TLS del usuario. La primera propuesta, de Dirk Balfanz, planteaba que el navegador generase certificados autofirmados sobre la marcha y vincular la cookie a un hash de ese certificado; si se usase una clave respaldada por hardware, el robo resultaría imposible. La idea, elegante, no prosperó por problemas de privacidad (la identidad se enviaba antes de establecer la sesión), de granularidad (los certificados debían coincidir con el ámbito de las cookies) y de incompatibilidad con la reanudación de sesión TLS.
Le siguieron los channel IDs, que sustituían los certificados por una clave pública cruda con prueba de posesión, y finalmente token binding, un estándar que abarcó tres RFC y resolvió los problemas previos a costa de mayor complejidad. Chrome retiró su soporte incompleto en noviembre de 2018, Edge lo mantuvo hasta finales de 2024 y, pese a culminar el proceso de estandarización, la iniciativa está funcionalmente muerta.