Seguridad

Almacenamiento de contraseñas

Las contraseñas se almacenan con hash bcrypt (cost factor 12). Las contraseñas en texto plano nunca se almacenan, ni siquiera temporalmente en la memoria del servidor — se descartan inmediatamente después del hash. Durante el registro, las contraseñas se verifican contra la API de Have I Been Pwned, y las contraseñas con historial de filtración conocido son rechazadas.

Tokens y sesiones

Los tokens de autenticación son JWT firmados con el algoritmo HS256. En producción, se requiere un secreto JWT de al menos 32 caracteres — el servidor no iniciará sin él.

Los tokens de actualización se almacenan con hash bcrypt (cost factor 10). Se rotan en cada uso — cada actualización emite un nuevo token e invalida el anterior. Los TTL de ambos tokens son configurables por proyecto.

Las sesiones se gestionan en el servidor con dirección IP, user agent y marca de tiempo de última actividad. Los usuarios pueden ver las sesiones activas y revocar sesiones individuales o todas desde el panel de control.

Autenticación multifactor

Se soporta autenticación multifactor basada en TOTP. Los secretos TOTP se cifran con AES antes del almacenamiento. Se generan 10 códigos de respaldo por usuario, cada uno con hash HMAC-SHA256. La verificación de códigos de respaldo utiliza comparación en tiempo constante para prevenir ataques de temporizado.

OAuth e inicio de sesión social

Los parámetros de estado OAuth se generan usando crypto.randomBytes(32) para prevenir ataques CSRF. Se soportan 20 proveedores OAuth, y las URL de callback están restringidas por proyecto.

Passkeys (WebAuthn)

La autenticación con passkeys se basa en el estándar FIDO2/WebAuthn. La verificación del lado del servidor utiliza la biblioteca SimpleWebAuthn.

Seguridad de red

Toda la comunicación se cifra mediante TLS. HSTS (HTTP Strict Transport Security) se aplica con un max-age de 1 año.

CORS se configura con una lista blanca dinámica que solo permite dominios registrados en cada proyecto. No se utilizan orígenes comodín.

El servidor API utiliza el middleware Helmet para configurar encabezados de seguridad incluyendo Content-Security-Policy, X-Frame-Options (DENY) y X-Content-Type-Options (nosniff).

Protección contra fuerza bruta

Se registran los intentos fallidos de inicio de sesión por usuario. Por defecto, las cuentas se bloquean durante 300 segundos (5 minutos) después de 5 intentos fallidos. Estos umbrales son configurables en la configuración de seguridad de cada proyecto. El inicio de sesión exitoso restablece el contador de fallos.

Se puede habilitar Cloudflare Turnstile CAPTCHA por proyecto, añadiendo desafíos de protección contra bots en los flujos de registro e inicio de sesión.

Validación de entrada

Todas las entradas de la API se validan usando class-validator. Los campos no reconocidos se eliminan automáticamente (modo whitelist), y las solicitudes con campos prohibidos explícitamente son rechazadas. Las contraseñas requieren un mínimo de 8 caracteres. Las consultas a la base de datos utilizan consultas parametrizadas de TypeORM para prevenir inyección SQL.

Seguridad de Webhooks

A cada endpoint de webhook se le asigna un secreto de firma único en su creación. Los payloads de webhook se firman con HMAC-SHA256, entregados con una marca de tiempo en el encabezado X-Authon-Signature. Los envíos fallidos se reintentan automáticamente hasta 3 veces.

Reportar vulnerabilidades

Si descubre una vulnerabilidad de seguridad, por favor repórtela a security@authon.dev. No abra un issue público — contáctenos directamente por correo electrónico.