1. Autenticadores de posesión

El factor de posesión comprueba que el usuario tiene un objeto, físico o digital, que solo él debería poseer. Su ventaja frente al conocimiento es que el atacante no puede adivinarlo desde cualquier lugar del mundo: debe robar, clonar o engañar para obtener el objeto o el secreto que contiene.

No todos los autenticadores de posesión ofrecen la misma seguridad. La diferencia fundamental es si resisten el phishing, es decir, si siguen siendo útiles cuando el usuario es engañado para entregar lo que el objeto produce.

Autenticador Qué es Resistente al phishing Ejemplo

Lista de códigos de un solo uso

Códigos precalculados que se tachan al usarse

No

Códigos de recuperación

OTP por software

Aplicación que calcula códigos con un secreto compartido

No

Aplicaciones TOTP

OTP por hardware

Dispositivo dedicado que genera códigos

No

Llaves con generador de códigos

SMS, voz o correo

Código enviado por un canal de comunicación

No

Mensaje de texto

Notificación push

Solicitud de aprobación en el teléfono

No, y expuesta a la fatiga

Aprobar o denegar

Llave de seguridad FIDO2

Dispositivo con clave privada y verificación del origen

Sí

Llaves USB y NFC

Tarjeta inteligente

Chip con clave privada y certificado, protegido por PIN

Sí, cuando valida el servidor

DNI electrónico

Un segundo factor no es automáticamente un buen segundo factor

Un código de seis dígitos, venga de una aplicación, de un mensaje o de una llave, se puede teclear en una web falsa y reenviar al servicio real en el mismo instante. Solo los autenticadores criptográficos que comprueban el origen, como FIDO2 y las tarjetas inteligentes con autenticación mutua, resisten esa técnica. La clasificación de los niveles de garantía se estudia en el capítulo de autenticación multifactor.

2. Contraseñas de un solo uso: HOTP y TOTP

Una contraseña de un solo uso u OTP (One-Time Password) es un código que sirve para una única autenticación. Aunque se intercepte, no puede reutilizarse más tarde. Los dos algoritmos estandarizados parten de un secreto compartido entre el servidor y el dispositivo del usuario.

2.1. HOTP: basado en un contador

Definido en el RFC 4226, calcula el código a partir del secreto K y de un contador C que ambos lados incrementan en cada uso:

HOTP(K, C) = Truncar(HMAC-SHA1(K, C)) mod 10^dígitos

  • El truncado dinámico toma cuatro bytes del resultado del HMAC, elegidos según el último medio byte, y los reduce a un número de seis u ocho dígitos.

  • Si el usuario genera códigos sin enviarlos, el contador del dispositivo se adelanta al del servidor. Por eso el servidor acepta una ventana de contadores futuros y se resincroniza al validar uno.

2.2. TOTP: basado en el tiempo

Definido en el RFC 6238, sustituye el contador por el tiempo discreto: el número de intervalos de 30 segundos transcurridos desde el 1 de enero de 1970.

T = floor(hora_unix / 30)
TOTP(K) = HOTP(K, T)

Como el código depende solo del secreto y del reloj, no hace falta comunicación entre el dispositivo y el servidor. Es el algoritmo de la mayoría de las aplicaciones de autenticación.

Funcionamiento de TOTP
Figura 1. Funcionamiento de TOTP

2.3. Alta del dispositivo

El secreto se comparte una sola vez, durante el alta, normalmente mediante un código QR que contiene un identificador de recurso con los parámetros del algoritmo:

otpauth://totp/Bastionado:maria?secret=JBSWY3DPEHPK3PXP&issuer=Bastionado&algorithm=SHA1&digits=6&period=30
Campo Descripción Ejemplo Explicación técnica

secret

Secreto compartido, codificado en Base32

JBSWY3DPEHPK3PXP

Es la clave K del HMAC. Quien lo obtenga puede generar todos los códigos del usuario.

issuer

Servicio que emite el código

Bastionado

Solo sirve para identificar la entrada en la aplicación.

algorithm

Función hash del HMAC

SHA1

SHA-1 sigue siendo seguro en HMAC y es el único que admiten todas las aplicaciones.

digits

Longitud del código

6

Con seis dígitos hay un millón de combinaciones por intervalo.

period

Duración del intervalo en segundos

30

Define el tamaño de T y la ventana de validez de cada código.

2.4. Seguridad y límites

  • El servidor guarda el secreto. El servidor debe poder calcular los códigos, por lo que almacena el secreto en forma recuperable. Una brecha de esa base de datos compromete el segundo factor de todos los usuarios, y debe cifrarse con una clave gestionada aparte.

  • Ventana de aceptación. Para tolerar la deriva de relojes, el servidor acepta el intervalo actual y el anterior y el siguiente. Ampliar la ventana aumenta la comodidad y las posibilidades de acierto del atacante.

  • Limitación de intentos. Con seis dígitos y tres intervalos válidos, un atacante acierta con una probabilidad de tres entre un millón en cada intento. Sin un límite de fallos por cuenta, el segundo factor se puede forzar.

  • Un código, un solo uso. El servidor debe rechazar un código ya empleado dentro de su ventana, o un atacante podría reutilizar uno interceptado durante 30 segundos.

  • Relojes sincronizados. Los servidores deben usar NTP. Un desfase de más de un intervalo impide validar a los usuarios legítimos.

  • No es resistente al phishing. Un atacante intermediario retransmite el código en cuanto el usuario lo teclea.

Con los conceptos explicados en esta sección, ya puede realizar el Ejercicio 1. TOTP desde cero y el Ejercicio 2. Deriva del reloj y ventana de aceptación.

3. Tokens de hardware y llaves de seguridad

Los tokens de hardware son dispositivos dedicados, sin conexión a Internet ni capacidad de instalar software ajeno, que reducen la superficie de ataque frente a un teléfono.

  • Generadores de OTP del estilo de RSA SecurID: un reloj interno y un secreto grabado de fábrica producen un código que cambia cada pocos segundos. Sufren los mismos límites que TOTP y, además, el fabricante o el servidor conocen la semilla.

  • Llaves de seguridad FIDO, como las YubiKey y otras llaves USB o NFC: guardan claves privadas que nunca salen del dispositivo y comprueban el origen del sitio web. Son los autenticadores con mejor equilibrio entre seguridad y comodidad, y se estudian en el capítulo de autenticación criptográfica.

El ciclo de vida de estos dispositivos exige un procedimiento: inventario de los entregados, registro de cada uno a su usuario, revocación inmediata ante pérdida o robo, y una segunda llave de reserva registrada para evitar bloqueos y recuperaciones inseguras.

4. SMS, voz, correo y notificaciones push

Estos métodos son cómodos y no requieren hardware, pero asumen la seguridad de un canal que el servicio no controla.

Método Riesgo principal Mitigación Uso recomendado

SMS y voz

SIM swapping, redirección en la red de señalización, malware que lee mensajes

Comprobar indicios de cambio de SIM o portabilidad; ofrecer alternativas

Último recurso, con aviso al usuario

Correo electrónico

Quien controla el buzón controla el código; el buzón suele protegerse peor

No utilizarlo como segundo factor

Prohibido por NIST como autenticador fuera de banda

Notificación push

Fatiga de MFA: el atacante genera solicitudes hasta que el usuario acepta

Mostrar el contexto y exigir un número de verificación

Aceptable con coincidencia de número

Lista de códigos de recuperación

Se almacena en claro o se pierde

Guardar en un gestor o en papel bajo custodia

Solo para recuperación

El SIM swapping consiste en convencer a un operador de que transfiera el número de la víctima a una tarjeta SIM que controla el atacante, que a partir de entonces recibe los SMS de verificación y las llamadas de recuperación. NIST califica la autenticación por la red telefónica pública como autenticador restringido: lo admite, pero exige que el servicio ofrezca alternativas y que valore indicadores de riesgo como un cambio reciente de SIM.

El correo merece una advertencia aparte, porque no es un canal más. El buzón es la raíz de la cadena de recuperación, ya que a él llegan los enlaces con los que se restablece la contraseña del resto de servicios. Quien lo controla no necesita robar ninguna otra credencial, le basta con solicitar el restablecimiento de cada cuenta una por una. De ahí se siguen dos consecuencias. La cuenta de correo debe ser la mejor protegida de todas, con un autenticador resistente al phishing. Y usar ese mismo correo como segundo factor de otros servicios cierra un círculo en el que un único compromiso basta para perderlo todo.

Las notificaciones push y la fatiga de autenticación se analizan en el capítulo de autenticación multifactor.

5. Tarjetas inteligentes y certificados digitales

5.1. Qué es una tarjeta inteligente

Una tarjeta inteligente (smart card) es un dispositivo con un chip que incorpora un procesador, memoria protegida y un módulo criptográfico. Su propiedad fundamental es que genera y guarda claves privadas que no pueden extraerse: cuando hay que firmar algo, los datos entran en la tarjeta, la operación se realiza dentro del chip y solo sale el resultado.

  • Interfaces: contacto, mediante un lector, o sin contacto, mediante NFC.

  • Normas: ISO/IEC 7816 para las tarjetas de contacto, PKCS#11 como interfaz de programación para acceder a sus operaciones criptográficas, y PIV, definido por NIST, como perfil para la identidad de empleados públicos.

  • PIN y PUK: el PIN desbloquea el uso de la clave. Tras un número reducido de intentos fallidos, la tarjeta se bloquea y solo se recupera con un código de desbloqueo, el PUK, que custodia el administrador.

Es, a la vez, un factor de posesión y, por el PIN, de conocimiento: una tarjeta con PIN es una autenticación de dos factores en un único acto.

5.2. Autenticación con certificado

La tarjeta contiene un certificado X.509 que asocia la clave pública con la identidad de su titular, firmado por una autoridad de certificación. La autenticación sigue un esquema de reto y respuesta:

  1. El servidor envía un reto aleatorio, de un solo uso.

  2. El usuario introduce el PIN y la tarjeta firma el reto con la clave privada.

  3. El servidor verifica la firma con la clave pública del certificado.

  4. El servidor valida el certificado: que lo ha emitido una autoridad de confianza, que está dentro de su periodo de validez, que no ha sido revocado mediante listas CRL o el protocolo OCSP, y que su uso extendido incluye la autenticación de cliente.

Ninguna credencial secreta viaja por la red: el servidor solo ve una firma, válida únicamente para ese reto.

5.3. El DNI electrónico y los certificados cualificados

El DNI electrónico español incorpora un chip con un certificado de autenticación y otro de firma electrónica, protegidos por un PIN, y puede utilizarse con lector de contactos o, en las versiones recientes, mediante NFC. El certificado de firma tiene el valor jurídico de una firma manuscrita en el marco del reglamento europeo eIDAS. Existen alternativas con el mismo fundamento, como los certificados de la FNMT y los sistemas de identificación de las administraciones públicas. Las características técnicas vigentes deben consultarse en el portal oficial del DNI electrónico.

5.4. Ventajas y amenazas

  • Ventajas: la clave privada no se exporta ni se copia; no hay secreto compartido que robar de un servidor; y la autenticación mutua con certificados resiste el phishing de credenciales.

  • Robo físico más PIN: quien consiga la tarjeta y observe el PIN tiene acceso completo. De ahí los límites de intentos y la revocación inmediata ante una pérdida.

  • Uso por malware: un programa en el equipo puede pedir firmas a la tarjeta mientras está insertada y desbloqueada, sin llegar a conocer la clave.

  • Validación deficiente: un servidor que no comprueba la revocación, la cadena o el uso de la clave acepta certificados que no debería.

  • Tarjetas débiles: las tarjetas de proximidad de control físico de accesos de generaciones antiguas, como las basadas en MIFARE Classic y en identificadores sin cifrar, se clonan con equipos económicos. No deben confundirse con las tarjetas criptográficas.

La infraestructura que emite y revoca los certificados se estudia con detalle en la guía de infraestructura de clave pública.

Con los conceptos explicados en esta sección, ya puede realizar el Ejercicio 3. Una tarjeta inteligente simulada con SoftHSM.

6. Políticas recomendadas

  1. Elegir el autenticador según el riesgo. Para administradores y accesos remotos a sistemas críticos, exigir autenticadores resistentes al phishing; las aplicaciones OTP bastan como mínimo general; el SMS solo como alternativa de último recurso.

  2. Exigir un procedimiento de alta presencial o verificado para registrar el primer autenticador, ya que es el momento más vulnerable.

  3. Registrar al menos dos autenticadores por usuario, para que la pérdida de uno no obligue a una recuperación débil.

  4. Proteger el secreto de TOTP en el servidor, cifrado y con acceso restringido, y limitar los intentos de validación por cuenta.

  5. Limitar y vigilar las recuperaciones: cada restablecimiento del segundo factor debe notificarse al usuario y quedar registrado.

  6. Revocar de inmediato los autenticadores perdidos, robados o de personas que causan baja.

  7. Mantener relojes sincronizados en todos los servidores que validan códigos temporales.

7. Ejercicios prácticos

Los ejercicios están diseñados para realizarse en orden sobre una máquina virtual Ubuntu o Debian de pruebas. Todos los archivos se crean en ~/lab_posesion. El último ejercicio elimina todo lo creado y no se necesita ningún dispositivo físico.

Nº Ejercicio Competencia que desarrolla

1

TOTP desde cero

Implementar HOTP y TOTP y validarlos con los vectores del RFC

2

Deriva del reloj y ventana de aceptación

Comprender el compromiso entre comodidad y seguridad

3

Una tarjeta inteligente simulada con SoftHSM

Autenticar con reto y respuesta usando una clave no exportable

4

Limpieza del entorno

Revertir los cambios realizados

7.1. Ejercicio 1. TOTP desde cero

Realice los siguientes pasos:

  1. Instale oathtool, herramienta de referencia para generar códigos, y cree el script totp.py, que implementa HOTP y TOTP con la biblioteca estándar de Python:

    sudo apt install -y oathtool
mkdir -p ~/lab_posesion && cd ~/lab_posesion
cat > totp.py << 'EOF'
import base64, hashlib, hmac, struct, time

def hotp(clave: bytes, contador: int, digitos: int = 6, alg=hashlib.sha1) -> str:
    mac = hmac.new(clave, struct.pack(">Q", contador), alg).digest()
    desplazamiento = mac[-1] & 0x0F
    codigo = struct.unpack(">I", mac[desplazamiento:desplazamiento + 4])[0] & 0x7FFFFFFF
    return str(codigo % 10 ** digitos).zfill(digitos)

def totp(clave: bytes, t=None, paso: int = 30, digitos: int = 6, alg=hashlib.sha1) -> str:
    t = time.time() if t is None else t
    return hotp(clave, int(t // paso), digitos, alg)

def verificar(clave: bytes, codigo: str, t=None, ventana: int = 1, paso: int = 30) -> bool:
    t = time.time() if t is None else t
    actual = int(t // paso)
    return any(hmac.compare_digest(hotp(clave, c), codigo) for c in range(actual - ventana, actual + ventana + 1))

if __name__ == "__main__":
    k = b"12345678901234567890"
    for t, esperado in [(59, "94287082"), (1111111109, "07081804"), (1234567890, "89005924")]:
        obtenido = totp(k, t, 30, 8)
        print(t, obtenido, esperado, "OK" if obtenido == esperado else "FALLO")
    print("HOTP contador 0 a 2:", [hotp(k, c) for c in range(3)])
EOF

  2. Ejecute el script y compruebe que los códigos coinciden con los vectores de prueba publicados en los RFC 4226 y 6238, que son 94287082, 07081804 y 89005924 para ocho dígitos, y 755224, 287082 y 359152 para los tres primeros contadores HOTP.

  3. Genere un secreto Base32 y calcule el código para un instante fijo con oathtool y con su script. Compruebe que coinciden.

  4. Construya el identificador otpauth:// de la sección 2.3 con su secreto y genere el código QR con qrencode para registrarlo en una aplicación TOTP real. Compare el código de la aplicación con el de oathtool.

7.2. Ejercicio 2. Deriva del reloj y ventana de aceptación

Realice los siguientes pasos:

  1. Con el módulo totp.py del ejercicio anterior, calcule el código del intervalo actual y valídelo con una ventana de 0 y de 1.

  2. Simule un dispositivo cuyo reloj va retrasado 30, 60 y 90 segundos. Compruebe con qué ventanas valida el servidor cada código y concluya cuál es el desfase máximo tolerado con la ventana habitual.

  3. Calcule la probabilidad de acertar el código de seis dígitos en un solo intento con ventanas de 1, 3 y 5 intervalos, y cuántos intentos haría falta realizar para superar el 50 % de éxito. Justifique la necesidad de limitar los intentos por cuenta.

  4. Verifique que un código ya utilizado no debería aceptarse de nuevo. Diseñe en pseudocódigo, o implemente, el control que el servidor debe añadir a verificar para impedir la reutilización dentro de su ventana.

7.3. Ejercicio 3. Una tarjeta inteligente simulada con SoftHSM

SoftHSM implementa por software la interfaz PKCS#11 de una tarjeta o módulo de seguridad. Permite practicar con una clave no exportable protegida por PIN sin necesidad de ningún lector.

Realice los siguientes pasos:

  1. Instale las herramientas y cree un almacén de pruebas dentro del directorio de trabajo. Inicialice una «tarjeta» con el nombre TarjetaLab, un PIN de usuario 1234 y un PIN de administración 123456.

  2. Genere dentro de la tarjeta un par de claves de curva elíptica con la etiqueta claveAuth. Liste los objetos sin PIN y con PIN, y compruebe los atributos de la clave privada. Identifique qué atributos impiden extraerla.

  3. Simule la autenticación con reto y respuesta. Genere un reto aleatorio, fírmelo con la tarjeta, exporte la clave pública y verifique la firma con openssl, como haría el servidor.

  4. Compruebe que la verificación falla si el reto cambia, y que un PIN incorrecto impide usar la clave. Razone qué le ocurriría a un atacante que obtuviera la clave pública y la firma, pero no la tarjeta.

7.4. Ejercicio 4. Limpieza del entorno

  1. Elimine el directorio de trabajo, que contiene el almacén de la tarjeta simulada, y la variable de entorno definida.

8. Referencias

9. Licencia

Licencia CC BY-NC-ND 4.0

Esta página forma parte del curso Bastionado de Redes y Sistemas © 2026 de José Juan Sánchez Hernández y su contenido se distribuye bajo una licencia Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International.

Esta licencia exige que quienes reutilicen el material otorguen el debido crédito al autor. Permite copiar y redistribuir el material en cualquier medio o formato, únicamente en su forma original, y solo para fines no comerciales.