Pour sécuriser l’accès à une application métier, la règle est simple : un mot de passe seul ne suffit plus, et toutes les authentifications fortes ne se valent pas. L’authentification multifacteur (MFA) doit être la norme, au minimum pour les administrateurs et les accès depuis l’extérieur, et il faut privilégier les méthodes qui résistent à l’hameçonnage, comme les passkeys et les clés de sécurité, plutôt que le SMS ou les codes à recopier. Pour les salariés, le plus efficace est souvent de déléguer l’authentification à l’annuaire de l’entreprise, qui applique déjà ces règles.
Qu’est-ce que l’authentification multifacteur ?
L’authentification multifacteur consiste à prouver son identité avec au moins deux facteurs appartenant à des catégories différentes. La CNIL en retient trois : ce que l’on sait (un mot de passe, un code), ce que l’on possède (un téléphone, une clé physique, une carte), ce que l’on est (une empreinte, un visage).
La nuance compte. L’ANSSI distingue la « double authentification », qui peut reposer sur deux éléments de la même catégorie (deux mots de passe, par exemple), de l’authentification multifacteur proprement dite. Demander un mot de passe puis une question secrète n’est pas de la MFA : ce sont deux choses que l’on sait, et toutes deux peuvent être volées de la même manière.
L’efficacité de la MFA est bien documentée. Une étude de Microsoft Research publiée en 2023, portant sur des comptes de sa plateforme d’identité qui présentaient une activité suspecte, a estimé que la MFA réduisait de 99,22 % le risque de compromission sur l’ensemble des comptes étudiés, et de 98,56 % pour ceux dont les identifiants avaient fuité.
Toutes les méthodes se valent-elles ?
Non. La menace principale aujourd’hui est l’hameçonnage en temps réel : un faux site, identique au vrai, récupère le mot de passe et le code saisis par l’utilisateur et les rejoue immédiatement sur le vrai site. Face à cette attaque, une méthode qui consiste à recopier un code ne protège pas : l’utilisateur le donne lui-même à l’attaquant.
| Méthode | Résiste à l’hameçonnage | Ergonomie | Ce qu’en disent les référentiels |
|---|---|---|---|
| Mot de passe seul | Non | Bonne, mais mots de passe réutilisés | Insuffisant pour des données sensibles |
| Code reçu par SMS | Non | Moyenne, dépend du réseau | Déconseillé par l’ANSSI (détournement de ligne, protocoles vulnérables) ; usage restreint par le NIST |
| Code d’une application d’authentification (TOTP) | Non | Moyenne | Le NIST rappelle qu’un code saisi à la main n’est pas résistant à l’hameçonnage |
| Notification à valider sur le téléphone | Partiellement | Bonne | Exposée aux validations par lassitude si l’on ne fait pas recopier un nombre affiché |
| Passkey synchronisée | Oui | Très bonne | Admise par le NIST au niveau d’assurance intermédiaire (AAL2) |
| Clé de sécurité ou passkey liée à un appareil | Oui | Bonne, un objet à ne pas perdre | Admise par le NIST au niveau le plus élevé (AAL3), contrairement aux passkeys synchronisées |
La version 4 des lignes directrices du NIST sur l’authentification va plus loin : au niveau d’assurance intermédiaire, le service doit proposer au moins une option résistante à l’hameçonnage. C’est une bonne cible pour toute application qui manipule des données clients ou financières.
Les passkeys, expliquées simplement
Une passkey est un identifiant de connexion fondé sur les standards de la FIDO Alliance et sur la norme WebAuthn du W3C, qui remplace le mot de passe par une paire de clés cryptographiques. Le fonctionnement tient en trois idées :
- À l’inscription, l’appareil de l’utilisateur crée une paire de clés propre à ce site. La clé publique est envoyée au serveur ; la clé privée reste sur l’appareil ou dans le gestionnaire de l’utilisateur.
- À la connexion, le serveur envoie un défi que l’appareil signe avec la clé privée, après que l’utilisateur l’a déverrouillé (empreinte, visage ou code de l’appareil).
- La passkey est liée au nom de domaine du site. Sur un faux site, même parfaitement imité, elle ne fonctionne tout simplement pas : c’est ce qui la rend résistante à l’hameçonnage par construction.
Le serveur ne stocke aucun secret réutilisable : une fuite de sa base ne livre que des clés publiques, inutilisables pour se connecter. Et la biométrie ne quitte jamais l’appareil.
On distingue deux familles. Les passkeys synchronisées sont copiées d’un appareil à l’autre par le gestionnaire de l’utilisateur, ce qui règle le problème du téléphone perdu. Les passkeys liées à un appareil, notamment sur une clé de sécurité physique, ne le quittent jamais et offrent le niveau d’assurance le plus élevé, au prix d’une gestion plus stricte. L’adoption progresse : dans une enquête commandée par la FIDO Alliance en 2024, 53 % des personnes interrogées déclaraient avoir activé les passkeys sur au moins un de leurs comptes.
Que mettre en place selon le profil des utilisateurs ?
Une application métier sert des publics différents, qui n’appellent pas la même réponse.
| Profil | Recommandation | Pourquoi |
|---|---|---|
| Salariés | Authentification unique via l’annuaire de l’entreprise, qui impose la MFA | Une seule politique, un départ géré en un clic, pas de mot de passe supplémentaire |
| Administrateurs et comptes à privilèges | Méthode résistante à l’hameçonnage obligatoire (clé de sécurité, passkey) | Un compte administrateur compromis donne accès à tout |
| Clients et partenaires d’un portail B2B | Passkeys proposées en priorité, application d’authentification en secours | Sécurité élevée sans imposer d’outil à des personnes extérieures |
| Postes partagés en atelier ou en entrepôt | Session courte, badge ou code personnel, droits limités au poste | Ergonomie terrain, traçabilité par personne |
Pour les salariés, déléguer l’authentification à Microsoft Entra ID ou Google Workspace est presque toujours la meilleure option : la politique de MFA, l’accès conditionnel et la désactivation des comptes se gèrent à un seul endroit. C’est un point que nous intégrons systématiquement lors des connexions avec Microsoft 365.
Pour un portail client B2B, la logique est différente : l’application gère elle-même ses comptes, et l’ergonomie conditionne l’adoption. Les passkeys sont alors un avantage, pas une contrainte.
Renforcer la vérification au moment des actions sensibles
Le niveau d’authentification ne se décide pas seulement à la connexion. Certaines actions justifient une vérification renforcée au moment où elles sont demandées, même si l’utilisateur est déjà connecté : modifier des coordonnées bancaires, valider un paiement, exporter une base clients, attribuer des droits d’administration. Combinée à une gestion fine des rôles, cette vérification limite fortement l’impact d’une session détournée.
Le mot de passe disparaît-il ?
Pas encore. Pendant la transition, il reste la méthode de secours de nombreux comptes. Autant qu’il soit bien géré, et les règles ont changé :
- La longueur prime sur la complexité. Le NIST exige au moins 15 caractères pour un mot de passe utilisé seul et interdit d’imposer des règles de composition (majuscule, chiffre, caractère spécial).
- Pas de changement périodique forcé. Le NIST l’interdit, sauf en cas de compromission ; l’ANSSI ne le recommande pas pour les utilisateurs standards.
- Un stockage à l’état de l’art. La CNIL demande de ne conserver qu’une empreinte du mot de passe, calculée avec une fonction conçue pour cet usage et un sel, et proscrit les fonctions obsolètes comme MD5 ou SHA-1.
- Les gestionnaires de mots de passe bienvenus. La CNIL range parmi les mauvaises pratiques le blocage du copier-coller et de la saisie automatique dans les formulaires.
- Une limitation des tentatives pour freiner les attaques par essais successifs, sujet traité dans notre article sur l’OWASP Top 10.
La récupération de compte, maillon faible de la chaîne
Une authentification forte peut être contournée par un parcours de récupération faible. Si « j’ai perdu mon téléphone » mène à un simple lien envoyé par e-mail ou à un code par SMS, l’attaquant passera par là.
Quelques principes :
- Permettre plusieurs méthodes dès l’inscription : deux passkeys, ou une passkey et des codes de secours imprimés.
- Exiger une vérification d’identité pour les réinitialisations traitées par le support, avec une procédure écrite.
- Notifier l’utilisateur de toute nouvelle méthode ajoutée ou de toute récupération, sur un canal distinct.
- Journaliser chaque changement de méthode d’authentification.
Comment déployer sans braquer les utilisateurs ?
L’authentification forte échoue rarement pour des raisons techniques. Elle échoue quand les utilisateurs la vivent comme une contrainte imposée du jour au lendemain. Un déploiement réussi suit généralement ces étapes :
- Commencer par les administrateurs et les comptes à privilèges, sans exception.
- Proposer avant d’imposer : un enrôlement guidé, en quelques écrans, avec une période pendant laquelle l’activation est encouragée mais pas encore obligatoire.
- Mémoriser les appareils de confiance pendant une durée raisonnable, pour ne pas redemander un second facteur à chaque connexion depuis le poste habituel.
- Mesurer le taux d’enrôlement et les demandes au support, et ajuster.
- Expliquer le pourquoi, avec des exemples concrets d’attaques, dans la logique de conduite du changement qui accompagne tout nouvel outil.
L’authentification se conçoit dès le début d’un projet, pas au moment de la mise en production. Toutes les applications que nous développons intègrent l’authentification forte, les passkeys et l’authentification unique selon vos publics. Pour faire le point sur la sécurité des accès d’une application existante ou à venir, contactez-nous.
