La historia del 2FA: de los tokens de hardware a las passkeys

Por qué las contraseñas solas dejaron de ser suficientes

Durante décadas, un nombre de usuario y una contraseña eran todo lo que separaba a un atacante de tu cuenta. Eso era manejable cuando las cuentas vivían en un único servidor de oficina. Dejó de serlo cuando casi todo — la banca, el correo electrónico, el trabajo, las compras — se mudó a internet.

Dos problemas se agravaron mutuamente. Primero, la gente reutiliza contraseñas: una filtración en un sitio menor entrega a los atacantes credenciales que también pueden abrir una bandeja de correo o una cuenta bancaria. Segundo, las filtraciones alcanzaron escala industrial, produciendo enormes cantidades de pares de usuario y contraseña robados que los delincuentes prueban automáticamente contra otros servicios.

La autenticación de un solo factor tiene un fallo estructural: el único factor del que depende — un secreto — puede ser adivinado, robado, reutilizado o suplantado por phishing.

Los investigadores en seguridad describen la autenticación en términos de tres tipos de factores:

• Algo que sabes — una contraseña o un PIN
• Algo que tienes — un teléfono, un token de hardware o una llave de seguridad
• Algo que eres — una huella dactilar o el rostro

Combinar dos factores distintos eleva el nivel de forma drástica: una contraseña robada ya no abre la puerta por sí sola. Los atacantes también deben robar un dispositivo o un dato biométrico. Esa idea simple impulsa todo lo que sigue.

La era de los tokens de hardware (1980–2000)

Los primeros segundos factores de uso generalizado fueron pequeños tokens de hardware: llaveros o dispositivos del tamaño de una tarjeta con una pequeña pantalla que mostraba un código numérico. Los bancos los entregaban a sus clientes corporativos, y las empresas se los daban a sus empleados para los inicios de sesión en la VPN y la red. El SecurID de RSA, introducido en la década de 1980, se convirtió en el ejemplo más conocido.

Cómo funcionaban los códigos sin conexión

Los tokens no necesitaban conectividad. En los diseños basados en el tiempo, el token y el servidor compartían una semilla secreta y un reloj; cada minuto o medio minuto, ambos derivaban el mismo código a partir de esa semilla más la hora actual. Los diseños basados en eventos reemplazaban el reloj por un contador: al pulsar el botón se incrementaba, y ambos lados calculaban el código a partir del nuevo valor. Como el token y el servidor seguían reglas idénticas, permanecían sincronizados sin necesidad de comunicarse nunca.

Por qué los usuarios comunes nunca los vieron

Cada llavero debía fabricarse, enviarse, registrarse y finalmente reemplazarse cuando se agotaba la batería o se perdía. Ese costo por usuario, más el inventario y la sobrecarga del servicio de asistencia, confinó los tokens de hardware a los bancos y las grandes empresas.

Los códigos SMS llevan la 2FA al gran público

A mediados de la década de 2000, los teléfonos móviles estaban por todas partes. Los bancos se dieron cuenta de que podían enviar por SMS un código de un solo uso para confirmar un inicio de sesión o una transferencia, y de repente el segundo factor llegó a millones de personas de la noche a la mañana. Sin dongle que comprar, sin software que instalar — el teléfono que ya llevabas en el bolsillo se convirtió en el segundo factor.

Los servicios web siguieron su ejemplo. Los proveedores de correo electrónico, las redes sociales y las tiendas en línea añadieron "enviar un código a tu teléfono" como opción, y la 2FA dejó de ser una herramienta de seguridad corporativa para convertirse en algo que los usuarios comunes podían activar con unos pocos toques.

Eso sí, el SMS tenía contrapartidas reales:

• SIM swapping: un atacante que engaña o soborna a la operadora para trasladar tu número a una nueva SIM recibe tus códigos.
• Intercepción: los códigos viajan por la red móvil y pueden capturarse mediante ciertos ataques de telecomunicaciones.
• Dependencia de la operadora: sin señal, sin roaming, sin código — y a menudo sin forma de acceder a tu cuenta.

El SMS hizo que la 2FA llegara al gran público, pero también expuso una falla: el segundo factor pertenecía a tu operadora, no a ti.

Aplicaciones de autenticación y aprobaciones push

Los teléfonos inteligentes pusieron un token de hardware en el bolsillo de todos. Las aplicaciones TOTP como Google Authenticator y Authy generan códigos de 30 segundos sin conexión a partir de un secreto compartido. Como la generación es local, los códigos funcionan en modo avión y nunca viajan por la red: sin dependencia del operador, sin intercepción del código en sí.

Inscripción más sencilla

La configuración inicial significaba teclear claves base32 largas a mano. La inscripción mediante código QR reemplazó eso: escanear, listo. Los secretos se transferían en segundos, reduciendo errores de escritura y solicitudes de soporte.

Aprobaciones push

La aprobación push reemplazó por completo la escritura: llega una notificación, un toque te conecta. Era más rápido, más difícil de equivocarse y funcionaba incluso cuando los usuarios no podían ver la pantalla de inicio de sesión. El number matching — teclear un código de la pantalla en el aviso — añadió después una salvaguarda contra aprobaciones accidentales.

La conveniencia cortaba en ambos sentidos. Los atacantes aprendieron a enviar solicitudes de aprobación repetidamente hasta que un usuario cansado tocara aceptar — fatiga de push. El number matching y los avisos más claros reducen ese riesgo pero no lo eliminan. Y como las contraseñas y los códigos SMS, los códigos TOTP pueden ser sustraídos mediante phishing cuando se engaña a los usuarios para que los lean en voz alta.

Llaves de seguridad y el cambio a la autenticación de clave pública

A principios de la década de 2010, un grupo llamado FIDO Alliance se propuso eliminar la debilidad fundamental de todos los métodos anteriores: el secreto compartido. Las contraseñas, los códigos SMS e incluso las semillas TOTP existen tanto en el servidor como en el lado del usuario, por lo que cualquiera que robe la copia del servidor puede iniciar sesión. FIDO reemplazó este modelo con criptografía de clave pública. La clave privada nunca sale de tu dispositivo; el servidor almacena solo una clave pública y emite desafíos que solo tu clave privada puede responder. Ningún secreto cruza nunca la red.

Llaves de seguridad de hardware

Las llaves de seguridad son pequeños dispositivos físicos que se conectan por USB, NFC o Bluetooth. Su propiedad definitoria es la resistencia al phishing: la llave verifica el origen del sitio web antes de firmar cualquier cosa, por lo que una página de inicio de sesión falsa en un dominio similar no recibe ninguna firma válida.

Por qué importa la vinculación al origen

Como cada firma está vinculada al origen exacto, una credencial capturada de un sitio no puede reutilizarse en otro, ni en el mismo sitio a través de un dominio falsificado. Simplemente no hay nada reutilizable que robar.

Passkeys: El capítulo actual

Las passkeys son el capítulo más reciente de esta historia, construidas sobre el framework FIDO2 y su protocolo WebAuthn, que permite a los sitios web verificar inicios de sesión directamente en el navegador. Una passkey reemplaza el secreto compartido de una contraseña por un par de claves criptográficas: la clave privada permanece en tu dispositivo o en tu cuenta sincronizada, mientras que el sitio web solo almacena la mitad pública.

Qué cambia en los inicios de sesión cotidianos

• Nada que escribir. Iniciar sesión significa confirmar con una huella dactilar, el rostro o el PIN del dispositivo. Sin códigos que recibir, reescribir o interceptar.
• Sincronizadas entre dispositivos. Apple, Google y Microsoft sincronizan las passkeys a través de sus servicios de cuenta, así que perder un dispositivo no te deja fuera.
• Sin secretos en el servidor. Como los sitios solo conservan claves públicas, una filtración de la base de datos no revela nada que un atacante pueda usar para iniciar sesión.

Las passkeys son además resistentes al phishing por diseño: el navegador vincula criptográficamente cada credencial a la dirección del sitio web legítimo, por lo que un sitio falso convincente no puede recopilar una credencial que funcione en ningún otro lugar.

Lo que enseña la historia

Cada generación de 2FA equilibró las mismas tres cosas de manera diferente. Los tokens de hardware eran seguros, pero costosos y fáciles de perder. Los códigos SMS eran gratuitos y familiares, pero vulnerables a la interceptación y al SIM swapping. Las aplicaciones de autenticación mejoraron la seguridad a bajo costo, mientras que las aprobaciones push se inclinaron por la conveniencia, a veces a expensas del criterio cuidadoso. Las passkeys finalmente alinean la seguridad con la usabilidad, aunque su adopción lleva tiempo.

La recuperación es el verdadero punto débil

En todas las épocas, los atacantes rara vez vencen al factor en sí. Lo restablecen. Los flujos de recuperación basados en correos electrónicos de respaldo, preguntas de seguridad o una llamada persuasiva al soporte han deshecho incluso la autenticación más fuerte. Una passkey protege poco si la recuperación puede eludirla.

Coexistencia, no reemplazo

Los tokens de hardware, las aplicaciones de autenticación, los códigos SMS y las passkeys coexistirán durante años. Los servicios, los presupuestos y los usuarios avanzan a distintas velocidades.

Conclusión práctica

Activa la 2FA en todos los lugares donde se ofrezca. Prefiere una passkey, una llave de seguridad o una aplicación de autenticación antes que SMS. Guarda los códigos de respaldo sin conexión. Luego revisa tu configuración de recuperación: ahí es donde realmente caen la mayoría de las cuentas.