Factores de autenticación: las cinco categorías

Por qué dedicar un artículo entero a los factores

Los factores son lo que el sujeto presenta para demostrar que es él. Pueden ser tan triviales como una contraseña memorizada o tan sofisticados como una llave criptográfica firmada por hardware seguro. Cada uno tiene fortalezas, debilidades, costos y casos de uso ideales. Si solo conoces “contraseña + OTP por SMS”, estás en el siglo XXI a medias — entre 2010 y 2026 emergió todo un universo de factores nuevos (passkeys, biometría con liveness, contextual, behavioral) que cambian las reglas del juego.

En este artículo recorremos las cinco categorías de factores, sus implementaciones más comunes con sus pros y contras, la nomenclatura SFA/2FA/MFA que mucha gente usa mal, el concepto de step-up authentication y la autenticación adaptativa basada en riesgo. Al final tendrás criterio para decir, en cualquier diseño que veas: “esto es robusto” o “esto es teatro de seguridad”.

Las cinco categorías de factores

Tradicionalmente la industria habla de tres categorías clásicas (“algo que sabes / tienes / eres”) y dos categorías modernas que ganaron peso en la última década (“algo que haces” y el contexto). Vamos a tratarlas como cinco para reflejar la realidad actual:

flowchart TB
  accTitle: Las cinco categorías de factores de autenticación
  accDescr: Flowchart de arriba hacia abajo con la autenticación ramificándose en cinco categorías: algo que sabes (contraseña, PIN), algo que tienes (celular, llave hardware), algo que eres (huella, rostro, iris, voz), algo que haces (tipeo, gestos) y contexto (ubicación, hora, dispositivo).
  AUTH([Autenticación])
  AUTH --> SABES[1. Algo que sabes]
  AUTH --> TIENES[2. Algo que tienes]
  AUTH --> ERES[3. Algo que eres]
  AUTH --> HACES[4. Algo que haces]
  AUTH --> CTX[5. Contexto]
  SABES --> S1[Contraseña, PIN]
  TIENES --> T1[Celular, llave hardware]
  ERES --> E1[Huella, rostro, iris, voz]
  HACES --> H1[Tipeo, gestos]
  CTX --> C1[Ubicación, hora, dispositivo]

Lectura rápida: la autenticación tiene cinco pilares posibles. Una autenticación fuerte combina factores de categorías distintas. Por eso pedir contraseña + PIN no es MFA verdadero — son dos cosas de la misma categoría. Veámosla una por una.

Tabla resumen de las cinco categorías

#	Categoría	Ejemplos	Fortaleza relativa
1	Algo que sabes	Contraseña, PIN, frase, preguntas de seguridad	Baja a media
2	Algo que tienes	Smartphone, llave hardware (YubiKey), smart card, certificado	Media a alta
3	Algo que eres	Huella, rostro, iris, voz	Alta (con liveness)
4	Algo que haces	Patrón de tipeo, gestos, movimientos	Auxiliar (no único factor)
5	Contexto	Geo, hora, dispositivo conocido, comportamiento	Auxiliar (modulador de riesgo)

Categoría 1: Algo que sabes

Contraseñas

La contraseña sigue siendo el factor más usado del mundo. También es el más débil. Un humano promedio reusa contraseñas, las apunta, las elige predecibles, y las olvida. Décadas de investigación muestran que casi todas las propiedades deseables de una contraseña pelean con la usabilidad: si es lo suficientemente compleja para ser segura, es difícil de recordar; si es fácil de recordar, es vulnerable.

Buenas prácticas modernas (basadas en NIST SP 800-63B):

• Longitud sobre complejidad: 12+ caracteres es más útil que reglas de “1 mayúscula + 1 número + 1 símbolo”.
• Verificar contra listas de contraseñas filtradas: rechazar passwords conocidas (Have I Been Pwned tiene una API gratuita).
• No forzar rotaciones periódicas sin razón: forzar cambio cada 90 días empeora la seguridad porque la gente termina con Pasaporte01!, Pasaporte02!, etc.
• Almacenar siempre con hashing fuerte: bcrypt, Argon2, scrypt — nunca MD5 ni SHA-256 plano.
• Hash sin salt es indefensible; con salt + algoritmo adecuado, mucho mejor.

PINs

Los PINs son un caso especial de contraseña, típicamente numéricos y cortos (4-6 dígitos). Aunque parezcan débiles por su corto espacio (10,000 a 1 millón de combinaciones), son aceptables cuando:

• Se combinan con otro factor (no son factor único).
• Hay rate limiting estricto (máximo N intentos antes de bloquear).
• Están vinculados a un dispositivo concreto (el PIN del iPhone solo sirve en ese iPhone).

Preguntas de seguridad: el anti-patrón clásico

“¿Cuál fue el nombre de tu primera mascota?” “¿En qué calle creciste?” Estas preguntas eran populares en los 2000s y son hoy una de las prácticas más cuestionadas en seguridad. Las respuestas suelen ser:

• Públicas: si tienes Facebook, probablemente todos pueden saber el nombre de tu mascota.
• Falsificables: el atacante busca tu cuenta de Instagram y tiene la información.
• Compartidas con familia y amigos: no son secretas.

Si todavía ves preguntas de seguridad en un sistema en 2026, es señal de un programa IAM con dos décadas de retraso.

Categoría 2: Algo que tienes

TOTP y HOTP

TOTP (Time-based One-Time Password, RFC 6238) y HOTP (HMAC-based, RFC 4226) son los algoritmos detrás de las apps tipo Google Authenticator, Microsoft Authenticator, Authy. Funcionan así:

• El servidor y el dispositivo del usuario comparten una semilla secreta (cuando se hace el setup inicial, escaneas un QR).
• Ambos derivan un código de 6 dígitos cada 30 segundos a partir de esa semilla + la hora actual (TOTP) o un contador (HOTP).
• El usuario escribe ese código; el servidor lo recalcula y compara.

Pros: trabaja offline, no necesita SMS, es gratuito, está estandarizado. Contras: el usuario tiene que copiar 6 dígitos en 30 segundos, susceptible a phishing en tiempo real (man-in-the-middle).

OTP por SMS

Recibir un código por mensaje de texto. Cómodo y muy adoptado, pero técnicamente débil:

• SIM swapping: un atacante convence a la operadora de portar tu número a su SIM. Toma minutos.
• Vulnerabilidades del protocolo SS7 que permiten interceptar mensajes.
• Phishing en tiempo real: el atacante captura el OTP y lo replay en segundos.

NIST SP 800-63B desaconseja SMS OTP para AAL2 (autenticación de nivel medio) desde 2017. Si lo usas todavía, asume que es la cuerda más débil de tu cadena.

OTP por email

Similar al SMS pero por correo. Es solo tan seguro como el correo, lo que en la práctica significa: depende de cuán bien protegida esté la cuenta de email. Si esa cuenta está protegida solo con una contraseña, el “OTP por email” es básicamente un factor único disfrazado.

Push notifications

El usuario recibe una notificación en su app (Microsoft Authenticator, Duo, Okta Verify) y aprueba con un toque. Más cómodo que TOTP. Pero introdujo un nuevo riesgo: MFA bombing o push fatigue.

El atacante, con la contraseña ya robada, dispara repetidamente push notifications a la víctima. La víctima, harta o medio dormida, eventualmente aprueba una. Caso real famoso: el breach de Uber en 2022.

Las plataformas modernas mitigan esto con number matching: en lugar de solo aprobar/rechazar, el push muestra un número que el usuario debe escribir en la app de origen. Eso elimina la aprobación automática.

Llaves hardware (FIDO2 / WebAuthn)

Una llave hardware (YubiKey, Google Titan) genera un par de claves criptográficas: la privada nunca abandona el dispositivo; la pública se registra en el servidor. Para autenticarte, el servidor envía un challenge, la llave lo firma con la clave privada, el servidor verifica con la pública.

Pros decisivos:

• Phishing-resistant por diseño: la firma incluye el origen (URL del sitio); si te roban a un sitio falso, la firma no es válida.
• Sin secreto compartido: una filtración del servidor no expone tu credencial.
• Resistente a man-in-the-middle.

Contras:

• Costo (la llave cuesta $25-$50).
• Si se pierde, recovery requiere otro factor.
• UX más friccionada que push notifications.

Smart cards y certificados X.509

Tarjetas que contienen un chip con clave privada. Comunes en gobiernos (DUI digital, DNIe en España, CAC en el ejército de EE. UU.) y empresas con requisitos de cumplimiento alto. Funcionan como las llaves FIDO2 pero con un factor de forma distinto.

Passkeys: el sucesor moderno

Passkey es la versión sincronizada de WebAuthn. La clave privada vive en el llavero del sistema operativo (iCloud Keychain, Google Password Manager, Windows Hello) y se sincroniza entre dispositivos del mismo usuario.

Combina lo mejor de varios mundos:

• Phishing-resistant (como FIDO2).
• Sin contraseñas (passwordless real).
• UX simple: “desbloquea con tu cara o huella” en lugar de “escribe esta cadena”.
• Funciona entre dispositivos: si tienes iPhone + Mac, el passkey funciona en ambos.

Apple, Google y Microsoft empujaron passkeys masivamente entre 2022 y 2024. Es por mucho la mejor opción de factor “tienes” para usuarios finales en 2026.

Categoría 3: Algo que eres (biometría)

Huella digital

El más maduro y barato. Touch ID en iPhone, sensores en laptops corporativas. La huella se almacena como un template matemático (no la imagen real) y, en dispositivos modernos, dentro del Secure Enclave del chip — inaccesible incluso al sistema operativo.

Limitaciones:

• Si tienes la mano húmeda o sucia, falla.
• Cierta gente no genera buenas huellas (oficios manuales, edad).
• Una huella levantada con un molde de silicona puede engañar sensores baratos.

Reconocimiento facial

Face ID en iPhone, Windows Hello, controles de acceso modernos. Mide la geometría 3D del rostro, no solo una foto.

Importante: hay dos categorías muy distintas que se confunden:

• Facial 2D simple (lo que usa una webcam barata): vulnerable a fotos impresas y videos.
• Facial 3D con liveness (Face ID, Windows Hello): mide profundidad, infrarrojo, micro-movimientos. Mucho más robusto.

Iris, voz, vena, escritura

• Iris: muy preciso, usado en aeropuertos. Requiere hardware especializado.
• Voz: “di tu frase”. Vulnerable a deepfakes y grabaciones — en 2024 ya hay casos documentados de fraude bancario por voz clonada con IA.
• Vena de la palma: usado en Japón, alta precisión. Hardware caro.
• Escritura/firma dinámica: rara fuera de bancos asiáticos.

Métricas que importan en biometría

Métrica	Qué mide
FAR (False Accept Rate)	% de usuarios incorrectos que el sistema acepta. Cuanto más bajo, mejor.
FRR (False Reject Rate)	% de usuarios correctos que el sistema rechaza. Cuanto más bajo, mejor.
EER (Equal Error Rate)	El punto donde FAR = FRR. Métrica única para comparar sistemas.
Liveness detection	Detecta si lo que se presenta es vivo (no una foto, video, máscara).
Anti-spoofing	Conjunto de técnicas para detectar intentos de engaño.

Privacidad y biometría

La biometría tiene una propiedad que la diferencia: no se puede revocar. Si te filtran tu contraseña, la cambias. Si te filtran tu huella, la huella ya es la huella — no la cambias en la próxima vida.

Por eso una buena implementación nunca almacena imágenes de huella o rostro. Almacena templates matemáticos derivados que (idealmente) no permiten reconstruir la imagen original. Y nunca los almacena en una base de datos central que podría ser comprometida — los almacena en hardware seguro del dispositivo del usuario.

Regulaciones específicas:

• BIPA (Illinois Biometric Information Privacy Act): obliga a notificar y obtener consentimiento explícito.
• GDPR Art. 9: trata biometría como dato sensible especial; alta protección requerida.
• LFPDPPP (México): incluye biometría en su categoría de datos sensibles.

Categoría 4: Algo que haces (biometría comportamental)

Esta es la categoría más reciente y todavía se trata como factor auxiliar, no como factor único. Mide patrones únicos en cómo te comportas:

• Patrón de tipeo (keystroke dynamics): tu ritmo, pausas y errores típicos al teclear.
• Movimiento del mouse: cómo lo desplazas, dónde clickeas, qué ruta sigues.
• Gestos en pantalla táctil: presión, velocidad de swipe, ángulo del dedo.
• Patrón de uso de la app: qué pantallas visitas, en qué orden, a qué hora.

Características:

• Funciona en silencio, sin pedirle nada al usuario explícitamente.
• Se va aprendiendo durante semanas o meses para crear un perfil personal.
• Útil contra ATO (account takeover): detecta cuando “alguien que escribe diferente” entra a la cuenta.

Vendors: BioCatch, NuData (Mastercard), TypingDNA. Mucho usado en banca por su fricción cero.

Categoría 5: Contexto

Estrictamente no es algo que el usuario “presente” como prueba — es información que el sistema observa sobre el entorno de la solicitud. Pero juega el mismo rol: subir o bajar la confianza.

Señal contextual	Qué dice del riesgo
Geolocalización IP	Login desde país nuevo = riesgo alto
Hora del día	Login a las 3 AM si nunca lo haces = sospechoso
Device fingerprint	Combinación única de datos del dispositivo (modelo, OS, fuentes, plugins, resolución)
ASN / ISP	Si la IP viene de una VPN o de Tor, sube el riesgo
Velocidad imposible	Login desde Madrid a las 14:00 y desde Tokio a las 14:05 = imposible
Dispositivo conocido	Si nunca habías usado este dispositivo, riesgo más alto

El contexto rara vez se usa como factor único. Su valor está en modular la decisión: pasar tu chequeo desde tu casa con tu laptop habitual debe ser fácil; pasar tu chequeo desde un país nuevo en un dispositivo nuevo debe pedir factores adicionales.

SFA, 2FA, MFA: la nomenclatura

Mucha gente usa estos términos sin precisión. Vamos a fijarlos:

Single-Factor Authentication (SFA)

Solo se presenta un factor. Típicamente la contraseña sola. Es el modelo más débil y debería estar fuera de cualquier app moderna seria. Casos donde sigue apareciendo: apps internas legacy, sistemas de baja sensibilidad.

Two-Factor Authentication (2FA)

Exactamente dos factores de categorías distintas. Ejemplos válidos:

• Contraseña (sabes) + OTP en app (tienes).
• Contraseña (sabes) + huella (eres).
• Llave hardware (tienes) + PIN (sabes).

Ejemplos inválidos (no son verdadero 2FA):

• Contraseña + PIN (ambos “sabes”).
• Dos huellas distintas (ambas “eres”).
• Contraseña + preguntas de seguridad (ambas “sabes”).

Multi-Factor Authentication (MFA)

Dos o más factores de categorías distintas. Es un superset de 2FA. La diferencia entre 2FA y MFA en la práctica es semántica: 2FA es exactamente dos, MFA es dos o más.

flowchart LR
  accTitle: SFA, 2FA y MFA mapeados a su fortaleza relativa
  accDescr: Flowchart de izquierda a derecha con tres ramas: single-factor authentication mapea a débil, two-factor authentication con dos factores distintos mapea a media, y multi-factor authentication con dos o más factores distintos mapea a fuerte.
  SFA[SFA - 1 factor] --> WEAK[Débil]
  TWOFA[2FA - 2 factores distintos] --> MED[Media]
  MFA[MFA - 2 o más factores distintos] --> STRONG[Fuerte]

Step-up authentication

Step-up es pedir un factor adicional al medio de una sesión, cuando el usuario va a hacer algo más sensible que su login original justificaba.

Ejemplos:

• Logueado para ver tu saldo: contraseña + push.
• Para hacer una transferencia mayor a $1,000: pedir PIN adicional.
• Para cambiar el email asociado a la cuenta: pedir biometría.

El step-up es la implementación práctica de “cuanto mayor el riesgo, mayor la autenticación”. No tiene sentido pedir todos los factores siempre — eso destruye UX. Pero sí tiene sentido pedirlos justo cuando importa.

Autenticación adaptativa basada en riesgo (RBA)

RBA es la evolución natural del step-up: en lugar de reglas fijas (“transferencias > $1,000 piden PIN”), el sistema calcula un score de riesgo en tiempo real y decide automáticamente cuánta fricción agregar.

Cómo funciona

flowchart TB
  accTitle: Flujo de decisión de autenticación adaptativa basada en riesgo
  accDescr: Flowchart de arriba hacia abajo que arranca de una solicitud de login, recolecta señales de contexto, comportamiento y factor inicial, alimenta un motor de riesgo que computa un score de 0 a 100, y ramifica en cuatro resultados según el score: bajo permite acceso sin fricción, medio pide un segundo factor, alto pide MFA más step-up y alerta al SOC, y crítico bloquea y exige reset manual.
  REQ[Solicitud de login] --> RECOLECTA[Recolecta señales]
  RECOLECTA --> SCORE[Motor de riesgo computa score 0-100]
  SCORE --> DEC{Nivel de score}
  DEC -->|Bajo| OK[Acceso sin fricción]
  DEC -->|Medio| MFA[Pide segundo factor]
  DEC -->|Alto| STEP[MFA + step-up, alerta SOC]
  DEC -->|Crítico| BLOCK[Bloquea, requiere reset manual]

Lectura: cada solicitud de login dispara una evaluación. El motor recolecta señales (de dónde viene, qué dispositivo es, a qué hora, qué patrón de tipeo presenta, qué credenciales mostró) y calcula un score. Según el score, escala progresivamente: deja pasar fluido, pide MFA, pide step-up, o bloquea de plano.

Señales típicas que alimentan el score

• Identitarias: ¿la cuenta es nueva? ¿hace cuánto fue creada? ¿tiene historial limpio?
• Contextuales: IP, geolocalización, dispositivo, hora, ISP/ASN.
• Comportamentales: tipeo, movimiento, navegación, ritmo.
• Anomalías: ¿es la primera vez que viene de este país? ¿velocidad imposible vs login anterior?
• Inteligencia externa: ¿la IP está en listas negras? ¿el dispositivo está reportado como comprometido?
• Contraataques en curso: ¿hay credential stuffing masivo en otras cuentas en este momento?

Ejemplo concreto: María al banco

María entra a su app de banco un viernes a las 8 PM desde su iPhone habitual, en su barrio de siempre, con su patrón de tipeo conocido. Score: bajo. La app le pide solo huella. Entra en 2 segundos.

El sábado siguiente, intenta entrar desde una computadora que el sistema nunca había visto, en un café de otra ciudad, con un patrón de tipeo ligeramente distinto (porque está usando teclado en lugar de su iPhone). Score: medio-alto. La app le pide contraseña + push notification a su iPhone + responder un challenge sobre su última transacción.

Si todavía intentara una transferencia inmediata después de ese login: score se eleva más, y el sistema le pide step-up adicional (PIN transaccional) o le bloquea la transferencia hasta confirmación por canal alterno.

María como usuaria legítima pasa todos los chequeos en segundos extra. Un atacante con su contraseña pero sin su iPhone, sin su patrón, sin su contexto — falla en alguno de los chequeos.

Vendors típicos para RBA

Vendor	Producto	Notas
Microsoft	Entra ID Conditional Access	Integrado al stack Microsoft
Okta	Adaptive MFA	Parte de Workforce Identity Cloud
BioCatch	Behavioral analytics	Especializado en patrones
Transmit Security	Detection and Response	Foco en passwordless + RBA
RSA	RSA Risk-Based Authentication	Veterano del segmento

Fuentes para tracking del mercado RBA: Gartner Peer Insights — Access Management (RBA es feature dentro de plataformas AM modernas), KuppingerCole Leadership Compass: Adaptive Authentication.

NIST AAL: niveles de aseguramiento

Para cerrar, vale conectar todo esto con un estándar formal. NIST SP 800-63B define Authenticator Assurance Levels (AAL) que mapean factores con niveles de seguridad:

AAL	Requisitos	Ejemplos válidos
AAL1	Mínimo: SFA aceptable	Solo contraseña
AAL2	MFA requerido (dos categorías distintas)	Contraseña + push, contraseña + TOTP, passkey
AAL3	MFA con factor criptográfico phishing-resistant + hardware	FIDO2 con llave hardware + PIN

Si te toca diseñar el nivel de autenticación de un sistema, esta tabla es la referencia: banca regular suele requerir AAL2; gobierno y banca de alto valor pueden requerir AAL3.

Recapitulación

Las cinco categorías de factores son el vocabulario operativo de cualquier conversación seria sobre autenticación:

1. Algo que sabes (contraseñas, PINs) — el más común y el más débil.
2. Algo que tienes (TOTP, push, FIDO2, passkeys) — robusto si está bien implementado.
3. Algo que eres (biometría) — fuerte con liveness, irrevocable si se filtra.
4. Algo que haces (comportamental) — auxiliar, valioso por ser silencioso.
5. Contexto — modulador de riesgo, no factor en sí.

La nomenclatura SFA / 2FA / MFA se reduce a la regla central: para que cuente como MFA verdadero, los factores deben ser de categorías distintas. Y los conceptos de step-up y RBA son las técnicas modernas para evitar el dilema clásico “fricción vs seguridad” — solo pedir lo necesario, cuando es necesario, según el riesgo real del momento.

Tres preguntas para autoevaluarte

1. Una app permite “doble autenticación” pidiendo contraseña + un PIN de 4 dígitos. ¿Es 2FA real? Justifica.
2. Diseña la lógica de step-up para una app de inversiones: define al menos cuatro acciones distintas y qué nivel de autenticación pedirías para cada una.
3. Tu CFO te dice “implementemos RBA con un score de 0 a 100 y bloqueemos cualquier login arriba de 60”. ¿Qué tres advertencias le darías sobre esa implementación simplista?