- Les politiques qui exigent une authentification fréquente n’apportent en pratique aucun renforcement réel de la sécurité et ne font qu’accroître la gêne pour les utilisateurs
- Avec la hausse des menaces récentes comme les attaques par fatigue MFA, la réauthentification répétée peut au contraire devenir une vulnérabilité
- Le verrouillage de l’écran par le système d’exploitation et les mises à jour en temps réel des politiques d’accès constituent des moyens de protection plus efficaces
- Une authentification supplémentaire n’est nécessaire que juste avant une opération sensible ; des cycles de connexion arbitrairement courts sont inutiles
- Les méthodes modernes de contrôle d’accès appliquent les politiques automatiquement et rapidement sans perturber l’utilisateur
Pourquoi les authentifications fréquentes ne renforcent pas la sécurité
Les problèmes causés par la réauthentification répétée
- Quand une session expire souvent en plein travail, le fait de ressaisir sans cesse le mot de passe et le MFA (authentification multifacteur) entraîne une baisse de productivité
- Au départ, il suffisait de ressaisir le mot de passe, mais l’ajout de l’étape MFA a aggravé la perte de temps et le mécontentement des utilisateurs
- Plus les demandes MFA sont fréquentes, plus la probabilité de réussite des attaques par fatigue MFA (MFA fatigue attacks) augmente
- Autrefois, le changement fréquent de mot de passe ou des expirations de session très courtes étaient considérés comme des mesures de sécurité efficaces, mais les recommandations récentes les jugent plutôt contre-productifs
- La sécurité ne dépend pas de la fréquence de connexion, mais de la rapidité avec laquelle la gestion des droits d’accès et les changements de politique sont pris en compte
La nature même de l’authentification
- L’authentification sert généralement à prouver l’un des deux éléments suivants
- Preuve de possession de l’appareil : vérifier que l’on détient physiquement l’appareil, via Windows Hello PIN, YubiKey, carte à puce, etc.
- Preuve d’identité : vérifier qu’il s’agit bien de l’utilisateur concerné, via un mot de passe, Face ID, Touch ID, etc.
- Le rôle principal d’un Identity Provider (IdP) est de se concentrer sur la vérification de l’identité
- Face ID, Touch ID, Windows Hello, etc. sont des systèmes intégrés très sûrs qui traitent à la fois la preuve de possession de l’appareil et la preuve d’identité
- De nombreux administrateurs configurent des expirations de session très courtes par crainte que les changements de politique ne soient pas appliqués immédiatement
Les menaces réelles et le rôle de l’authentification
- La plupart des attaquants opèrent par phishing à distance, et le vol de mot de passe est extrêmement facile
- Pour se défendre contre les attaques à distance, l’usage d’une authentification secondaire (par ex. YubiKey) constitue une protection importante
- En cas d’attaque physique, comme la perte ou le vol d’un appareil, l’écran est généralement déjà verrouillé
- À l’inverse, plus on se connecte souvent, plus on donne aux attaquants des occasions de voler des identifiants, ce qui nuit à la sécurité
Le rôle du système d’exploitation et des services web
- Les systèmes d’exploitation modernes protègent automatiquement le système grâce au verrouillage de l’écran lorsque l’utilisateur s’absente
- Plutôt que d’imposer davantage de frictions en augmentant la fréquence des authentifications, il est préférable d’appliquer des politiques de verrouillage automatique
- Sauf sur un ordinateur partagé, les expirations courtes des sessions web ne sont qu’un vestige de l’époque des cybercafés
- En dehors de services sensibles (par ex. la banque en ligne), des politiques d’expiration de session inadaptées dégradent au contraire à la fois la sécurité et l’utilisabilité
Un modèle de sécurité efficace et respectueux de l’utilisateur
- Une authentification immédiate avant une opération sensible (on-demand authentication) est idéale
- Le mode check de Tailscale SSH, Slack Accessbot, etc. offrent une vérification immédiate de l’utilisateur lorsque nécessaire
- En l’associant à l’application du verrouillage de l’écran par le système d’exploitation, il est possible de préserver l’équilibre entre sécurité et confort d’usage
- Les contrôles continus de l’état de sécurité (device posture check) et le contrôle d’accès en temps réel s’effectuent automatiquement, indépendamment du comportement de l’utilisateur
- Exemples :
- si l’appareil est hors ligne, perdu ou échoue à une vérification de sécurité, les droits d’accès sont retirés immédiatement
- si le rôle de l’utilisateur change ou que son statut évolue, les politiques d’accès sont mises à jour automatiquement
- Une approche de l’automatisation en temps réel est bien plus intelligente et plus sûre qu’un modèle qui force l’utilisateur à se réauthentifier sans cesse
Conclusion
- Des connexions fréquentes n’améliorent pas efficacement la sécurité et peuvent au contraire favoriser la réutilisation de mots de passe, le phishing et la fatigue MFA
- Un système de sécurité discret et automatisé constitue la meilleure protection
- Tailscale vise une sécurité adaptative, intelligente et réellement utile
- Le système est conçu pour que l’utilisateur n’ait pas à ajuster lui-même la fréquence de connexion, tout en ne subissant qu’un minimum de friction d’authentification au moment nécessaire
- Les fonctions de vérification de sécurité en temps réel de Tailscale peuvent aussi être étendues à d’autres applications, afin de protéger même les systèmes legacy en toute sécurité
Liens de référence
4 commentaires
Cela a aussi été mentionné dans les commentaires de HN, mais par rapport à un environnement IT qui évolue rapidement, les contrôles et réglementations de sécurité fondés sur des standards rigides et anciens constituent souvent un vrai frein. Ceux qui sont sur le terrain le savent sans doute déjà tous... haha
Beaucoup de services en Corée affichent cette notification agaçante qui vous demande de réinitialiser votre mot de passe une fois tous les 30 jours.
C’est une contrainte imposée depuis des années au nom des obligations de sécurité des données personnelles, donc oui, c’est vraiment très pénible... snif snif
Avis Hacker News
Je pense que les politiques obligatoires de changement périodique ou d’expiration des mots de passe posent un problème encore plus grand : elles finissent souvent par verrouiller les utilisateurs hors de leur compte (par exemple si le mot de passe expire pendant des vacances), puis cela entraîne toute une série de contraintes — aller voir l’IT en personne, passer des heures au téléphone avec l’IT pour demander une réinitialisation, ou faire contacter l’IT par un collègue qui, lui, n’est pas verrouillé.
Beaucoup (la plupart ?) d’entreprises appliquent encore ce genre de politique, alors que le NIST ne recommande plus les changements arbitraires de mot de passe.
Document officiel du NIST
Microsoft non plus ne recommande pas l’expiration des mots de passe, qu’il juge plus nuisible qu’utile.
Document officiel de Microsoft
Et pourtant, dans l’IT et la sécurité, on a l’impression que ces recommandations ne sont toujours pas considérées comme suffisamment « autorisées », d’autant qu’il existe encore des guides qui continuent à défendre ces politiques.
Quand je me connecte à un site au hasard et qu’on m’oblige soudain à réinitialiser mon mot de passe, je me dis que ce n’est peut-être pas une expiration basée sur le temps, mais que le compte a pu fuiter ou être compromis.
Si l’exploitant du site sait que certains comptes figurent dans une liste de données compromises, exiger un changement de mot de passe à la prochaine connexion me semble être une réponse raisonnable.
Quand j’en ai parlé à un responsable cybersécurité, on m’a répondu que les exigences PCI imposent les changements périodiques de mot de passe, donc tout dépend de l’audit auquel on accorde le plus d’importance.
À une époque, cette politique m’agaçait tellement que je la contournais simplement en ajoutant à chaque fois une lettre à la fin de mon mot de passe, dans l’ordre de a à z.
Heureusement, dans mon entreprise actuelle, j’utilise le même mot de passe depuis trois ans, et ça me convient très bien.
Je trouve absurde que des fournisseurs me demandent de changer régulièrement mon mot de passe alors qu’il n’a pas été compromis.
Le fait que cela soit encore appliqué comme une sorte de standard officiel est sidérant.
Au final, tous mes comptes finissent avec le même schéma
1234abcd@.Je trouve ça vraiment pénible avec les produits Apple.
J’ai constaté ce comportement sur tous les produits Apple.
Sur Mac, même si Touch ID est configuré, si je me connecte à mon compte Apple dans l’App Store puis que j’essaie d’installer une app, une fenêtre me redemande sans cesse le mot de passe, alors que Touch ID pourrait très bien servir à l’authentification.
C’est pareil pour les applications gratuites, et je trouve cette étape totalement inutile.
Le même schéma apparaît aussi parfois sur l’iPhone de mon épouse.
Quand on réinitialise le téléphone et qu’on le configure de nouveau, Apple redemande particulièrement souvent le mot de passe.
Même quand la situation est déjà suffisamment sécurisée par Touch ID, ça continue comme ça, et c’est frustrant.
L’inconfort est encore pire lorsqu’on accède aux services Apple depuis un appareil non Apple.
À chaque connexion à icloud.com, même si je clique sur « faire confiance à cet appareil », le lendemain je dois à nouveau repasser par le mot de passe + le code à usage unique, donc toute la procédure de double authentification.
Si Face ID échoue au moment d’un paiement ou de l’installation d’une app, Apple ne bascule pas vers le PIN mais exige carrément le mot de passe complet du compte Apple, tout en empêchant d’ouvrir l’application de gestionnaire de mots de passe.
Vivre ça en caisse est vraiment pénible.
Il faut bien vérifier que l’option d’approbation des achats via Touch ID est activée.
(Il faut aller dans Settings > Touch ID & Password pour la configurer.)
Si ce n’est pas activé, il est possible qu’on vous redemande le mot de passe en permanence.
D’après mon expérience, il faut s’authentifier une seule fois après un redémarrage, puis Touch ID suffit ensuite dans la plupart des cas.
Chaque fois que je branche mon iPhone à mon Mac pour le synchroniser, la fenêtre « Faire confiance à cet appareil ? » apparaît à la fois sur le Mac et sur l’iPhone, et même si je réponds « oui » à chaque fois, la question revient à la connexion suivante.
Quand il s’agit d’opérations nécessitant les privilèges
sudo, je trouve normal qu’une réauthentification soit demandée.Dans ce cas, on peut réduire le nombre de réauthentifications en regroupant les opérations concernées pour n’avoir à s’authentifier qu’une seule fois.
Mon enfant utilise un très vieil iPad sous iOS 10.3, donc le gestionnaire de mots de passe n’y fonctionne pas, et le navigateur est lui aussi une application 32 bits incapable d’afficher les sites modernes.
Du coup, à chaque utilisation de l’App Store, je dois saisir manuellement un mot de passe de plus de 50 caractères, ce qui est extrêmement pénible.
Je pense que les personnes qui devraient lire ce genre d’article sont les auditeurs qui réalisent les audits de sécurité.
Tant que leurs attentes ne changent pas, beaucoup d’entreprises continueront à suivre des politiques absurdes dans la pratique, tout en les présentant comme des standards de l’industrie.
Même de petites entreprises dans certains secteurs sont obligées d’obtenir de bonnes notes aux audits de sécurité, et adoptent donc quantité de procédures inutiles.
Chez nous, au moins six mesures de sécurité dont on sait qu’elles sont inefficaces sont imposées, et les auditeurs restent encore très peu enclins à changer.
Lors des audits SOC2, j’ai régulièrement présenté les recommandations du NIST.
Quand on leur montre les liens, la plupart finissent par accepter les critères du NIST.
Apple comme Microsoft permettent aux équipes sécurité d’entreprise de désactiver, via des réglages d’entreprise, des options comme « se souvenir de mon appareil » ou « faire confiance à cet appareil ».
Les auditeurs ou le CISO (directeur de la sécurité des systèmes d’information) raisonnent entièrement en mode checklist : ce qui compte, ce n’est pas l’amélioration réelle de la sécurité, mais le fait de faire valider l’audit.
Ces réglages ne font qu’augmenter la gêne utilisateur tout en dégradant en pratique la sécurité réelle.
Je pense que Microsoft a aussi ruiné le jeu sur PC de cette manière.
Je repousse le moment de lancer des jeux comme Minecraft ou la Master Chief Collection parce que je sais qu’une fenêtre de réauthentification va surgir de nulle part.
À cause de ce genre de friction, j’ai même désactivé la 2FA sur mon compte.
Ce n’est qu’un jeu, pas une validation bancaire ; j’aimerais juste pouvoir jouer tranquillement.
On me dit qu’il existe maintenant une fonction pour s’authentifier en scannant un QR code, mais j’ai l’impression que les gens qui conçoivent ce système sont totalement déconnectés de l’expérience utilisateur réelle.
Il y a un aspect à peine évoqué dans l’article.
Une mauvaise UX (expérience utilisateur) peut en soi devenir une vulnérabilité de sécurité.
Si un système se comporte habituellement de manière irrationnelle, les utilisateurs risquent de ne plus remarquer les changements ou les comportements anormaux quand un vrai problème survient.
Par exemple, si la demande de mot de passe apparaît trop souvent, on finit par le saisir machinalement, et dans ce contexte il devient plus difficile de repérer des risques comme le phishing.
De plus, si l’OS ne gère pas correctement les programmes de démarrage ou le code suspect exécuté en arrière-plan, l’exploitation devient plus facile.
Le fait que beaucoup de professionnels de la sécurité négligent presque totalement la psychologie humaine comme variable importante est aussi un problème, tout comme la tendance à tout concevoir sous l’angle de la checklist ou des intérêts de l’entreprise.
Ce sont des erreurs qu’un bon design produit permettrait d’éviter, mais comme les fournisseurs de produits et services sont bien plus actifs que les consommateurs lorsqu’il s’agit de faire évoluer la réglementation, les améliorations arrivent mal.
Au final, je pense en réalité qu’un renforcement de la régulation peut aider la sécurité, mais on se retrouve dans une situation étrange où les entreprises refusent toute régulation de leurs propres produits et services.
Les systèmes qui imposent des réauthentifications fréquentes n’améliorent pas réellement la sécurité (sauf peut-être avec des expirations très longues, qui constituent un cas un peu à part).
Dans un bon système d’authentification, l’essentiel est d’avoir la capacité de retirer immédiatement des droits via l’expiration de session ou une gestion explicite des sessions.
En pratique, le point bien plus important que la fréquence de réauthentification, c’est le « délai » entre le moment où l’on révoque une session et celui où cette session expire complètement et perd tout accès.
Cela devient encore plus complexe selon l’architecture du système d’authentification et le nombre de systèmes qui le composent.
C’est pour cela qu’il faut des refresh tokens.
Le token effectif expire régulièrement, mais le client reçoit séparément la possibilité d’en obtenir un nouveau.
La révocation des tokens se contrôle en empêchant la création de nouveaux tokens.
Je pense à peu près pareil.
Dans mon entreprise, nous utilisons une authentification en deux étapes.
Une ou deux fois par jour, je me connecte à keycloak via ADFS + MFA, et la plupart des systèmes utilisent keycloak comme provider OIDC, avec un rafraîchissement du token toutes les 10 à 15 minutes.
Du coup, la plupart du temps je n’ai à subir la procédure d’authentification pénible qu’une fois par jour, et si nécessaire on peut bloquer complètement l’accès à des services accessibles via VPN en moins de 15 minutes.
L’avantage, c’est qu’en usage normal, ce genre de changement est presque invisible.
Il n’est pas nécessaire de redemander une authentification complète ; il suffit de renouveler périodiquement les tokens existants.
Il est préférable de séparer la durée d’expiration de l’authentification (
auth) de celle de l’autorisation (authorization).Si l’on force les réauthentifications fréquentes, les gens finissent au contraire par chercher des moyens de contournement.
Ils écrivent leur mot de passe sur du papier, l’enregistrent dans Google Docs, bricolent un Yubikey avec un Arduino et un servomoteur, transfèrent les SMS par e-mail, ou envoient les codes TOTP sur WeChat — toutes sortes de « hacks » apparaissent.
Au final, plus une politique d’authentification inconfortable devient lourde, plus les utilisateurs cherchent des contournements dangereux pour pouvoir utiliser leur ordinateur avec un minimum de liberté.
L’article dit en substance qu’« à présent, sur la plupart des OS, on peut déverrouiller avec empreinte digitale ou reconnaissance faciale, donc il n’y a plus de raison de ne pas verrouiller son écran quand on s’absente », mais dans la réalité cela s’applique très peu aux postes de travail fixes (PC de bureau).
En 30 ans de support terrain, je n’ai vu qu’un seul desktop équipé d’un lecteur d’empreintes.
Il y a aussi très peu de caméras : sur les PC de 5 sites que je gère actuellement, moins de 2 % des machines en ont une.
La reconnaissance faciale ajoute aussi un facteur de rejet pour les utilisateurs.
Nous avons déjà développé une forte méfiance envers la reconnaissance faciale non consentie et dissimulée (caméras de surveillance, écoles, entreprises, police, etc.), et je pense que cet inconfort est parfaitement légitime.
Même quand le matériel m’appartient, les éditeurs conçoivent en pratique des logiciels qui empiètent sur mes droits sans réelle limite morale.
C’est pourquoi je pense que les clés de sécurité sont mieux adaptées aux postes de travail.
Dans le secteur, les politiques de sécurité IT relèvent un peu de la même logique que le vieux mantra « personne ne se fait virer pour avoir acheté IBM » : tout le monde fait seulement comme les autres.
Peu importe que le système soit cassé ou non ; ce qui compte davantage, c’est d’avoir fait « comme c’est écrit dans le livre ».
Le problème, c’est que ce livre (le standard) est un texte très médiocre conçu il y a 30 ans.
Du coup, convaincre un responsable de la sécurité qu’il n’est pas nécessaire de changer de mot de passe tous les trois mois demande une énergie énorme.
Une entreprise cliente impose une limite de session de 30 minutes sur tous ses systèmes.
Je n’aimais déjà pas Jira à la base, mais devoir me reconnecter à chaque fois juste pour consulter un ticket rend le tout insupportable.
Au final, ça me donne surtout envie de lire Hacker News au lieu de travailler.
Heureusement, aujourd’hui la plupart des services gardent au moins le contenu du travail en cache.
Le nom SSO signifie pourtant « SINGLE sign on », mais en pratique on nous demande une authentification répétée sans fin.
Je me demande pourquoi je dois voir un message de demande d’authentification SSO des centaines de fois par jour.
Pour les téléphones, vu le risque de perte ou de vol, je peux encore le comprendre, mais sur desktop, on voit encore souvent des gens quitter un ordinateur partagé (par exemple dans une bibliothèque) sans se déconnecter, et beaucoup d’utilisateurs n’en ont toujours pas conscience.
Dans mon souvenir, SSO voulait dire qu’on se connecte à plusieurs systèmes avec un identifiant unique, pas qu’on ne se connecte qu’une seule fois au sens littéral.