Conçu pour l'ère quantique
UniAuth est conçu de A à Z avec la sécurité comme valeur par défaut — pas ajoutée après coup. Chaque hachage, chaque jeton, chaque session est protégé par une cryptographie qui résiste aux attaques d'aujourd'hui comme de demain.
Fondations cryptographiques
Chiffrement au repos AES-256-GCM
Chaque valeur sensible — secrets TOTP, jetons d'accès OAuth, clés privées PQC, mots de passe de liaison LDAP — est chiffrée avec AES-256-GCM avant de toucher la base de données. Format : iv:tag:ciphertext.
La clé de chiffrement est un secret 256 bits distinct (ENCRYPTION_KEY), non dérivé du secret JWT. La rotation de l'un ne compromet pas l'autre.
Signatures de session ML-DSA-44
Chaque session porte une signature numérique post-quantique (FIPS 204 ML-DSA-44, anciennement CRYSTALS-Dilithium). À chaque requête, touchSession() vérifie la signature ; toute divergence révoque immédiatement la session et journalise l'événement.
Même si une signature classique ECDSA ou RSA était cassée par un ordinateur quantique, les sessions ML-DSA restent sûres.
Hachage de mot de passe Argon2id
Les nouveaux mots de passe utilisent Argon2id (recommandé par l'OWASP : 64 Mo de mémoire, 3 itérations, 4 de parallélisme). Les anciens hachages bcrypt sont migrés de façon transparente à la connexion. La robustesse du mot de passe est évaluée avec zxcvbn (score ≥ 2 requis) et vérifiée via l'API k-anonymity de HaveIBeenPwned.
Identifiants de sujet par paire
Les applications connectées ne voient jamais votre véritable UUID. Chaque application reçoit un identifiant unique, déterministe et spécifique à l'application : HMAC-SHA256(userId:clientId, secret). Les applications ne peuvent pas corréler les utilisateurs entre les services — votre confidentialité est structurelle, pas une simple politique.
Protection à l'exécution
Détection adaptative des menaces
Évaluation statistique du risque de connexion sur 6 facteurs : nouvelle IP, nouveau user-agent, heure inhabituelle, rafale de tentatives échouées, anomalie géographique et confiance de l'appareil. Les connexions à haut risque déclenchent automatiquement une 2FA renforcée ou un CAPTCHA.
Verrouillage progressif du compte
5 échecs = 1 min, 10 = 5 min, 15 = 15 min, 20+ = 1 heure. Renvoie un 401 générique (pas d'énumération de compte). Réinitialisé après une authentification réussie. Le verrouillage s'applique aussi bien aux flux par mot de passe, passkey et lien magique.
Cycle de vie des sessions
Délai d'inactivité de 24 heures + durée de vie absolue de 30 jours. Une empreinte SHA-256 (IP + UA) est vérifiée à chaque requête : un changement de client met fin à la session, tandis qu'un simple changement de réseau sur le même client la relie à nouveau. 10 sessions simultanées maximum par utilisateur, la plus ancienne étant évincée.
Sorties protégées contre le SSRF
Chaque requête HTTP sortante (webhooks, découverte OIDC, déconnexion backchannel) passe par safeFetch — résolu par DNS, épinglé à l'adresse IP validée. Le rebinding DNS entre la vérification et la connexion du socket est impossible.
CORS + CSP + limitation de débit
CORS strictement de même origine sur toutes les routes d'API. CSP avec frame-ancestors 'none'. Limitation de débit à double couche (en mémoire + fenêtre glissante Redis). Seuils par route ajustés au profil de risque de chaque point de terminaison.
Tout en temps constant
Chaque comparaison de hachage, vérification de jeton, contrôle de code de secours et recherche de jeton SCIM utilise crypto.timingSafeEqual. Aucun canal auxiliaire temporel, nulle part.
Conformité et audit
Chaque action est journalisée, chaque chaîne est vérifiée, chaque export est expurgé.