Llaves de seguridad - Dispositivos de autenticación hardware
Lectura de 2 min aprox.
Una llave de seguridad es un dispositivo físico de autenticación por hardware que cumple con los estándares FIDO2/U2F. Con solo conectarla a un puerto USB o acercarla por NFC, funciona como un potente segundo factor de autenticación además de la contraseña. Adopta un método de desafío-respuesta basado en criptografía de clave pública, y su resistencia estructural a los ataques de phishing es lo que la distingue de forma decisiva del OTP por SMS y de TOTP. En 2017, Google hizo obligatorio el uso de llaves de seguridad para todos sus empleados (más de 80 000 personas) y reportó que, a partir de entonces, los compromisos de cuentas por phishing se redujeron a cero.
Productos principales y tipos de conexión
En el mercado de las llaves de seguridad, la serie YubiKey de Yubico tiene una cuota abrumadora, seguida por la Titan Security Key de Google y la serie ePass de Feitian. El tipo de conexión se elige según el entorno en el que se vaya a usar el dispositivo.
| Tipo de conexión | Dispositivos compatibles | Características |
|---|---|---|
| USB-A | PC (puertos tradicionales) | El más extendido. Alta compatibilidad con entornos heredados |
| USB-C | PC / Mac / iPad más recientes | La corriente dominante del futuro. Imprescindible para usuarios de MacBook |
| NFC | Teléfonos inteligentes (Android / iPhone) | Autentica con solo acercarla. Ideal para uso móvil |
| Lightning | iPhone (modelos antiguos) | Para iPhone 14 y anteriores. En retroceso por la transición a USB-C |
En la práctica, tener a mano un modelo compatible con USB-C + NFC es muy versátil, ya que puede usarse tanto en PC como en teléfonos inteligentes.
Por qué es altamente resistente al phishing - Verificación de origen
La principal razón por la que las llaves de seguridad son fuertes contra el phishing reside en el mecanismo que verifica criptográficamente el origen (dominio) del navegador en el momento de la autenticación. Aunque un atacante atraiga al usuario a un sitio falso (por ejemplo, g00gle.com), la llave de seguridad no usará las credenciales destinadas al sitio legítimo (google.com) bajo el origen del sitio falso. Como esta verificación se realiza automáticamente a nivel de hardware, el ataque no prospera aunque el usuario lea mal la URL.
Esta es una característica de la que carecen el OTP por SMS y TOTP. Con el OTP, si el usuario introduce el código en un sitio falso, este queda en manos del atacante; pero con una llave de seguridad no se genera ninguna firma en primer lugar, por lo que también es resistente a los ataques de adversario en el medio (AiTM). Para más detalles, consulta la guía de adopción de llaves de seguridad.
La diferencia con las claves de acceso
Tanto las llaves de seguridad como las claves de acceso se basan en los estándares FIDO2/WebAuthn, pero la forma de almacenar las credenciales es fundamentalmente distinta.
La clave privada queda encerrada dentro del dispositivo físico y no se puede extraer. Si se pierde, iniciar sesión con esa llave se vuelve imposible. Es adecuada para políticas de seguridad corporativas que desean controlar físicamente dónde residen las claves.
La clave privada se sincroniza en varios dispositivos a través del Llavero de iCloud o el Administrador de contraseñas de Google. Puede restaurarse desde la nube incluso si se pierde un dispositivo. Es adecuada para casos que priorizan la comodidad de los usuarios generales.
Diseño de recuperación ante pérdidas
El mayor desafío operativo de las llaves de seguridad es la recuperación en caso de pérdida o avería. Como la clave privada está ligada al dispositivo físico, existe el riesgo de no poder acceder a la cuenta si se pierde la llave. En la práctica, se recomienda el siguiente diseño de recuperación en varias capas.
- Registrar una llave de seguridad de respaldo como segunda llave y guardarla en un lugar seguro
- Configurar de antemano métodos alternativos de autenticación multifactor (claves de acceso, códigos de recuperación, etc.)
- En entornos corporativos, establecer un flujo de recuperación gestionado por los administradores de TI
- Registrar siempre varios métodos de autenticación para las cuentas importantes
Revisar conjuntamente los fundamentos de la autenticación de dos factores y los retos de migrar a las claves de acceso te dará una visión más clara del diseño de autenticación en su conjunto.
Por qué repartir llaves por sí solo no aumenta la resistencia global
Repartir llaves de seguridad no eleva por sí solo la resistencia al phishing de una organización. Los atacantes pueden elegir la vía más fácil de franquear, de modo que, con una adopción voluntaria que solo usan algunas personas, o dejando la introducción de códigos de un solo uso como método alternativo, esa es la vía que se ataca. Añadir un método fuerte y dejar de aceptar uno débil son trabajos distintos, y si el segundo no acompaña al primero, la solidez del conjunto la determina la vía más débil que quede. En la planificación de un despliegue organizativo, las cuestiones centrales son hasta dónde extender el ámbito de usuarios cubiertos, cuándo dejar de aceptar los métodos antiguos y cuánto periodo de gracia conceder antes de ese cambio. Lo difícil del cambio es atender a quienes tienen motivos para no poder usar una llave. Si aquí se conceden excepciones manuales, el propio procedimiento de excepción se convierte en objetivo y, si alguien solicita una excepción suplantando una identidad, la debilidad original regresa. Decidir de antemano cómo se aceptarán las excepciones, incluido el nivel de verificación de identidad exigido, determina la eficacia real del cambio. Al valorar los resultados del despliegue, tampoco hay que fijarse en el número de llaves repartidas, sino en si queda alguna vía en la que la autenticación pueda completarse solo con los métodos antiguos.
¿Te resultó útil este artículo?