SRP no envía la contraseña dentro del protocolo; eso no equivale a eliminarla, ser inmune al phishing ni hacer inocuo el verificador.
Las passkeys y SRP son dos formas diferentes de autenticación. Una passkey utiliza un par de claves y puede eliminar la necesidad de una contraseña. SRP sigue basándose en una contraseña, pero, cuando el protocolo se implementa correctamente, no envía la contraseña en sí al servidor para demostrar que se conoce.
Por tanto, «iniciar sesión sin enviar una contraseña» no es lo mismo que «iniciar sesión sin tener una contraseña». La elección debe basarse en el riesgo de phishing, la gestión de credenciales, la recuperación y la calidad de la implementación, no en una etiqueta general de «conocimiento cero».
¿Qué cambia una passkey?
En la autenticación con passkeys, el servicio conserva la clave pública y el usuario confirma el acceso mediante el control de la clave privada. Vincular la credencial al servicio y al origen correspondientes es una parte importante de su resistencia al phishing. Explicación de FIDO sobre las passkeys.
No todas las passkeys se sincronizan necesariamente en la nube. Algunas están vinculadas a un dispositivo o una llave de seguridad; otras se transfieren entre dispositivos mediante un proveedor de credenciales. Hay que examinar el modelo de recuperación y la protección de la sincronización de ese proveedor concreto. La «sincronización en la nube», por sí sola, no demuestra que la empresa almacene las claves de forma legible.
La seguridad de la sesión después del acceso también es independiente. Una passkey no neutraliza automáticamente el malware del dispositivo ni el robo de una sesión válida.
¿Qué entrega SRP al servidor?
SRP pertenece a la familia de intercambios de claves autenticados mediante contraseña. En lugar de guardar la contraseña, el servidor conserva datos como una sal y un verificador. Mediante el intercambio de mensajes del protocolo, ambas partes comprueban el conocimiento del secreto y la clave compartida.
Pero el verificador no es un dato inocuo. La sección 3.3 del RFC 5054 afirma explícitamente que un atacante que obtenga el verificador puede realizar un ataque de diccionario para adivinar la contraseña. Por tanto, es falsa la afirmación de que «robar la base de datos no permite ningún intento de adivinación fuera de línea».
Siguen siendo necesarios una contraseña robusta, protección del servidor, parámetros adecuados, validación de entradas y controles de los intentos de acceso. SRP tampoco garantiza que la página donde escribe su contraseña sea segura: el código malicioso puede capturarla antes de ejecutar el protocolo.
Una comparación justa
| Pregunta | Passkey | SRP |
|---|---|---|
| ¿El usuario memoriza una contraseña del servicio? | Normalmente no; necesita controlar la credencial | Sí, el método depende de conocer la contraseña |
| ¿Qué guarda el servicio para el acceso? | Una clave pública e información relacionada | Un verificador y parámetros relacionados |
| ¿Cómo se logra la resistencia al phishing? | Vinculando la credencial al servicio/origen en el diseño FIDO | No enviar la contraseña en el protocolo no basta para hacer segura una página de entrada falsa |
| ¿Es obligatoria la nube? | No; también hay opciones vinculadas a un dispositivo | El protocolo no necesita intrínsecamente un proveedor externo de identidad, pero sí un servicio de autenticación |
| ¿Cómo funciona la recuperación? | Depende del tipo de credencial y del proveedor | Lo determinan las políticas de la cuenta y del producto, no el nombre SRP |
Esta tabla no permite establecer una clasificación absoluta de todas las implementaciones. Un proceso de recuperación débil puede reducir la ventaja de un método de acceso sólido.
¿Qué relación tiene el acceso a la cuenta con las claves del chat?
La autenticación indica al servicio quién tiene permiso para actuar. Las claves de cifrado de mensajes determinan quién puede abrir el contenido. Un producto puede relacionar ambas cosas, pero esa relación debe estar documentada.
La documentación de seguridad de Livara describe SRP para el acceso y, por separado, el paquete de recuperación v7 para la identidad cifrada. Ese paquete recupera la identidad, no el historial del chat. Por eso, «la contraseña de acceso es correcta» no significa que «se hayan recuperado todas las claves y los mensajes antiguos».
Este artículo es una comparación conceptual, no una prueba práctica de todos los métodos de acceso de Livara ni una certificación de que el producto implemente exactamente un RFC concreto.
¿Qué debemos preguntar al elegir?
- Si se pierde el dispositivo, ¿cuál es la vía alternativa de acceso y quién la controla?
- ¿Es la recuperación más débil que el acceso principal?
- ¿Cómo se pueden ver y revocar las sesiones desconocidas?
- ¿Cambiar el método de acceso modifica las claves de los mensajes o los dispositivos vinculados?
- ¿Qué cuenta y qué protección independiente se necesitan para sincronizar las credenciales?
Conclusión: No califique las passkeys de intrínsecamente «inseguras porque usan la nube» ni SRP de «inmune a filtraciones porque es de conocimiento cero». Los límites de cada método y la política de recuperación del producto son la base de una comparación fiable.
