La mayoría de las comparaciones entre estas dos opciones se reducen a enfrentar la comodidad con la seguridad, con una afirmación vaga de que las llaves son "más seguras". Existe una respuesta más precisa, y está escrita negro sobre blanco en una norma.
La frase que zanja la cuestión del phishing
El NIST SP 800-63B, sección 5.2.5, es directo al respecto. Los autenticadores que implican la introducción manual de una salida de autenticador, como los autenticadores fuera de banda y OTP, no deben considerarse resistentes a la suplantación del verificador, porque la introducción manual no vincula la salida del autenticador a la sesión específica que se está autenticando.
La misma sección explica el ataque en lugar de dejarlo implícito: en un ataque de tipo machine-in-the-middle, un verificador impostor podría reproducir la salida del autenticador OTP hacia el verificador real y autenticarse con éxito.
Ese es todo el mecanismo. Tu código de seis dígitos es correcto. Simplemente es correcto en todas partes, incluida una página que solo se parece a la de tu banco.
Por qué la vinculación es la diferencia real
La norma define la resistencia a la suplantación del verificador como establecer un canal protegido autenticado con el verificador y después vincular de forma fuerte e irreversible un identificador de canal a la salida del autenticador, por ejemplo firmando ambos valores juntos con una clave privada.
Contrasta eso con lo que hace físicamente cada método.
Una aplicación de autenticación genera un número a partir de un secreto compartido y un reloj. Nunca llega a saber en qué sitio estás. Tú eres la capa de transporte, y puedes ser desviado.
Una llave de seguridad firma un desafío junto con la identidad de la sesión. La FIDO Alliance describe las passkeys como algo que usa técnicas estándar de criptografía de clave pública para proporcionar autenticación resistente al phishing. No hay ningún número que tengas que leer en voz alta, y por tanto nada que un atacante pueda retransmitir.
Cómo se ve el ataque desde tu lado
La abstracción oculta lo corriente que es esto, así que conviene recorrerlo paso a paso.
Recibes un mensaje sobre tu cuenta. El enlace lleva a una página que se muestra correctamente, porque el servidor del atacante está obteniendo la página real y dejándola pasar. Introduces tu contraseña. El servidor del atacante la envía al sitio real de inmediato. El sitio real pide un segundo factor, así que la página falsa también te lo pide a ti.
Abres tu aplicación y lees seis dígitos. El servidor del atacante los introduce en el sitio real dentro de la misma ventana de treinta segundos. El sitio real ve una contraseña válida y un código válido, y emite una sesión. El atacante posee ahora esa sesión.
Fíjate en lo que nunca ocurrió. No se rompió nada, no se robó ningún secreto de tu teléfono, y tu aplicación se comportó exactamente como fue diseñada. El código era auténtico. Simplemente se usó en un lugar que tú no pretendías, y ni tú ni la aplicación teníais forma de notarlo, porque el código no lleva ninguna información sobre su destino.
Repite la misma secuencia con una llave de seguridad y se detiene en el segundo factor. La llave no produce ningún número para que tú lo retransmitas. Firma una respuesta vinculada al sitio que realmente lo está pidiendo, de modo que el servidor del atacante recibe algo que solo funciona en su propio dominio, lo cual no le sirve de nada.
Dónde una llave tampoco ayuda
Ser preciso sobre los límites importa tanto como serlo sobre las virtudes, porque una llave no es un escudo de propósito general.
No protege una sesión ya emitida. Si un programa malicioso en tu equipo roba una cookie de sesión después de que hayas iniciado sesión legítimamente, el paso de inicio de sesión ya quedó atrás y la llave ya no interviene.
No protege la vía de recuperación. Una cuenta que puede restablecerse por correo electrónico o por un agente de soporte es solo tan fuerte como esa vía. Precisamente por eso la cuenta de correo es la primera que hay que proteger, y por eso las preguntas de recuperación de cuenta siguen siendo un objetivo fácil.
No protege lo que ve un dispositivo comprometido. Si el equipo está totalmente comprometido, el atacante está dentro de la sesión autenticada contigo.
No cubre los servicios que no la admiten. Este es el límite práctico para la mayoría de la gente, y la razón por la que una llave es un añadido a una aplicación de autenticación y no un sustituto de ella.
El matiz que la mayoría de las comparaciones deja caer
Aquí es donde mucha literatura sobre seguridad se pasa de la raya, así que conviene decirlo con claridad.
La resistencia a la suplantación del verificador solo se exige en AAL3 dentro del marco del NIST. En AAL1 y AAL2 no es obligatoria. Una aplicación TOTP es por tanto un segundo factor conforme para una parte muy grande de las cuentas ordinarias, y sigue siendo una mejora importante frente a los códigos por SMS o frente a no tener ningún segundo factor.
Así que el planteamiento honesto no es "las aplicaciones están rotas". Es que las aplicaciones tienen una debilidad específica, el phishing en tiempo real, y que esa debilidad es estructural y no un fallo de ninguna aplicación en particular. Ninguna actualización de tu aplicación de autenticación lo va a arreglar, porque la brecha está en el propio paso de introducción manual.
Elegir sin darle demasiadas vueltas
La decisión se deriva de lo que obtiene un atacante si una cuenta concreta cae.
Usa una llave de seguridad donde una vulneración sea irrecuperable. Tu cuenta de correo primero, porque es la vía de restablecimiento de contraseña de todo lo demás. Después tu gestor de contraseñas. Después cualquier cosa financiera que admita llaves.
Conserva la aplicación por cobertura. La mayoría de los servicios todavía no admiten llaves de seguridad. Una aplicación de autenticación en esas cuentas es mucho mejor que nada, y no cuesta nada.
No uses una única llave sin alternativa. Registra una segunda, o guarda códigos de recuperación impresos y almacenados sin conexión. Perder tu única llave es un bloqueo autoinfligido, y es un fallo más frecuente que ser víctima de phishing.
Si estás decidiendo qué llave comprar, comparamos los modelos actuales en nuestra comparativa de llaves de seguridad hardware.
Cara a cara
| Aplicación de autenticación | Llave de seguridad | |
|---|---|---|
| Resiste el phishing en tiempo real | No, según el NIST 5.2.5 | Sí, respuesta vinculada a la sesión |
| Lo que manejas | Un código que lees y vuelves a teclear | Nada, el dispositivo firma |
| Exigido en AAL3 | No basta por sí solo | Cumple el requisito |
| Funciona en la mayoría de servicios | Sí | Solo donde está admitida |
| Coste | Gratis | Aproximadamente de 25 a 60 unidades monetarias por llave |
| Principal modo de fallo | Caes en el phishing e introduces un código válido | Pierdes la llave sin ninguna copia registrada |
| Recuperación en caso de pérdida | Reinstalar desde una copia de las semillas | Registrar una segunda llave, o códigos de recuperación |
Las dos últimas filas son las que la gente subestima. El riesgo dominante en el mundo real con una aplicación es que te engañen para usarla correctamente en el momento equivocado. El riesgo dominante en el mundo real con una llave es perderla después de haber registrado solo una.
★ Audit Cure53 2024 · ✓ Plan gratuit · Cross-platform
Guarda los códigos de recuperación donde vayas a seguir teniéndolosLos códigos de recuperación son lo que te permite volver a entrar cuando se pierde una llave. Un gestor de contraseñas los mantiene fuera del dispositivo que estás intentando recuperar, que es justamente de lo que se trata.→La versión corta
La cuestión del phishing no es una cuestión de opinión. El NIST afirma que los autenticadores OTP no pueden considerarse resistentes a la suplantación del verificador, y explica por qué: la introducción manual no vincula el código a la sesión. Una llave de seguridad firma la propia sesión, así que no hay nada que retransmitir.
Pero el requisito se aplica en AAL3, no en todas partes. Una aplicación de autenticación sigue siendo un segundo factor legítimo para la mayoría de las cuentas. Pon llaves donde una pérdida sería irrecuperable, conserva la aplicación para la larga cola, y asegúrate de tener una forma de volver a entrar.
Las definiciones y requisitos descritos aquí están tomados de la NIST Special Publication 800-63B, y la caracterización de las passkeys del propio material de la FIDO Alliance, ambos comprobados en el momento de la redacción. Las normas se revisan; verifica frente al texto vigente antes de apoyarte en una cláusula concreta. Los enlaces comerciales llevan el atributo rel="sponsored nofollow"; puede aplicarse una comisión de afiliación sin coste adicional para ti.
★ Audit Cure53 2024 · ✓ Plan gratuit · Cross-platform
Un gestor con 2FA y passkeys integrados → NordPassGuarda TOTP y passkeys · XChaCha20 · plan gratis→Preguntas frecuentes
¿Es una llave de seguridad realmente más resistente al phishing que una aplicación de autenticación?
En este punto concreto la norma es inequívoca. El NIST SP 800-63B indica que los autenticadores que implican la introducción manual de una salida, como los autenticadores fuera de banda y OTP, no deben considerarse resistentes a la suplantación del verificador, porque la introducción manual no vincula la salida a la sesión específica que se está autenticando. Un autenticador criptográfico firma un identificador de canal junto con su respuesta, que es lo que hace una llave de seguridad y lo que un código de seis dígitos no puede hacer.
¿Por qué importa tanto el hecho de teclear el código?
Porque el código no tiene ni idea de dónde lo estás escribiendo. El NIST describe el ataque de forma directa: un verificador impostor puede reproducir la salida del autenticador OTP hacia el verificador real y autenticarse con éxito. Una página de inicio de sesión falsa recoge tu código y lo usa dentro de su ventana de validez. El código es válido, el sitio no lo es, y nada en el proceso detecta la diferencia.
¿Significa eso que las aplicaciones de autenticación son inseguras?
No, y conviene ser preciso. La resistencia a la suplantación del verificador solo se exige en AAL3 dentro del marco del NIST. En AAL1 y AAL2 no es obligatoria, así que una aplicación TOTP sigue siendo un segundo factor conforme para una gran parte de las cuentas ordinarias. Es una mejora muy grande frente al SMS y frente a no tener ningún segundo factor. La brecha es específica: afecta al phishing en tiempo real, no a la solidez general del método.
¿Qué hace que una llave de seguridad sea resistente donde un código no lo es?
La credencial es criptográfica en lugar de un número transcrito. La FIDO Alliance describe las passkeys como algo que usa técnicas estándar de criptografía de clave pública para proporcionar autenticación resistente al phishing. La respuesta la produce el dispositivo y queda vinculada a la sesión, así que no hay nada que tú tengas que leer en voz alta ni nada que un atacante pueda retransmitir.
¿Debería usar ambos?
Esa suele ser la respuesta práctica. Usa una llave de seguridad en las cuentas cuya pérdida sería peor, normalmente tu correo electrónico y tu gestor de contraseñas, ya que el correo es la vía de restablecimiento de todo lo demás. Mantén una aplicación de autenticación para los muchos servicios que no admiten llaves. Registra una segunda llave o guarda códigos de recuperación sin conexión, porque una única llave sin alternativa es un riesgo en sí misma.
