L'authentification multifacteur

Le mot de passe seul ne suffit plus. Il est réutilisé d’un site à l’autre, deviné, volé par hameçonnage ou récupéré dans une fuite de données. L’authentification multifacteur (MFA) ajoute une preuve d’une autre nature, pour qu’un mot de passe compromis ne donne pas accès au compte. Ce cours présente les facteurs, les technologies courantes et les notions qui servent à piloter le MFA par application.

Les trois catégories de facteurs

Un facteur d’authentification appartient à l’une de trois catégories.

Catégorie	Principe	Exemples
Connaissance	Ce que je sais	Mot de passe, code PIN, phrase de passe
Possession	Ce que je possède	Téléphone avec une application d’OTP, clé de sécurité FIDO2, carte à puce
Inhérence	Ce que je suis	Empreinte digitale, reconnaissance faciale

On parle de MFA quand on combine des facteurs de catégories différentes. Deux mots de passe, ou un mot de passe et une question secrète, restent une authentification à un seul facteur, même en deux étapes.

La biométrie est rarement un facteur transmis au serveur. Sur un téléphone ou un ordinateur, l’empreinte ou le visage sert le plus souvent à déverrouiller localement une clé stockée sur l’appareil. Le serveur reçoit une preuve de possession de cette clé, accompagnée d’une indication que l’utilisateur a été vérifié localement.

Les codes à usage unique : HOTP et TOTP

Les OTP (One-Time Password) sont des codes courts, valables une seule fois. Les deux algorithmes standard reposent sur un secret partagé entre le serveur et l’appareil de l’utilisateur, échangé lors de l’enrôlement, souvent par un QR code.

HOTP (RFC 4226) calcule un HMAC du secret et d’un compteur incrémenté à chaque code. Le serveur doit tolérer un décalage de compteur.
TOTP (RFC 6238) remplace le compteur par le temps : le nombre d’intervalles écoulés depuis une date de référence, généralement des intervalles de 30 secondes. C’est ce qu’utilisent les applications comme FreeOTP ou Google Authenticator.

Le QR code d’enrôlement contient une URI de ce type :

otpauth://totp/Exemple:claire.martin?secret=JBSWY3DPEHPK3PXP&issuer=Exemple&algorithm=SHA1&digits=6&period=30

Les OTP sont simples à déployer et bien mieux qu’un mot de passe seul. Ils ont deux faiblesses : le secret partagé est stocké côté serveur, et le code peut être saisi sur un faux site puis rejoué immédiatement par l’attaquant. Les codes par SMS ou par e-mail ajoutent des risques propres au canal (détournement de ligne, compromission de la boîte mail).

WebAuthn, FIDO2 et passkeys

FIDO2 est un ensemble de standards porté par la FIDO Alliance et le W3C. Sa partie web, WebAuthn, permet à un site d’enregistrer puis d’utiliser une paire de clés asymétriques détenue par un authentificateur : une clé USB ou NFC, ou la puce de sécurité d’un téléphone ou d’un ordinateur.

Le serveur ne stocke qu’une clé publique : une fuite de sa base ne permet pas de se faire passer pour l’utilisateur. La clé privée ne quitte pas l’authentificateur, ou circule chiffrée dans le cas des passkeys synchronisées.

Les passkeys sont des identifiants WebAuthn « découvrables » : l’authentificateur sait proposer le bon compte sans que l’utilisateur saisisse d’identifiant. Elles peuvent être liées à un appareil ou synchronisées entre les appareils d’un même utilisateur par son gestionnaire de mots de passe ou son système. Comme l’appareil vérifie l’utilisateur localement, une passkey peut remplacer à elle seule le mot de passe et le second facteur.

La résistance au phishing

Un facteur est résistant au phishing si un attaquant qui contrôle un faux site ne peut pas obtenir une preuve réutilisable sur le vrai site. C’est la propriété clé qui distingue WebAuthn des OTP.

Méthode	Secret côté serveur	Résiste au relais en temps réel
Mot de passe	Empreinte du mot de passe	Non
OTP par SMS ou e-mail	Code généré à la volée	Non
TOTP / HOTP	Secret partagé	Non
Notification push à valider	Variable selon la solution	Non
WebAuthn (clé FIDO2, passkey)	Clé publique seulement	Oui

La raison est technique : le navigateur transmet à l’authentificateur l’origine réelle de la page, et la signature porte sur cette origine. Une clé enregistrée pour exemple.fr ne répondra pas pour exemple-connexion.fr, et l’utilisateur ne peut pas se tromper à sa place.

Le step-up et les niveaux d’authentification

Toutes les applications n’ont pas besoin du même niveau de garantie. Consulter un annuaire interne et valider un paiement ne présentent pas le même risque. On définit donc des niveaux d’authentification, souvent appelés LoA (Level of Assurance). Le règlement européen eIDAS, par exemple, définit trois niveaux : faible, substantiel et élevé.

Les protocoles transportent ce niveau :

en OpenID Connect, le client demande un niveau par le paramètre acr_values et lit le niveau obtenu dans le claim acr de l’ID token ; le claim amr liste les méthodes utilisées ;
en SAML, c’est le rôle de l’AuthnContextClassRef, dans la requête comme dans l’assertion.

Le step-up consiste à relever le niveau en cours de session, seulement quand c’est nécessaire. L’utilisateur s’est connecté avec un mot de passe ; au moment d’une opération sensible, l’application relance une requête d’autorisation :

GET /realms/demo/protocol/openid-connect/auth?response_type=code
    &client_id=paiement
    &scope=openid
    &acr_values=niveau-eleve
    &redirect_uri=https%3A%2F%2Fpaiement.exemple.fr%2Fcallback
    &state=xyz&nonce=abc
    &code_challenge=...&code_challenge_method=S256 HTTP/1.1
Host: idp.exemple.fr

L’IdP voit que la session ne satisfait pas ce niveau et demande le second facteur. Il ne redemande pas le mot de passe si la session est encore valide. Le client doit ensuite vérifier le claim acr du nouvel ID token : rien ne garantit que l’IdP a pu satisfaire la demande. Les valeurs d’acr ne sont pas normalisées par OIDC ; elles sont définies par chaque IdP ou chaque fédération.

La récupération de compte

Tout facteur peut se perdre : téléphone cassé, clé oubliée, changement d’appareil. La procédure de récupération est souvent le maillon faible. Si un simple e-mail suffit à réinitialiser le second facteur, le niveau réel du compte est celui de la boîte mail.

Quelques principes généraux :

proposer plusieurs facteurs enrôlés par compte, par exemple une passkey et une application TOTP, ou des codes de secours générés une fois et conservés hors ligne ;
réserver la réinitialisation complète à une procédure de vérification d’identité de niveau au moins équivalent, par exemple via un support qui contrôle l’identité ;
notifier l’utilisateur à chaque ajout ou suppression de facteur ;
journaliser ces opérations pour pouvoir les auditer.

Les recommandations de l’ANSSI

L’ANSSI publie un guide intitulé Recommandations relatives à l’authentification multifacteur et aux mots de passe. Il traite des facteurs d’authentification, des moyens de les mettre en œuvre, des mots de passe et de leur stockage. C’est le référentiel à citer pour un système d’information public en France.

Le cours de la section Essentiel consacré aux parcours d’authentification montre comment Keycloak met en œuvre ces mécanismes : flux d’authentification, TOTP, WebAuthn et niveaux d’authentification.