SRP: protocolo de contraseña remota segura

El protocolo Secure Remote Password (SRP) fue desarrollado por Tom Wu en Stanford y publicado como RFC 2945 en 2000; posteriormente se definió una versión mejorada, SRP-6a. SRP permite la autenticación mutua basada en una contraseña compartida sin transmitir jamás la contraseña, ni siquiera de forma cifrada.

Durante el registro de SRP, el cliente calcula un verificador de contraseña v = g^x mod N, donde x = H(salt || password) y N es un primo seguro grande. El servidor almacena únicamente la sal y el verificador v. Aunque la base de datos del servidor se vea comprometida, el verificador almacenado no revela directamente la contraseña.

Durante el inicio de sesión mediante SRP, el cliente y el servidor realizan un intercambio similar a Diffie-Hellman que genera una clave de sesión compartida. El cálculo de cada lado incorpora el valor derivado de la contraseña, por lo que la clave de sesión resultante solo puede calcularla correctamente quien conoce la contraseña y quien posee el verificador, respectivamente.

SRP proporciona autenticación mutua: el cliente demuestra que conoce la contraseña y el servidor demuestra que posee el verificador legítimo. Esto evita los ataques de phishing en los que un servidor falso intenta recopilar información de la contraseña, porque un servidor falso no puede completar correctamente el intercambio de SRP sin el verificador verdadero.

El verificador se calcula como v = g^x mod N, donde x = H(salt || password), g es un generador y N es un primo seguro de 2048 bits o más. El problema del logaritmo discreto hace que recuperar x a partir de v sea computacionalmente inviable. La contraseña solo se puede verificar completando correctamente todo el intercambio de SRP.

SRP-6a aborda las debilidades de los diseños originales SRP-3 y SRP-6 mediante la introducción de un parámetro multiplicador k = H(N, g) y la modificación del orden de los cálculos del cliente y del servidor. Estos cambios evitan ciertos ataques de adivinación con ventaja de dos por uno y garantizan que la contribución del servidor quede vinculada desde una fase temprana del protocolo.

SRP se ha implementado de forma significativa en sistemas reales. Apple utiliza SRP en la sincronización de iCloud Keychain para permitir que los dispositivos recuperen los datos del llavero sin revelar la contraseña de la cuenta a los servidores de Apple. 1Password ha utilizado SRP en su modelo de autenticación para evitar la exposición de credenciales en el servidor.

Como SRP genera una clave de sesión que vincula tanto la contraseña como el verificador del servidor, un servidor de phishing no puede completar correctamente el handshake de SRP. Un usuario que se conecte a un sitio de phishing mediante SRP no podrá autenticarse, lo que proporciona una propiedad antiphishing integrada que no existe en el envío tradicional de contraseñas.

SRP requiere muchos recursos computacionales, ya que implica realizar exponenciaciones modulares con enteros grandes (de más de 2048 bits). Es complejo implementarlo correctamente, debido a numerosos problemas sutiles en la validación de parámetros que han provocado vulnerabilidades en algunas implementaciones. El protocolo también requiere un canal seguro (TLS) para evitar la interceptación pasiva del propio intercambio.

RFC 5054 define suites de cifrado TLS-SRP que integran la autenticación mutua de SRP directamente en el handshake de TLS. Esto elimina la necesidad de certificados del servidor y, al mismo tiempo, proporciona autenticación mutua cifrada. Sin embargo, TLS-SRP ha tenido una adopción limitada en la práctica, ya que FIDO2 y OPAQUE han surgido como alternativas más modernas.

Aunque SRP fue revolucionario, las alternativas modernas como OPAQUE proporcionan garantías de seguridad más sólidas (resistencia a la precomputación) y FIDO2/passkeys eliminan por completo las contraseñas. Para los sistemas nuevos se prefieren OPAQUE o FIDO2, pero SRP sigue siendo una opción válida para los sistemas que requieren autenticación mutua basada en contraseña sin vulnerabilidad al phishing.

En SRP, ¿qué almacena el servidor en lugar de la contraseña del usuario?

SRP almacena un verificador de contraseña, no la contraseña; genera una clave de sesión compartida mediante un intercambio similar a DH y proporciona autenticación mutua resistente al phishing. SRP-6a mejora el diseño original al resistir los ataques de adivinación. iCloud Keychain de Apple y 1Password utilizan SRP en producción. OPAQUE y FIDO2 son sucesores modernos para los sistemas nuevos.