SRP evita enviar la contraseña durante el intercambio de inicio de sesión; no hace inofensivo un verificador robado.
Secure Remote Password, o SRP, permite que un cliente y un servidor se autentiquen mediante una contraseña sin enviarla en el intercambio normal del protocolo. Puede reducir la exposición frente a un servidor que, de otro modo, recibiría la contraseña durante el inicio de sesión.
No elimina del servidor todos los secretos relacionados con la contraseña. El servidor conserva un verificador, y un verificador robado puede permitir intentos de adivinar la contraseña sin conexión. Esa distinción es esencial al evaluar afirmaciones sobre el «inicio de sesión de conocimiento cero».
¿Qué cambia respecto a un inicio de sesión convencional con contraseña?
En un diseño convencional, el cliente envía la contraseña por una conexión TLS autenticada. Un servidor bien diseñado compara un hash de contraseña adecuado con sal, evita registrar las credenciales y aplica medidas contra los intentos de adivinación. TLS protege la conexión; el hash de contraseña protege de otra manera la credencial almacenada.
SRP cambia el intercambio. Durante el registro, el sistema establece la sal y el material del verificador. Al iniciar sesión, ambas partes utilizan valores nuevos del protocolo y sus respectivos secretos para establecer y confirmar material de claves compartido. El cliente usa la contraseña; el servidor, su verificador. Un cliente honesto no envía la contraseña en sí como carga útil del inicio de sesión.
La especificación de SRP en RFC 2945 explica los fundamentos del protocolo. Los perfiles e implementaciones posteriores requieren revisar sus parámetros exactos y comprobaciones de mensajes; llamar «SRP» a un diseño no demuestra que todas sus decisiones de implementación sean acertadas.
| Pregunta | Inicio convencional con contraseña sobre TLS | Intercambio SRP correctamente implementado |
|---|---|---|
| ¿Recibe el servidor de la aplicación la contraseña introducida al iniciar sesión? | Normalmente sí | No como parte del intercambio del protocolo |
| ¿Qué material sensible de autenticación se almacena? | Habitualmente, un hash de contraseña con sal | Sal y un verificador derivado de la contraseña |
| ¿Permite una base de datos robada adivinar contraseñas sin conexión? | Sí, según el material almacenado | Sí, el material de verificadores SRP robados puede permitirlo |
| ¿Protege frente a un registrador de teclas? | No | No |
| ¿Cifra automáticamente el historial de mensajes? | No | No |
Por qué sigue importando un verificador robado
La sección 3.3 de RFC 5054 trata expresamente los verificadores robados. Explica que un verificador puede permitir a un atacante hacerse pasar por el servidor y realizar ataques de diccionario para recuperar la contraseña.
La distinción importante es que el verificador no es simplemente un token reutilizable de inicio de sesión del cliente. Eso no lo hace inofensivo. Un atacante puede probar contraseñas candidatas contra el material robado, en lugar de resolver un problema de logaritmo discreto para cada secreto posible. Una contraseña débil o reutilizada sigue siendo un riesgo grave.
Los límites de intentos en línea pueden ralentizar los ataques contra un servicio activo, pero no controlan los cálculos realizados sobre una base de datos robada. La protección de la base de datos, el procesamiento cuidadoso de contraseñas y las contraseñas seguras y únicas siguen siendo pertinentes.
Qué no protege SRP
Un dispositivo comprometido: El malware puede capturar la contraseña antes de que comience el protocolo o robar después una sesión autenticada.
Una página de inicio de sesión maliciosa: Si la propia página que solicita la contraseña es hostil, puede enviar el texto introducido a otro lugar. Una aplicación web sigue necesitando una vía de distribución fiable.
Todas las vías de recuperación: Un proceso por correo electrónico, SMS o soporte que concede acceso a la cuenta tiene sus propios requisitos. El método normal de inicio de sesión más sólido puede quedar debilitado por una alternativa menos segura.
Todos los ataques activos de red: Importan los parámetros del protocolo, la validación de entradas, la confirmación mutua y la conexión autenticada que lo rodea. No sustituya las protecciones TLS prescritas para un despliegue por el lema «la contraseña nunca viaja».
Los metadatos o el cifrado del chat: La autenticación responde a si debe admitirse una sesión. No determina qué registros de conversaciones existen ni quién posee las claves para descifrar mensajes.
Cómo separa Livara el inicio de sesión de la recuperación de identidad
La descripción de seguridad de Livara presenta la autenticación SRP por separado de su protocolo de mensajería LVR1. También documenta una copia de seguridad cifrada de identidad de la versión 7, protegida por una clave de recuperación aleatoria de 256 bits distinta.
La copia se sella criptográficamente antes de subirla y restaura la identidad criptográfica, no el historial del chat. Conocer solo la contraseña de una cuenta no restaura esas claves de cifrado. A la inversa, afirmar que el soporte no puede reconstruir un secreto de cifrado no demuestra que no pueda existir ninguna acción de gestión de cuentas ni ningún proceso de cambio de contraseña.
El modelo de amenazas también incluye los dispositivos comprometidos y los metadatos visibles de comunicación. No debe utilizarse SRP para etiquetar todo el servicio como de «conocimiento cero» sobre cada aspecto de la actividad del usuario.
Una lista práctica de evaluación
Como usuario, elija una contraseña segura y única, proteja el dispositivo, guarde el material de recuperación en un lugar separado y apropiado y comprenda cómo se revocan las sesiones. No introduzca un secreto en un sitio no fiable solo porque afirme usar SRP.
Como revisor técnico, solicite el perfil exacto del protocolo, el procesamiento de la contraseña al verificador, la validación de entradas, la gestión de fallos, el flujo de registro y el diseño del restablecimiento. Revise conjuntamente cliente y servidor. Incluya pruebas de valores públicos no válidos, repetición de intercambios y sesiones interrumpidas, en vez de confiar únicamente en una prueba de inicio de sesión correcta.
SRP es una herramienta útil para limitar la revelación de contraseñas durante la autenticación. Su valor resulta más claro cuando se describen sus beneficios reales junto con el robo de verificadores, los dispositivos comprometidos y los riesgos de recuperación, en lugar de presentarlo como el fin de los problemas de seguridad de las contraseñas.
