Authentifier les personnes et les services

Authentifier les personnes et les services

L’authentification est le point où la cryptographie rencontre le monde réel : un humain fatigué devant un formulaire, un service qui doit prouver son identité à un autre service au milieu de la nuit, un employé qui a perdu son téléphone et appelle le support. Les primitives cryptographiques — fonctions de dérivation de clé, signatures asymétriques, protocoles à échange de clés — sont solides depuis longtemps. Ce qui casse, ce sont les coutures : la récupération de compte, la session qui survit trop longtemps, le facteur secondaire qu’un opérateur humain peut désactiver par téléphone. Cette page relie les mécanismes cryptographiques aux parcours d’authentification réels, du mot de passe historique aux passkeys, en passant par Kerberos et les protocoles à mot de passe augmenté.

Explication de la marmotte

Prouver qui on est à un ordinateur, c’est comme montrer une carte à l’entrée d’un club. On peut réciter un mot secret, montrer un objet qu’on est seul à posséder, ou laisser son téléphone confirmer à notre place. Chaque méthode a ses failles : le mot secret s’écoute, l’objet se perd. Le vrai danger est souvent la porte de secours.

→ Lire l’explication complète de la marmotte

Comment fonctionne réellement l’authentification par mot de passe

Un mot de passe est un secret partagé : l’utilisateur le connaît, le serveur doit pouvoir vérifier qu’il le connaît. Le stockage en clair est évidemment exclu, mais le stockage sous forme de hachage simple l’est tout autant : une carte graphique moderne calcule plusieurs dizaines de milliards de SHA-256 (Secure Hash Algorithm 256 bits) par seconde, ce qui réduit un mot de passe humain moyen à quelques minutes de calcul. La réponse est une KDF (Key Derivation Function, fonction de dérivation de clé) délibérément coûteuse : Argon2id, scrypt, ou à défaut bcrypt.

Le paramétrage compte autant que le choix de l’algorithme. Pour Argon2id, l’OWASP (Open Web Application Security Project) recommande un point de départ autour de 19 Mio de mémoire, 2 itérations et un parallélisme de 1 ; augmenter la mémoire est plus efficace contre les attaques matérielles que multiplier les itérations, car la mémoire coûte cher à répliquer sur un circuit dédié. Pour bcrypt, un facteur de coût de 12 ou plus reste acceptable en 2024, mais bcrypt tronque silencieusement l’entrée au-delà de 72 octets — un piège classique quand on préhache le mot de passe avec un encodage hexadécimal.

Le sel, unique par utilisateur et stocké en clair à côté du condensat, empêche la mutualisation des attaques : sans lui, une seule table précalculée casse toute la base. Le poivre (une clé secrète globale ajoutée avant hachage, idéalement conservée dans un HSM — Hardware Security Module, module matériel de sécurité) ajoute une couche : un attaquant qui vole uniquement la base de données ne peut plus tester de candidats hors ligne. En contrepartie, la rotation du poivre impose un rehachage progressif au prochain login, donc un schéma versionné dès le départ.

Il faut ensuite gérer le cycle de vie. Vérifier les mots de passe contre une liste de fuites connues (par exemple via le protocole k-anonymity de Have I Been Pwned, qui n’envoie que les cinq premiers caractères du condensat SHA-1) élimine la majorité du bourrage d’identifiants. Le NIST (National Institute of Standards and Technology) a explicitement abandonné dans sa publication SP 800-63B l’expiration périodique obligatoire : elle pousse à des variations triviales et n’apporte rien face à une compromission réelle.

# Hachage de mot de passe avec Argon2id — paramètres conformes OWASP 2024
from argon2 import PasswordHasher
from argon2.exceptions import VerifyMismatchError, VerificationError

ph = PasswordHasher(
    time_cost=2,        # itérations : coût CPU
    memory_cost=19456,  # 19 Mio : coût mémoire, freine les attaques GPU/ASIC
    parallelism=1,      # threads
    hash_len=32,
    salt_len=16,        # sel unique généré automatiquement, inclus dans la sortie
)

stored = ph.hash("correct horse battery staple")
# $argon2id$v=19$m=19456,t=2,p=1$<sel base64>$<condensat base64>

def verify(stored_hash: str, candidate: str) -> bool:
    try:
        ph.verify(stored_hash, candidate)
    except (VerifyMismatchError, VerificationError):
        return False
    # Rehachage transparent si les paramètres ont durci depuis l'inscription
    if ph.check_needs_rehash(stored_hash):
        persist_new_hash(ph.hash(candidate))
    return True

Pourquoi les passkeys résistent au hameçonnage là où le MFA échoue

Le MFA (Multi-Factor Authentication, authentification multifacteur) classique ajoute un second facteur au mot de passe : un code TOTP (Time-based One-Time Password, mot de passe à usage unique basé sur le temps) généré par une application, une notification poussée, ou — pire option — un SMS (Short Message Service). Le gain est réel contre le bourrage d’identifiants : un mot de passe volé ne suffit plus. Mais aucune de ces méthodes n’est liée au site visité. Un site de hameçonnage qui relaie en temps réel le code TOTP saisi par la victime obtient une session valide en quelques secondes ; des kits comme Evilginx automatisent cela depuis des années.

La fatigue MFA exploite l’autre bout du problème : l’attaquant qui possède déjà le mot de passe déclenche des dizaines de notifications poussées jusqu’à ce que l’utilisateur accepte pour faire cesser le bruit. La compromission d’Uber en 2022 a suivi exactement ce schéma. Le correctif partiel est la correspondance de numéro (number matching) : l’utilisateur doit recopier un code affiché sur l’écran de login, ce qui interdit l’acceptation réflexe mais ne protège toujours pas contre un relais actif.

WebAuthn (Web Authentication, standard du W3C) change la nature de la preuve. À l’enrôlement, l’authentificateur — puce sécurisée du téléphone, module TPM (Trusted Platform Module) du portable, clé USB — génère une paire de clés asymétrique dédiée à ce service. La clé privée ne quitte jamais le matériel ; le serveur ne stocke que la clé publique, donc une fuite de base de données ne donne rien d’exploitable. À la connexion, le navigateur envoie à l’authentificateur un défi aléatoire accompagné de l’origine réelle de la page (schéma, domaine, port). Cette origine est incluse dans les données signées et vérifiée côté serveur.

C’est ce liage d’origine (origin binding) qui tue le hameçonnage. Un site micros0ft-login.example ne peut pas obtenir une signature valide pour login.microsoftonline.com : le navigateur refuse de solliciter la clé, et même s’il le faisait, la signature porterait la mauvaise origine. Google a déployé les clés de sécurité sur ses 85 000 employés en 2017 et n’a plus enregistré un seul compte compromis par hameçonnage depuis.

Les passkeys sont des identifiants WebAuthn découvrables (resident credentials) synchronisés par le fournisseur de plateforme — trousseau iCloud, gestionnaire Google, gestionnaire de mots de passe tiers. Cette synchronisation résout le problème de perte d’appareil qui bloquait l’adoption des clés matérielles, au prix d’un déplacement du modèle de menace : la sécurité du compte dépend désormais de la sécurité du compte plateforme et de sa procédure de récupération. Pour un usage à haute exigence, on garde des passkeys liées à l’appareil (device-bound) sur clé matérielle, avec attestation vérifiée pour s’assurer que l’authentificateur appartient bien à une liste de modèles autorisés.

// Enregistrement d'une passkey côté navigateur
const credential = await navigator.credentials.create({
  publicKey: {
    challenge: base64urlDecode(challengeFromServer), // aléa serveur, usage unique
    rp: { id: "exemple.fr", name: "Exemple" },        // relying party : le service
    user: {
      id: base64urlDecode(opaqueUserHandle), // identifiant opaque, JAMAIS l'email
      name: "alice@exemple.fr",
      displayName: "Alice Martin",
    },
    pubKeyCredParams: [
      { type: "public-key", alg: -7 },   // ES256 (ECDSA P-256)
      { type: "public-key", alg: -257 }, // RS256, repli pour vieux TPM
    ],
    authenticatorSelection: {
      residentKey: "required",        // passkey découvrable : login sans username
      userVerification: "required",   // code PIN ou biométrie locale exigés
    },
    timeout: 60000,
    attestation: "none", // "direct" seulement si on vérifie vraiment les certificats
  },
});
// Le serveur vérifie : origine, challenge, flags UP/UV, et enregistre la clé publique.

Comment authentifier des services entre eux sans transmettre de secret

Entre machines, le problème change de nature : pas d’humain pour taper un code, mais des milliers d’appels par seconde et des secrets qui traînent dans des fichiers de configuration. Kerberos, conçu au MIT dans les années 1980 et cœur de l’authentification Active Directory, résout cela par un tiers de confiance. Le KDC (Key Distribution Center, centre de distribution de clés) délivre d’abord un TGT (Ticket Granting Ticket, ticket d’octroi de tickets) après authentification initiale, puis des tickets de service chiffrés avec la clé du service cible. Le client ne connaît jamais la clé du service ; le service n’appelle jamais le KDC pour valider un ticket.

La contrainte structurante est temporelle : les tickets contiennent des horodatages et la tolérance par défaut est de cinq minutes. Une dérive d’horloge supérieure fait échouer toute l’authentification du realm, ce qui explique pourquoi NTP (Network Time Protocol) est une dépendance critique de tout domaine Kerberos. Les autres pièges opérationnels sont le SPN (Service Principal Name) mal enregistré ou dupliqué, qui provoque des échecs intermittents difficiles à diagnostiquer, et le Kerberoasting : un attaquant authentifié demande un ticket pour un compte de service, puis casse hors ligne le mot de passe qui chiffre ce ticket. La parade est d’imposer des mots de passe de 25 caractères ou plus aux comptes de service, ou de passer à des comptes de service gérés par le domaine.

Côté web et microservices, on distingue les jetons opaques des jetons auto-portants. Un jeton opaque est une simple référence aléatoire ; toute vérification passe par le serveur d’autorisation, ce qui permet une révocation immédiate mais impose un aller-retour réseau. Un JWT (JSON Web Token) embarque ses revendications signées : vérifiable localement en microsecondes, mais valide jusqu’à son expiration quoi qu’il arrive. Le compromis pratique consiste à garder des jetons d’accès JWT très courts — 5 à 15 minutes — adossés à un jeton de rafraîchissement opaque, révocable, avec détection de réutilisation : si un jeton de rafraîchissement déjà consommé réapparaît, on invalide toute la famille de jetons, signe probable de vol.

Trois erreurs reviennent constamment sur les JWT. Accepter l’algorithme annoncé dans l’en-tête du jeton lui-même permet l’attaque alg: none ou la confusion RS256/HS256, où la clé publique sert de secret HMAC ; il faut fixer l’algorithme attendu côté vérification. Omettre la validation des revendications aud (audience) et iss (émetteur) permet de rejouer un jeton émis pour un autre service. Enfin, un secret HMAC court est cassable hors ligne : au minimum 256 bits d’entropie réelle, ou mieux, une signature asymétrique avec rotation de clés via un point d’accès JWKS (JSON Web Key Set).

Pour l’authentification mutuelle entre services, mTLS (mutual Transport Layer Security) reste la référence : chaque service présente un certificat client à durée de vie courte, émis par une autorité interne. Les maillages de services comme Istio ou Linkerd automatisent la rotation, souvent toutes les 24 heures, ce qui rend le vol de certificat peu rentable. Voir aussi notre page sur les fondamentaux de la cryptographie appliquée pour le détail des signatures et de la gestion de clés.

# Détecter les comptes de service Active Directory exposés au Kerberoasting
# (SPN enregistré = ticket demandable par tout compte authentifié)
Get-ADUser -Filter {ServicePrincipalName -like "*"} `
  -Properties ServicePrincipalName, PasswordLastSet, msDS-SupportedEncryptionTypes |
  Select-Object Name, ServicePrincipalName, PasswordLastSet,
                @{n="AES";e={$_."msDS-SupportedEncryptionTypes" -band 24}}
# AES = 0 -> le ticket sera chiffré en RC4, cassage hors ligne bien plus rapide.

Prouver un mot de passe sans jamais l’envoyer : PAKE et OPAQUE

Dans tous les schémas classiques, y compris derrière TLS, le serveur reçoit le mot de passe en clair au moment de la vérification. Il le hache immédiatement, mais l’instant de vulnérabilité existe : un serveur compromis, un journal mal configuré, un intermédiaire TLS d’inspection capturent le secret. Les protocoles PAKE (Password-Authenticated Key Exchange, échange de clés authentifié par mot de passe) suppriment cette exposition. Client et serveur exécutent un échange où la connaissance du mot de passe permet de dériver une clé de session commune, sans que le mot de passe ni un équivalent transitent.

SRP (Secure Remote Password), la génération précédente, est encore utilisé — notamment par Apple pour iCloud. Sa faiblesse est d’être un PAKE « augmenté » imparfait : le vérificateur stocké côté serveur permet une attaque par dictionnaire hors ligne en cas de fuite, et le protocole ne s’adapte pas proprement aux courbes elliptiques modernes.

OPAQUE, standardisé par le CFRG (Crypto Forum Research Group) de l’IETF (Internet Engineering Task Force), corrige cela. Il repose sur une OPRF (Oblivious Pseudo-Random Function, fonction pseudo-aléatoire aveugle) : le client masque son mot de passe par un facteur aléatoire, le serveur applique sa clé secrète au résultat masqué, le client démasque. Le serveur n’apprend rien du mot de passe, le client n’apprend rien de la clé serveur, et le résultat sert à déchiffrer une enveloppe contenant la clé privée du client. Conséquence forte : le serveur ne détient aucun élément permettant une attaque hors ligne « pure ». Un attaquant qui vole la base doit interagir avec le serveur pour tester chaque candidat, ce qui rend la limitation de débit réellement efficace.

Le prix à payer est opérationnel. OPAQUE exige du code client — donc du JavaScript sur le web, avec toute la fragilité que cela implique si l’attaquant contrôle déjà la page servie. L’écosystème reste jeune : bibliothèques en Rust, Go et TypeScript disponibles, mais peu d’intégrations clés en main dans les frameworks d’authentification courants. Le raisonnement pragmatique en 2024 est simple : si vous pouvez déployer des passkeys, faites-le — elles apportent la résistance au hameçonnage qu’OPAQUE n’offre pas. OPAQUE trouve sa place dans les contextes où un mot de passe reste structurellement nécessaire, typiquement le déverrouillage d’un coffre chiffré de bout en bout.

Concevoir la récupération de compte sans détruire la sécurité

C’est la section la plus souvent bâclée, et celle qui décide du niveau de sécurité réel. Un parcours d’authentification résistant au hameçonnage adossé à une récupération par courriel ramène la sécurité globale à celle de la boîte mail. Les attaquants le savent : plutôt que d’attaquer la passkey, ils appellent le support en se faisant passer pour un employé ayant perdu son téléphone. Les intrusions MGM et Caesars en 2023 ont commencé par un appel au service d’assistance.

Le principe directeur est que la récupération doit être aussi forte que l’authentification nominale, ou explicitement traitée comme une dégradation assumée avec des contreparties. Concrètement : exiger l’enrôlement d’au moins deux authentificateurs dès la création du compte, ce qui rend la récupération d’urgence exceptionnelle plutôt que routinière. Générer des codes de secours à usage unique, stockés hachés côté serveur, présentés une seule fois. Imposer un délai — 24 à 72 heures — avant qu’une réinitialisation complète ne prenne effet, avec notification sur tous les canaux enregistrés, ce qui donne à l’utilisateur légitime le temps d’annuler. Pour les comptes à privilèges, exiger une vérification hors bande par un second humain.

Une réinitialisation doit aussi invalider l’ensemble des sessions actives et des jetons de rafraîchissement. Sans cela, un attaquant qui a obtenu une session avant la réinitialisation la conserve. Voir également nos notes sur la gestion des accès et des privilèges pour l’articulation entre authentification et autorisation — deux choses distinctes : la première établit qui vous êtes, la seconde décide de ce que vous pouvez faire.

FAQ

Faut-il supprimer les mots de passe dès qu’on déploie les passkeys ? Pas immédiatement. Une phase de coexistence est nécessaire : tous les navigateurs et systèmes de vos utilisateurs ne supportent pas les passkeys, et certains contextes d’entreprise verrouillent les authentificateurs de plateforme. La bonne trajectoire est de proposer la passkey par défaut, de mesurer le taux d’adoption, puis de retirer le mot de passe compte par compte une fois deux authentificateurs enrôlés. Attention : tant que le repli mot de passe existe, la résistance au hameçonnage n’est pas acquise, car un attaquant poussera l’utilisateur vers ce repli.

Un jeton JWT peut-il être révoqué ? Pas nativement : un JWT signé est valide jusqu’à son expiration, tout vérificateur hors ligne l’acceptera. Trois contournements existent : durées de vie très courtes (5 à 15 minutes) qui bornent la fenêtre, liste de révocation consultée à chaque vérification — ce qui annule l’intérêt du format auto-portant —, ou une revendication de version incrémentée à chaque événement de sécurité et comparée à un cache. En pratique, on combine jeton d’accès court et jeton de rafraîchissement opaque révocable.

La biométrie du téléphone est-elle envoyée au serveur ? Non, jamais. L’empreinte ou le visage servent uniquement à déverrouiller localement la puce sécurisée qui détient la clé privée. Le serveur ne reçoit qu’une signature cryptographique accompagnée d’un indicateur de vérification utilisateur. C’est une différence essentielle avec la biométrie centralisée : aucune donnée biométrique ne quitte l’appareil, donc aucune fuite de gabarit n’est possible côté service.

SMS ou TOTP quand on ne peut pas déployer de passkeys ? TOTP sans hésiter. Le SMS est vulnérable à l’échange de carte SIM, à l’interception via le protocole SS7 et à la dépendance à l’opérateur ; le NIST le déconseille depuis 2016. TOTP reste hameçonnable par relais, mais élimine toute la surface d’attaque télécom. Un SMS vaut toujours mieux que rien face au bourrage d’identifiants, mais il ne doit pas être le facteur de secours d’un compte à privilèges.

Conclusion

L’authentification moderne n’est pas un choix d’algorithme mais un arbitrage de parcours. Argon2id bien paramétré protège une base de mots de passe volée ; WebAuthn et les passkeys éliminent le hameçonnage grâce au liage d’origine ; Kerberos et mTLS couvrent l’authentification machine à machine ; OPAQUE répond au cas particulier du secret qui ne doit jamais atteindre le serveur. Aucun de ces mécanismes ne compense une récupération de compte faible, une session éternelle ou un support technique qui réinitialise sur simple appel. La règle de conception tient en une phrase : votre niveau de sécurité est celui de votre chemin le plus faible, et ce chemin est presque toujours la porte de secours.

🦫 Explication de la marmotte 🍫

Quand tu te connectes à un site, tu dois prouver que c’est bien toi. La méthode ancienne : un mot de passe. Le site ne le range pas tel quel, il le transforme en une suite de caractères illisible grâce à un calcul volontairement lent, avec un grain de sel unique ajouté pour toi. Ainsi, même si des voleurs copient la base, ils devront tester des milliards de possibilités, une par une.

Problème : quelqu’un peut te fabriquer un faux site et récupérer ce que tu tapes, y compris le code à six chiffres de ton application. La solution récente s’appelle passkey. Ton téléphone fabrique deux clés jumelles : une secrète qui ne sort jamais de la puce protégée, une publique donnée au site. Pour te connecter, le site envoie un défi, ton téléphone le signe avec la clé secrète, et il ajoute l’adresse exacte de la page. Un faux site ne pourra jamais produire la bonne signature : son adresse ne correspond pas. Ton empreinte digitale ne part nulle part, elle sert seulement à débloquer la puce.

Entre machines, même logique : elles échangent des tickets à durée courte plutôt que des mots de passe. Et le vrai point faible reste toujours le même : la procédure prévue quand tu perds ton téléphone.