Les 42 nouvelles recommandations de l'ANSSI en matière de mots de passe font évoluer en profondeur celles de 2012 qui ne ciblaient que les seuls utilisateurs. Elles recommandent notamment de ne plus forcer à un renouvellement régulier, ce qui était attendu. Tour d'horizon.
L'ANSSI vient (enfin) de mettre à jour ses recommandations de sécurité relatives aux mots de passe. La précédente édition (1.0) datait en effet de 2012, faisait 10 pages et comportait 8 « recommandations minimales ». Qualifiée de « caduque », elle a « été dépubliée » (mais on la retrouve sur archive.org) à l'occasion de sa mise à jour.
Cette version 2.0 de 52 pages a fait l'objet d'une « réécriture complète », totalise 42 conseils (avec 3 alternatives en plus) et a été réintitulée « recommandations relatives à l'authentification multifacteur et aux mots de passe », pour prendre en considération l'évolution des problématiques en question :
« L'objectif de ce guide est de proposer des recommandations de sécurité relatives à l'authentification en général (recommandations sur le cycle de vie d'un moyen d'authentification quel qu'il soit) et relatives à l'authentification par mots de passe en particulier. »
Dans la version 1.0, l’Agence proposait de les « appliquer indépendamment de tout contexte » et ciblant les seuls utilisateurs. La 2.0 ne leur propose que 7 recommandations (sur 42) et s'adresse surtout aux développeurs, administrateurs, DSI et RSSI, « dans le cadre de la définition des objectifs de sécurité en matière d’authentification ».
Un avant-propos de la CNIL précise que le gendarme des données personnelles y a lui aussi contribué, de sorte de « garantir la sécurité des traitements de données personnelles, en application des articles 5 et 32 du RGPD », qu'il convient d'être « particulièrement vigilant sur la biométrie », et qu'elle rendra publique une mise à jour de sa propre recommandation sur l'usage des mots de passe en 2022.
Placé sous le régime de la Licence Ouverte v2.0 publiée par la mission Etalab, le guide « peut être réutilisé librement, sous réserve de mentionner sa paternité (source et date de la dernière mise à jour) », reproduit, adapté, modifié, transformé, « y compris à des fins commerciales ».
Mots de passe VS coffre-forts
Selon l'ANSSI, « les principales recommandations qui sont mises en avant dans ce guide sont » :
- Mener une analyse de risque lors de la mise en place de moyens d’authentification
- Privilégier l’utilisation de l’authentification multifacteur
- Privilégier l’utilisation de l’authentification reposant sur un facteur de possession
- Adapter la robustesse d’un mot de passe à son contexte d’utilisation
- Utiliser un coffre-fort de mots de passe
Le document débute par un rappel des principales menaces et attaques sur l'authentification, en ligne et hors-ligne, par force brute, rejeu, l'homme-du-milieu, hameçonnage, ingénierie sociale, usurpation d'identité, recherche exhaustive, « password spraying » (à partir d'une liste de mots de passe très utilisés sur un grand nombre d’identifiants possibles), dictionnaire ou tables précalculées comme avec les rainbow tables, etc.
- La petite histoire du mot de passe
- Choisir un bon mot de passe : les règles à connaître, les pièges à éviter
Il dresse ensuite un « aperçu des limites de l'authentification par mots de passe », à commencer par l'erreur consistant à choisir et mémoriser des mots de passe faciles à retenir, donc facilement exploitables par des attaquants, ainsi que l’utilisation d’un même mot de passe sur plusieurs services.
Le guide loue l'utilisation d'un coffre-fort logiciel (gestionnaire), en ce qu'il permet de stocker voire de générer de multiples mots de passe robustes sans que l’utilisateur ait besoin de les mémoriser. Il n'en rappelle pas moins que « ce type d’outil ne permet pas d’empêcher les attaques d’ingénierie sociale comme l’hameçonnage » :
« Ce genre d’attaque permet de récupérer en particulier les mots de passe en usant de moyens détournés : convaincre une personne par téléphone ou courriel d’envoyer son mot de passe, inciter une personne à cliquer sur un lien frauduleux falsifiant une vraie page d’authentification, etc. Également, ces outils restent assez sensibles à la compromission par des logiciels malveillants (comme des enregistreurs de frappe ou keylogger en anglais) des équipements sur lesquels ils sont installés. »
Authentification multifacteur VS double authentification
La première recommandation de l'ANSSI est donc d'opter pour l'« authentification multifacteur », de sorte d'augmenter la sécurité des authentifications par mots de passe : « Ainsi, lors d’une authentification à l’aide d’un mot de passe et d’un autre facteur, même si le mot de passe est compromis, un attaquant doit encore récupérer le ou les autres facteurs afin d’usurper l’identité du prouveur [utilisateur, ndlr] lors de la phase d’authentification ».
Le guide insiste sur le fait que « chacun des facteurs d’authentification mis en œuvre doit appartenir à une catégorie de facteur différente parmi les facteurs de connaissance (« ce que je sais » : code, mot de passe, etc.), de possession (« ce que je possède » : carte à puce, token, téléphone, etc.) et inhérent (« ce que je suis » : ADN, empreinte digitale, rétinienne, voix, frappe au clavier) » :
« L’appartenance à une catégorie différente pour chacun des facteurs utilisés est un point important de cette définition. Une authentification qui nécessiterait un code PIN et un mot de passe ne peut pas être considérée comme multifacteur : les deux facteurs utilisés appartiennent à la même catégorie (facteur de connaissance) et sont donc sujets aux mêmes menaces. »
L'ANSSI distingue ainsi la « double authentification », qui repose sur l’utilisation de plusieurs facteurs appartenant à la même catégorie, de l'« authentification multifacteur ». Elle reconnait cela dit que, « selon le contexte de la mise en œuvre », la double authentification peut tout de même permettre d’améliorer la sécurité apportée par l’authentification via un unique facteur.
Le guide précise ensuite les emplois de ces différents types de facteurs. Les codes PIN et mots de passe ne doivent ainsi être connus que de leurs seuls propriétaires. De son côté, le vérifieur ne doit connaître qu'une version « non réversible » de ce facteur, comme l’empreinte d’un mot de passe calculée au moyen d’une fonction de hachage cryptographique, dédiée au stockage des mots de passe.
Afin de garantir la sécurité des facteurs « de possession » (cartes à puce ou cartes SIM, dispositifs One Time Password – OTP), l'ANSSI estime « essentiel que des moyens de protection et de détection contre les tentatives de reproduction ou de falsification du facteur soient mis en place ».
Enfin, les facteurs inhérents permettant d’identifier une personne de façon unique au moyen d’attributs physiques (empreintes, iris, visages, etc.) doivent être différents d’une personne physique à l’autre, « y compris lorsque des personnes physiques présentent des caractéristiques similaires (par exemple des jumeaux ou jumelles) ».
Authentification forte VS authentification multifacteur
L'ANSSI relève en outre qu'« en langue française, l’authentification multifacteur est souvent confondue avec l’appellation authentification forte (ou robuste), ce qui laisserait entendre qu’une authentification multifacteur est nécessairement plus robuste qu’une authentification avec un unique facteur ».
Ces facteurs, pris indépendamment ou ensemble, ne sont pas forcément considérés comme forts. Par exemple, un mot de passe associé à un code temporaire reçu par SMS, pourrait être intercepté ou faire l'objet d'une usurpation de type « SIM swapping ». L'ANSSI estime même qu'« une méthode d’authentification reposant sur la réception d’une valeur (comme un code à usage unique) au moyen d’un canal peu ou pas sécurisé (comme le SMS) est à proscrire », ce qui fait l'objet de sa 8e recommandation.
Cela l'incite à « différencier une authentification multifacteur "faible" d’une authentification multifacteur forte lorsque cette dernière fait intervenir au moins un facteur d’authentification considéré comme fort ».
Afin d’être considérée comme forte, une authentification doit dès lors reposer sur un protocole cryptographique de type défi-réponse permettant de résister aux attaques mentionnées. Citons l'authentification par certificats (stockés dans des cartes à puce par exemple), les protocoles FIDO2 et FIDO U2F, OTP comme HOTP (HMAC-based OTP), TOTP (Time-based OTP) ou OCRA (OATH Challenge-Response Algorithm).
La deuxième recommandation est dès lors de « privilégier l’utilisation de moyens d’authentification forts reposant sur des mécanismes cryptographiques conformes au référentiel général de sécurité (RGS) et à ses annexes » (R2).
Conduire une analyse de risque
L’ANSSI précise ensuite que « l'authentification est un mécanisme fortement dépendant du contexte dans lequel il est mis en œuvre » :
« Ce contexte peut être varié et de nombreux paramètres entrent en jeu comme le niveau de sensibilisation des utilisateurs à la sécurité, le niveau de sensibilité des données ou des services à protéger, l’importance des menaces pesant sur les données à protéger, le niveau de compétence des différentes personnes impliquées dans la gestion du système d’information ou le niveau de complexité d’utilisation des différents moyens d’authentification mis en place, etc. »
Les recommandations doivent donc s'adapter aux cas d'usage et aux contextes d'utilisation, en tenant compte « des menaces potentielles, de la criticité du service ou des informations traitées par ce dernier et de son niveau d’exposition aux menaces ». Ce pourquoi la troisième recommandation est de « mener une analyse de risque pour déterminer les moyens d’authentification à mettre en œuvre en fonction du besoin de sécurité ».
Mais attention : « l'authentification multifacteur ne doit pas donner un faux sentiment de sécurité », car elle « n’empêchera nullement un attaquant d’utiliser un canal de connexion déjà ouvert vers ce service si jamais, par exemple, le poste est compromis ».
Changer régulièrement les mots de passe est « contre-productif »
Elle relève également que « mettre en place des moyens d’authentification trop contraignants par rapport à l’information ou au service à protéger pourrait se révéler contre-productif puisque les utilisateurs chercheraient à contourner les moyens mis en place » :
« Par exemple, un renouvellement de mots de passe trop fréquent pourrait inciter les utilisateurs à noter les mots de passe sur une feuille, qui ne sera pas nécessairement conservée en lieu sûr. »
Une position qui tranche avec la précédente version du guide de l'ANSSI, qui recommandait : « renouvelez vos mots de passe avec une fréquence raisonnable. Tous les 90 jours est un bon compromis pour les systèmes contenant des données sensibles ». Le guide précise que « le choix d’imposer ou non un délai d’expiration fixe est un sujet qui a évolué ces dernières années ». Qualifié de « bonne mesure en général », cela s'avère « souvent contre-productif dans le cas des mots de passe » :
« En effet, en imposant un délai d’expiration trop réduit sur les mots de passe, les utilisateurs ont tendance à créer des itérations sur leurs mots de passe (par exemple rajouter "+1" sur un nombre contenu dans le mot de passe comme Toto1, Toto2, etc.) ou à créer des liens logiques triviaux entre les différents mots de passe. »
De plus, de nombreux moyens permettent de s’assurer que les utilisateurs choisissent des mots de passe robustes (contrôle de leur robustesse à la création, utilisation de coffre-fort de mots de passe, etc.) qui, « lorsqu’ils sont mis en œuvre, ne justifient plus le besoin d’imposer un délai d’expiration ».
L'ANSSI recommande dès lors de « ne pas imposer par défaut de délai d'expiration sur les mots de passe des comptes non sensibles comme les comptes utilisateur » (R24), et de ne l'imposer que sur les mots de passe des « comptes très sensibles comme les comptes administrateurs » ne bénéficiant pas d'authentification à double facteur, « pour une durée comprise entre 1 et 3 ans » (R25). A contrario, le guide recommande de « révoquer immédiatement (de l’ordre de la journée) les mots de passe en cas de compromission suspectée ou avérée » (R26).
L'ANSSI recommande de « mettre à disposition des utilisateurs un coffre-fort de mots de passe », tel que Keepass, mais également qu'ils soient formés à son utilisation (R31). Il s'agit non seulement d'expliquer l'intérêt (et les modalités, à commencer par la gestion du mot de passe « maître ») d'un tel stockage sécurisé, mais également de la possibilité offerte de « générer des mots de passe longs et complexes (sans avoir besoin de les mémoriser ni même d’en prendre connaissance) ».
Ne changez qu'en cas de suspicion de compromission
Le NCSC, équivalent britannique de l'ANSSI, déconseille lui aussi, depuis 2015, de forcer les utilisateurs à changer fréquemment de mot de passe, au motif que « c'est l'un de ces scénarios de sécurité contre-intuitifs ; plus les utilisateurs sont obligés de changer de mot de passe, plus la vulnérabilité globale aux attaques est grande » :
« Le nouveau mot de passe peut avoir été utilisé ailleurs, et les attaquants peuvent également l'exploiter. Le nouveau mot de passe est également plus susceptible d'être écrit, ce qui représente une autre vulnérabilité. Les nouveaux mots de passe sont également plus susceptibles d'être oubliés, ce qui entraîne des coûts de productivité pour les utilisateurs bloqués sur leurs comptes et les centres de services devant réinitialiser les mots de passe. »
De plus, les utilisateurs, régulièrement obligés de changer leur mot de passe, en choisiront souvent un « plus faible » qu'ils n'oublieront pas, élargissant la surface d'attaque. Dans ses recommandations mises à jour, le NCSC écrit même que « le changement régulier de mot de passe nuit au lieu d'améliorer la sécurité », et que « forcer l'expiration du mot de passe ne présente aucun avantage réel car » :
- l'utilisateur est susceptible de choisir de nouveaux mots de passe qui ne sont que des variations mineures de l'ancien ;
- les mots de passe volés sont généralement exploités immédiatement ;
- la réinitialisation du mot de passe ne permet pas de savoir si un compromis s'est produit ;
- un attaquant ayant accès au compte recevra probablement également la demande de réinitialisation du mot de passe ;
- s'il est compromis via un stockage non sécurisé, l'attaquant pourra trouver le nouveau mot de passe au même endroit.
Le NCSC recommande plutôt de verrouiller automatiquement les comptes inactifs, surveiller les connexions suspectes (heures de connexion inhabituelles, via de nouveaux appareils), d'encourager les utilisateurs à signaler quand quelque chose est suspect et, bien évidemment, l'authentification multifactorielle. Pour lui, les utilisateurs ne devraient modifier leurs mots de passe que « lorsque vous savez (ou soupçonnez) qu'il a été compromis ».
Minimiser les risques de compromission
La 9e recommandation porte à ce titre sur la conservation des historiques d'utilisation des facteurs d'authentification pour « faciliter la détection de comportements anormaux qui présagerait d’une compromission ».
Il convient en outre de limiter dans le temps le nombre de tentatives d'authentification (R10), de réaliser l'authentification au travers d'un canal sécurisé (R11), de limiter la durée de validité d'une session authentifiée (R12), mais également de ne pas donner d'information sur l'échec de l'authentification (R14) pour ne pas fournir d’information supplémentaire à un attaquant.
Afin de limiter les dégâts en cas de compromission non détectée d’un facteur d’authentification, l'ANSSI recommande de mettre en place un délai d’expiration des facteurs d’authentification, permettant de limiter une éventuelle période d’utilisation frauduleuse (R15), de définir une politique d'utilisation des facteurs d'authentification – notamment en cas de perte ou de compromission (R16) – et de sensibiliser les utilisateurs à la sécurité de l'authentification, par exemple des campagnes de sensibilisation au hameçonnage (R17).
Elle recommande en outre un processus de révocation des facteurs d'authentification (R18) et de définir des délais de prise en compte des révocations adaptés aux menaces pesant sur le système d’information (R19).
Un nombre limité de mots de passe à mémoriser
Signe du virage à 180° de l'approche de l'ANSSI, ses recommandations relatives à la bonne utilisation des mots de passe n'arrivent qu'au chapitre 4, page 26. Elle y distingue trois catégories de codes PIN, mots ou phrases de passe :
- ceux qui ne peuvent pas facilement être gérés par un coffre-fort logiciel, comme le mot de passe maître de ce dernier, le mot de passe d’une session Windows, etc. :
« Ces mots de passe doivent être mémorisés et suffisamment robustes au vu de leur criticité, mais ils sont peu nombreux à retenir. Cette catégorie de mot de passe étant la plus critique, il est pertinent qu’elle soit associée à un second facteur d’authentification. »
- ceux pouvant ne pas être mémorisés comme les mots de passe générés et conservés par des coffres-forts logiciels ;
- les codes PIN que l’on retrouve dans les cartes à puce dont les cartes SIM, et qui sont « accompagnés de mesures très restrictives sur le nombre d’échecs d’authentification autorisés ».
Cette catégorisation permet à l'ANSSI de « mettre en lumière le fait que parmi tous les mots de passe utilisés au quotidien, il n’y en a qu’un nombre limité qui doivent être mémorisés par un humain ».
L'entropie ? Le petit bout de la lorgnette
« La sécurité des mots de passe est souvent réduite à l’estimation de leur "force", c’est-à-dire l’estimation de leur entropie exprimée en bits », relève en outre l'ANSSI. Elle « peut être estimée en calculant l’ensemble des mots de passe possibles pour une longueur donnée et une complexité donnée ».
Or, cette approche serait biaisée, car « cette estimation ne vaut que si chaque caractère du mot de passe est choisi de manière uniformément aléatoire ». Ce qui n'est pas le cas lorsque l'utilisateur choisit lui-même ses mots de passe, souvent dérivés de termes du langage courant ou de mots de passe pré-existants dans des dictionnaires.
De plus, si « l'entropie est une métrique simple d’utilisation », elle « ne permet pas de capturer la sécurité apportée par les nombreuses autres mesures additionnelles qui doivent être définies dans une politique de sécurité des mots de passe comme la limite du nombre d’essais, la méthode de conservation des mots de passe, etc. ».
Mots de passe VS phrases de passe
La 20e recommandation va dès lors bien au-delà des sempiternels caractères en majuscules, minuscules, spéciaux et/ou accentués, préférant prendre en compte l'ensemble du spectre d'une « politique de sécurité des mots de passe ». L'ANSSI, renvoie à sa page permettant de calculer la force d’un mot de passe et rappele qu'« il est souvent plus efficace d’allonger un mot de passe que de chercher à le rendre plus complexe pour en augmenter l’entropie ».
Elle recommande dès lors d'imposer une longueur minimale pour les mots de passe lors de leur création en fonction du niveau de sécurité visé par le système d’information (R21) : entre 9 et 11 pour les niveaux de sensibilité faible à moyen, entre 12 et 14 pour les niveaux moyen à fort, et au moins 15 pour les niveaux fort à très fort (où il est par ailleurs recommandé d’utiliser l’authentification multifacteur), voire plus encore :
« Ces exemples de longueurs minimales concernent surtout les mots de passe devant être mémorisés par un humain. Pour ceux ne devant pas être mémorisés, il est recommandé que la longueur minimale soit très grande (supérieure à 20 caractères par exemple). »
L'Agence tempère cela dit cette recommandation en précisant que « ces valeurs minimales de longueur peuvent être adaptées » pour les codes PIN « qui sont accompagnés de fortes mesures complémentaires (comme une désactivation d’accès définitive au compte au bout de trois échecs d’authentification) ».
Elle propose également d'adapter certaines mesures complémentaires (comme imposer des caractères spécifiques) en fonction de la taille du mot de passe choisi par l’utilisateur :
« Un utilisateur choisissant un mot de passe très long (comme une phrase de passe de 20 caractères et plus) ne se verrait pas imposer de contraintes sur les caractères à utiliser alors qu’un utilisateur choisissant un mot de passe court (une dizaine de caractères) se verrait imposer l’utilisation de chiffres et de caractères spéciaux. »
Elle recommande en tout état de cause de « ne pas fixer de limite à la longueur maximale d’un mot de passe afin de permettre aux utilisateurs d’avoir recours à des phrases de passe ou longs mots de passe » (R22).
Il lui paraît néanmoins raisonnable de « fixer une valeur limite (plusieurs centaines de caractères par exemple) afin de ne pas s’exposer à de potentielles attaques en déni de service (qui consisterait à soumettre des mots de passe de plusieurs Mo au vérifieur et pouvant prendre plusieurs minutes à traiter) ».
Les phrases de passe plus simples à mémoriser
L'ANSSI qualifie par ailleurs de « mauvaise pratique observée » le fait de fixer une longueur maximale faible de 8 ou 10 caractères par exemple : « cette pratique empêche l’utilisation de phrases de passe [qui] consistent à choisir aléatoirement un certain nombre de mots parmi un corpus déterminé (comme le dictionnaire de la langue française). À entropie égale, les phrases de passe sont souvent bien plus longues que les mots de passe "classiques", mais sont aussi pour certains utilisateurs plus simples à mémoriser ».
Crédits : xkcd, Traduction : Next INpact.com
Elle recommande de « mettre en œuvre des règles de complexité tout en proposant un jeu de caractères le plus large possible » (R23), en imposant par exemple que les mots de passe « contiennent au moins une majuscule, un chiffre et un caractère spécial », afin d'éviter que les utilisateurs ne choisissent « des mots de passe trop simples (des mots du dictionnaire français par exemple) » :
« Ce type de règles se trouve en pratique souvent détourné par les utilisateurs : transformation de a en @, de o en 0 (par exemple le mot de passe "password" va être remplacé par "Passw0rd", "P@ssw0rd", "PaSSword1", "p4ssw0rd" et des dizaines d’autres possibilités), rajout d’une majuscule en début de mot de passe, rajout d’un chiffre en fin de mot de passe, etc. »
Si ce type de contre-mesure « n’apporte en pratique qu’assez peu de sécurité contre des attaques hors ligne, où il est possible de créer des dictionnaires dédiés », l'ANSSI note cela dit qu'elle « permet d’augmenter significativement la protection contre des attaques en ligne ».
Le stockage des mots de passe en clair doit être proscrit
Le guide recommande également de « mettre en place un contrôle de la robustesse des mots de passe lors de leur création ou de leur renouvellement » (R27), en les comparant avec une base de données répertoriant les mots de passe les plus utilisés ou bien ceux qui ont été compromis, et d'interdire la réutilisation d’un mot de passe parmi les X derniers mots de passe déjà utilisés.
Il s'agirait aussi de repérer les mots de passe contenant des motifs (ou des répétitions de motifs) spécifiques (comme une suite de chiffre telle que « 12345 », la suite des premières lettres des claviers comme « azerty », etc), des informations personnelles comme les noms, prénoms ou dates de naissance
L'ANSSI relève cela dit que « les produits logiciels actuellement disponibles pour la mise en pratique de cette recommandation sont rares ». Le guide ajoute qu'il est important de fournir aux utilisateurs des ressources leur permettant de générer des mots de passe robustes comme des coffres-forts ou des outils d’assistance à leur génération et mémorisation (« comme l’outil de la CNIL »).
L'Agence attire également l'attention sur le fait qu'une analyse de la base de données contenant les mots de passe au moyen d’outils de « cassage » comme John The Ripper – pour vérifier leur robustesse a posteriori – est « délicate à mettre en œuvre de manière sécurisée car elle présente de nombreux risques » :
« la base de mots de passe doit être extraite d’une zone protégée et journalisée vers une autre zone potentiellement moins bien protégée, les personnes responsables de ce traitement pourraient être malveillantes et tirer profit des informations extraites, etc. »
Seules les empreintes, « aussi appelées hachés, résultats d’une fonction de hachage cryptographique (comme les familles SHA2 ou SHA3) appliquée aux mots de passe », doivent être stockées.
Pour que ce stockage soit effectuée « de manière sécurisée », l'ANSSI recommande d'y ajouter « une valeur aléatoire unique (communément appelée un sel) lors du calcul de l’empreinte du mot de passe », afin de se prémunir contre des attaquants utilisant des tables pré-calculées (R28).
Pour « ralentir les attaquants », elle recommande en outre d’« utiliser des fonctions de dérivation de mots de passe memory-hard comme scrypt ou Argon2 », voire PBKDF2 lorsqu'il est « difficile de faire usage de fonctions memory-hard » (R29). Les méthodes de recouvrement d'accès (en cas d'oubli ou d'expiration) sont si diverses (réception d’un mot de passe temporaire autogénéré, d’un lien temporaire à usage unique de réinitialisation, par courriel, SMS, envoi postal, téléphone, etc.) que « cela rend très difficile la recommandation d’une méthode en particulier ».
Éviter de transmettre les mots de passe en clair
Il faut attendre la page 35 du guide pour en venir aux sept « recommandations à destination des utilisateurs » :
- utiliser des mots de passe (ou phrases de passe) robustes, c’est-à-dire suffisamment longs et complexes pour résister aux attaques par recherche exhaustive et n’étant pas un mot du dictionnaire (ou une citation ou phrase connue) pour résister aux attaques par dictionnaire (R32) ;
- utiliser un mot de passe différent pour chaque service afin de limiter les conséquences en cas de compromission d’un mot de passe (R33) ;
- utiliser un coffre-fort de mots de passe permettant facilement de générer des mots de passe robustes et différents pour chaque service (R34) ;
- adopter les bons réflexes de protection des mots de passe : « par exemple, il est impératif de ne pas écrire ses mots de passe sur une note sous le clavier, de ne pas créer un fichier "mot de passe" sur le poste utilisateur, de ne pas s’envoyer ses mots de passe par courriel, etc. » (R35) ;
- utiliser un mot de passe robuste pour accéder à sa messagerie électronique, et privilégier l’utilisation d’une méthode d’authentification multifacteur lorsque cela est disponible (R36) ;
- choisir un mot de passe sans information personnelle comme les noms et prénoms ou encore la date de naissance (R37) ;
- modifier les mots de passe par défaut (R38).
En comparaison des huit précédentes recommandations de 2012, l'ANSSI ne déconseille plus de demander à un tiers de générer pour vous un mot de passe, de s'envoyer ses propres mots de passe sur sa messagerie personnelle ou d'activer la fonction « se souvenir de ses mots de passe » d'un navigateur. Mais elle privilégie le recours à des coffre-forts logiciels qui, contrairement aux navigateurs, sont protégés par un mot de passe maître.
Ses recommandations finales portent sur les avantages et inconvénients des facteurs de possession (qui doivent avoir reçu un visa de sécurité de l’ANSSI, ou utiliser un protocole d’authentification conforme au RGS), et inhérents. Elle déconseille à ce titre la biométrie « lorsqu’il s’agit d’une authentification avec un unique facteur ».
Commentaires (62)
#1
Très bon article.
#2
Yes, bon article.
La plus part des RSSI n’ont je pense pas attendu l’ANSSI pour faire la plupart de ces constats en tous cas.
Attendre 10 ans presque pour faire de nouvelles recommandations sur le domaine, c’est un peu léger d’ailleurs non ?
#3
Ça tombe bien je l’ai lu rapidement il y a quelques jours. Je finis de lire votre article mais je me pose une question pour les admins Windows. Je souhaiterai déployer Windows Hello for Business pour une partie de la population. Est-ce considéré comme multi-facteur ? Car je dois pouvoir convaincre mon manager et DSI
Car pour déverrouiller, il faut la connaissance (Pin) ou inhérents (Empreinte) afin que la puce TPM délivre la clé authentification. Est-ce que la Puce TPM qui a la clé peut-être considéré comme possession ? Comme le montre l’exemple avec carte à puce + PIN.
Je suis en train de tester la méthode cloud trust pour ceux qui connaissent (pas la version certificat ou key trust)
#3.1
C’est effectivement considéré comme un second facteur, puisque le TPM n’est pas (sous réserves) altérable.
Après, certains standards (notamment NIST SP 800-53, exigence IA-2) demandent à ce que les facteurs d’authentification soient découplés physiquement entre eux (via smartcard ou token de sécurité, par exemple). C’est à prendre en compte si vous voulez vous faire auditer et/ou certifier.
#3.3
Ok. Je vois mais c’est complexe de dissocier car il y a que les clés de sécurités USB et NFC. Pour que cela fonctionne partout et il faut bien sûr un tel NFC. Principalement en FIDO2
Tu peux cibler les utilisateurs. Ils ont du appliquer à la machine ce qui oblige à tout personne qui se connecte à s’enrôler ce qui n’a pas tester en profondeur.
Pour le Pin obligatoire c’est voulu.
https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-why-pin-is-better-than-password
#3.2
Au boulot ils ont activé Windows Hello, mais on n’arrive pas a enlever le code PIN. C’est le seul moyen qu’il n’est pas possible de supprimer, c’est une aberration complète.
En plus, de base, le code PIN demandé est de seulement 6 chiffres.
Résultat, si on veut se connecter au PC d’un collègue, il suffit de regarder son clavier lorsqu’il déverrouille son ordi et le tour est joué.
Comme la création du code PIN est obligatoire, même l’admin qui vient se connecter sur la machine pour résoudre un problème doit créer un PIN pour son compte, compte qui aura les droits admin.
On a fait le test, le PIN est bien unique (=valable uniquement sur la machine et ne peut pas être réutiliser ailleurs sauf si l’admin utilise le même PIN sur différentes machines), mais du coup il est super simple de se connecter avec un compte admin et ensuite de faire ce que l’on veut sur la machine.
Perso, j’ai vu qu’il y avait un bouton pour demander à mettre autre chose que des chiffres, j’ai donc créé un PIN impossible à mémoriser (35 caractères générés par keepass) et je n’utilise pas le PIN pour me connecter.
Si quelqu’un sait comment bannir le code PIN de Windows Hello, je suis preneur!
#4
Merci pour l’article. Les recommandations sont enfin pertinentes. Merci pour la traduction xkcd !
Ce document est très orienté SI. Connaissez-vous un guide grand public pour faciliter la formation des employés d’une petite entreprise sur ces sujets ? Je souhaiterai que tout le monde utilise un mot de passe fort (plutôt une phrase de passe), utilise un gestionnaire de mot de passe pour les comptes sur les sites internet, et active un 2nd moyen d’authentification pour certains services (messagerie, cloud). Le problème c’est que c’est pas évident de communiquer et former sur ce sujet sans y passer énormément de temps, que je n’ai pas. Et je ne trouve pas de support adapté sur les sites (c’est toujours des documents pour les responsables informatiques).
#4.1
https://secnumacademie.gouv.fr/ est un bon mooc fait par l’ANSSI
#5
“On_nous_ballade_dur” c’est un bon mot de passe.
Ripper proof.
#6
Et sinon, ils pensent quoi des banques et de leurs claviers virtuel tout pétés qui bloquent les gestionnaires de mots de passe, et forcent des mots de passe à 8 chiffres au mieux ?
#7
oui, Excellent artcicle.
Pour rajouter un complément d’info, les plateformes Azure AD permettent d’implémenter des règles qui bannissent les mots de passe simples ou via une base de donnée usuelle. Cela permet d’éviter que les utilsateurs tombent dans le piège de garder des mots de passe simple et utilisé partout ailleurs.
Par contre, le NIST américain propose depuis plusieurs années de ne plus changer les mots de passe et Microsoft s’y était mis aussi avec ses recommendations dans son centre de sécurité (pour peu que les règles de Condtionnal Access soient en place pour forcer le MFA par défaut pour toutes connections externes).
Si Windows Hello for Business est activé, alors, cela devient plus simple à gérer au niveau du tenant.
Reste à expliquer aux users que la caméra infra-rouge sur leur laptop n’est pas là pour les enregistrer et d’enlever leur morceau de scotch dessus, de fois qu’on les filme :-)
Apres Windows 11 va sans doute orienter le marché dans ce sens (pin-code, lecteur d’empreinte/ camera IR pour se logger sur Windows). D’où les soucis actuellement de compatibilité car pour le grand public, c’est loin d’être acquis d’avoir accès à tous ces méchanismes sur leur machine à la maison. Au bureau, c’est différent. Le covid a malheureusement permis de mettre à jour pas mal de flotte d’entreprise et les nouveaux laptops depuis plusieurs années, ont au moins une methode d’authentification forte matériel (TPM2.0) de disponible.
Le Lien NIST qui préconise de ne pas changer de mot de passe souvent si celui-ci est “fort” (2017…)
https://www.nist.gov/video/password-guidance-nist-0
#7.1
Par curiosité… à quoi sert la caméra infrarouge du coup ? A vérifier que quelqu’un est bien devant le poste (à l’opposé de quelqu’un qui s’y connecterait à distance) ? A le verrouiller automatiquement ?
#8
Super news, vivement que les SI ce mettent à jours. Je suis presta en ESN, ma boite et mon client ont cette règle de forcer le changement de mdp tout les 3 mois…
Autant pour ma boite c’est pas trop relou car j’y accède via du web donc password dans keepass, mais pour mon client avec le PC fournis par le client, ben c’est mon mdp de session windows que je dois changer tout les 90 jours…
et ils gardent un historique de je ne sais pas combien de mdp (2 ans que j’y suis et je n’ai toujours pas pu cycler). ça commence à devenir compliqué de trouver de nouvelles idées dont je suis capable de me souvenir…
Anecdote véridique: j’en ai discuté avec un collègue et lui demandé comment il faisait. Il m’a répondu que l’astuce d’un peu tout le monde était d’utiliser un incrément à la fin de leur mdp 😭.
Du coup je me pose sérieusement la question de le faire aussi 😬
#8.1
ça ou inclure mois + année à la fin du pass.
l’expiration c’est totalement débile, tout le monde le sait, tout le monde contourne de la même façon (incrément ou date qui change).
que cette injonction stupide perdure depuis des lustres me fait halluciner.
#9
Sur les banques Françaises, il faut quand même un deuxième code PIN (sécurpass, sécuripass, ou autre nom), pour n’importe quel opération importante (ajout bénéficiaire, virement, etc..), sachant que la plupart des ses opérations sont également notifiées mail + sms.
Personnellement, je n’ai pas envi d’ouvrir mon gestionnaire de mot de passe ou entrer un passe à 20 caractères à chaque fois que je veux consulter mes comptes depuis mon tel.
#10
Ce qui est drôle, c’est la politique de mots de passes de certains sites comme:
Ils feraient donc mieux de tester l’entropie plutôt que des nombres de caractères et présence de caractères “non naturels” quand on fait un nouveau mot de passe
#10.1
Tellement vrai!
En général quand un site refuse certains types de caractère ou a une taille maximum de mdp, je me dit :
Dans les 2 cas, je ne m’inscrit pas et je cherche un site équivalent.
#11
Et dire que pas plus tard que la semaine dernière, un site internet m’a refusé mon mot de passe parce que “trop long”…
(alors que généré par un gestionnaire avec des règles standard !)
#11.1
alors le pire c’est ceux qui ne te disent rien, ou qui ont un script de vérification du pass pété.
par exemple Norauto, tu crées un compte avec un pass long, pas de problème. par contre tu rencontres une erreur à la connexion après. jme suis arraché les cheveux.
et j’arrive pas à comprendre comment ça peut merder. ils doivent avoir un algo de hashage aux fraises. ou alors ils hashent pas.
#12
Firefox propose un mot de passe maître (appelé mot de passe principal)et il me semble que Mozilla avait fait évolué la technique de chiffrement de la base de données des mots pour mieux sécuriser cela.
https://support.mozilla.org/fr/kb/gestionnaire-mots-passe
Firefox porpose aussi de solliciter le mot de passe de Windows ou Mac Os pour accéder à la gestion des mots de passe: https://support.mozilla.org/fr/kb/lockwise-authentification-mot-de-passe
#13
Le clavier virtuel utilisé par les banques est une contre-mesure visant la principale menace liée au mots de passe : les enregistreurs de frappe clavier (keyloggers, quoi).
Pour le code PIN, il est bien dit dans la note de l’ANSSI, page 18 :
On peut accepter une baisse de la complexité à condition qu’il y ait d’autres mesures comme le blocage après un certain nombre de tentatives. Il ne faut pas oublier l’expérience utilisateur : vous imaginez une mamie devant taper une passphrase ou un mot de passe de 20 caractères pour se consulter son compte en ligne ? Pour les banques, il s’agit d’un blocage au bout de 3 ou 5 tentatives, par exemple. Et pour rappel, avec un code PIN, il n’y a pas d’attaque par dictionnaire, on ne peut faire que de la force brute (à partir de l’interface du client). Et enfin, avec la DSP2, l’authentification multifacteur est désormais obligatoire.
Que les claviers virtuels bloquent les gestionnaires de mot de passe est au contraire une bonne mesure de sécurité contre les keyloggers et les malwares capables de rejeu. Sans rentrer dans les détails, cela rend (par exemple) inutile qu’on enregistre vos frappes clavier ou de prendre en vidéo le déplacement de votre souris pour rejouer votre code puisque l’emplacement des chiffres change à chaque fois (ainsi que le nom des zones HTML derrière, etc.).
Donc j’insiste : le clavier virtuel même avec un code PIN est une bonne mesure de sécurité qui augmente la couverture des risques puisqu’elle atténue (sans faire disparaître toutefois) la menace des keyloggers et autres enregistreurs d’interface.
#13.1
Et il n’existe aucun keylogger qui prendrait des screen du clic de la souris ?
#14
Sur la partie Windows AD, il y a des outils qui peuvent éviter ce genre d’habitudes à incrémenter des chiffres ou lettres. Par exemple Specops qui permet des règles du genre : au changement de mot de passe, tu ne peux pas avoir 3 caractères qui se suivent identiques aux 15 précédents par exemple.
Mais du coup, tu entres dans la problématique de se creuser pour trouver un nouveau passe à chaque fois et qu’il fini inscrit en clair sur un papier ou sur le téléphone…
Ah mais je suis totalement d’accord, c’est ce que je disais ;)
Il faut toujours penser à l’expérience utilisateur et au suivi technique/assistance ; ne pas suivre bêtement les préconisations.
Mettre de la complexité et de la double authentification partout n’est pas toujours une solution. Si tu te retrouve avec des utilisateurs perdus qui ne font que verrouiller leur compte, oublier leur téléphone ou carte pour la double Authentification, etc… ca devient contre-productif. Il faut un juste milieu.
Personnellement, j’ai plusieurs banques, et dans les appli bancaires, il y en a qui sont bien plus pratique que d’autres, et ca compte beaucoup je trouve quand on s’y connecte tous les jours comme moi, il faut que ca reste simple et rapide pour s’authentifier juste pour consulter.
#15
La technique est loi d’être idiote:
C’est bien mieux qu’on code pin sur un tél avec des doigts gras :)
#16
Moi ce qui m’énerve c’est lorsque les banques prennent le prétexte que les SMS sont pas sur pour nous imposer leur appli énorme, buggé jusqu’à l’os, qui marche que sur des téléphones non flashés (*) et qui demande toute les permissions possible et imaginable.
Alors que le SEUL but, et c’est ainsi qu’elles le vendent à leur investisseur, c’est de tracker les clients pour remplir leur base d’infos valorisable auprès des publicitaires.
(*) Tel que Lineage par ex - ce qui fait que des téléphones vieux mais à jour au niveau sécurité sont refusé là où de vieux téléphones non supporté (et donc plus mis à jour) sont vulnérables.
Alors oui, ptet que les SMS sont pas sur - il me semble pas qu’en France (contrairement aux USA) on ai eu de grosses histoires de détournement SS7 (sauf attaque ciblée) pour que le “pirate” reçoive le SMS à ta place. Peut-être que le problème sera alors de sécuriser le SS7, ce qui, en plus permettrait d’éviter les appels de “jean-claude” depuis ouagadoudou avec un numéro en 01 pour te vendre le dernier scam bitcoin à la mode.
Accessoirement un SMS rare sont les gens qui ne peuvent pas en recevoir, alors qu’une appli je connais plein de gens qui ne peuvent pas en installer sur leur téléphone : Trop vieux, pas assez de mémoire (surtout que les appli bancaires, avec tous ces mouchards, sont pas légères), appli qui plante ou bugge, pas de data sur le téléphone,… bref.
#16.1
Et la banque t’impose de t’abonner à Apple ou à Google pour utiliser leur application alors que rien dans le contrat te l’impose.
Bizarement cette problématique de devoir créer un compte Google, Apple, ou MS pour télécherger et utiliser un programme n’émeut pas les politiques qui aiment tirer sur les GAFAM & Co.
#17
La caméra “évoluée” avec lecture infraarouge permet à Windows de faire la reconnaissance faciale (données stockées en local dans la puce TPM avec un code PIN) et d’être sûr que c’est pas une photo de la dite personne qui est présentée devant la caméra. La partie infra-rouge permet de s’assurer que la personne est bien vivante lorsqu’elle s’authentifie.
Cette caméra ne s’active que lors de l’authentificaiton de l’utilisateur.
Autre options, les empreintes si le pc a un lecteur d’empreinte intégré.
Après, il y a d’autres moyens de garder la sessions ouverte avec une association à un téléphone mobile (bluetooth). de l’utilisateur. Quand tu quittes ta place de bureau avec ton mobile, cela bloque la session en cours car la distance d’apparage augmente. C’est des petits gadgets mais qui peuvent être bien utiles pour les utilisateurs étourdis.
On arrive in fine à avoir 4-5 methodes d’authentification pour les utilsateurs (mot de passe, pin code, camera, empreintes digitales et même photo/zone à choisir), . Il manque encore le support FIDO2 natif (clé Yubikey par example) pour débloquer sa session Windows. Cela devrait arriver, d’après Microsoft depuis l’année dernière… Peut être avec Windows 11 ?
#18
Je ne pense pas que ce soit le but premier de forcer l’usage et l’installation de leur application.
Dans tous les cas, le SMS n’est pas sécurisé, c’est un fait… A partir de là, soit tu fais une validation par mail qui n’est pas plus sécurisée… Soit c’est une validation physiquement ou oralement donc contraignante.
Sans passer par leur application, le SMS ou le mail, ça se complexifie quand même peu… Ça voudrait dire dépendre d’un service tiers genre une application d’authentification. Je ne suis pas sûr que d’utiliser Google Authentificator pour sa banque ce serait mieux…
Ce mode de fonctionnement est clairement discriminatoire s’il oblige d’avoir un smartphone récent, on est bien d’accord… (cela dit, le SMS aussi…)
Certaines banque proposent des boitiers, mais je crois que c’est payant (ce qui est dingue quand même… tu n’as pas les moyens de changer de smartphone, mais tu dois te payer un boitier pour la double authentification).
C’est plus vraiment des keylogger dans ce cas :)
#19
“Changer régulièrement les mots de passe est « contre-productif »”
amen
“les phrases de passe…mais sont aussi pour certains utilisateurs plus simples à mémoriser”
On dirait que ces utilisateurs sont l’exception.
Je pense au contraire que ces phrases sont plus simples à mémoriser.
#20
Quelqu’un a décidé que les espaces réduisent la sécurité des mots de passe et cette légende a la vie dure.
Certes si en même temps on limite le mot de passe à 8 caractères.
#21
Certains généralisent l’idée de keylogger à tout logiciel espion (donc ne se limitant pas à l’enregistreur de frappe).
#22
Tu as des pointeurs sur le sujet , avec des exemples d’exploit ?
J’en ai bcp lu aux USA mais pas trop en France.
On répète ça tout le temps, mais jusqu’à maintenant je l’ai jamais trop lu.
C’est “juste” parce que c’est pas chiffré ? (Ca me gêne moins quand ce sont des codes à usage unique et avec une validité temporelle limitée).
Alors oui, après, évidemment si tu te fait voler ton tel non verrouillé.. et/ou que t’a pas changé le code pin…
Ou alors une attaque ciblée par une team gouvernementale. Je dis pas.
Mais là on parle d’éviter le piratage par des mails de fishing plein de fautes envoyés à la chaîne par des bots africains ou ukrainiens….
Voila. Encore que souvent le IMAP est, lui, chiffré, mais bon…
Ben moi je trouve pas , surtout que les gens s’y sont fait.Beaucoup moins qu’utiliser une mauvaise appli en tous cas.
j’avoue que ça me plairais pas non plus sur le fond.
Tu peux recevoir un SMS sur un nokia 3310 encore aujourdhui. C’est pas possible avec une appli, d’autant que certaines appli bancaire exigent un android récent - beaucoup de vieux smartphone sont en android 4 et continuent à marcher, malgré des failles de sécurité énormes.
Un ami a encore un smartphone sous Symbian… (et peux donc encore recevoir des SMS), mais il ne peux plus installer d’appi symbian ou même naviguer sur le net ou relever ses mails avec parceque le root CERT est expiré.
Au moins l’avantage des FOB c’est que c’est varié, donc pas rentable à pirater
La diversité a toujours été un point intéressant pour la sécurité.
#22.1
Si tu pars de ce constat, parce que tu n’as pas vu ou lu qu’une faille serait exploitée en France, on ne devrait pas la corriger ? Ce n’est pas très grave..
Le SMS peut être intercepté et lu, peut être que ce n’est pas simple à faire et peu courant, mais on ne peut pas faire reposer la sécurité d’un système d’authentification sur quelque chose de non sécurisé (dixit l’article et l’ANSSI).
Aujourd’hui, tout le monde a des smartphones dans ses placards, le marché de l’occasion est énorme. Donc celui qui veut vraiment, doit pouvoir trouver. Avoir un smartphone ne nécessite aucun abonnement contrairement au SMS d’ailleurs (aussi bas soit-il). Ce que je veux dire, c’est que dans les deux cas il faut faire des démarches si tu n’es pas équipé.
C’est discriminatoire dans les deux cas, l’un plus que dans l’autre, on est d’accord. Mais c’est accessible.
#23
Merci pour cette remise en forme du charabia ANSSIble.
Pour les coffres forts numériques c’étais évident ainsi que sur le renouvellement des mots de passe. En attendant que ce soit mis en place dans les gouvernances, on aura la version 3 avec le passeport sanitaire inclus.
#24
Le SMS pour du 2FA est fortement déconseillé, mais imposer une appli 2FA unique m’énèrve à moi aussi et j’ai refusé celle de ma banque pour cela, surtout quand elles ont tendance à être bogués et contenir des trackers de plus, du coup j’utilise le SMS (pas top je sais) en cas de besoin, mais j’ai surtout réadapté mes habitudes, j’ai ouvert un nouveau compte Paypal où je peux utiliser le 2FA avec mon application de base.
Très bon article autrement, enfin de bonnes recommendations de la part de l’ANSSI.
#25
Concernant le MFA, c’est toujours pas possible de le mettre en place nativement sur AD ? (avec des yubikey par exemple).
#26
Je trouve l’infographie d’xkcd fausse.
Pour la phrase de passe, on utilise quotidiennement que 500 mots environ. Donc pour des mots communs ça fera moins de 9 bits d’entropie, encore moins si les mots doivent avoir un minimum de sens pour que la phrase soit simple à retenir…
D’où même pas 36 bits d’entropie.
Inversement, pour le mot de passe, celui proposé est très réducteur. Majuscule forcément au début, ponctuation et nombre forcément à la fin.
Sans ces contraintes, on arrive à une entropie finalement plus grande que celle de la phrase de passe.
Et pour la difficulté de mémorisation, perso je n’ai pas de problème (pourtant j’ai une mémoire de poisson rouge) parce que j’ai construit mon mot de passe et qu’il a donc un sens pour moi (mais n’en aura absolument aucun pour n’importe qui d’autre).
#27
En considérant les lecteurs de NXI un minimum avertis: qu’est-ce qui vous met en confiance dans l’utilisation d’une application bancaire sur vos smartphones ?
On passera l’obligation des services google/apple, des traqueurs pour se concentrer sur le smartphone, vous y croyez encore dans ces passoires ?
#27.1
Je pense que le problème est le même quelle que soit l’application sur smartphone, sur PC : comment un utilisateur peut-il estimer la confiance d’une appli ou d’un site web ? Le problème est donc le même avec l’appli Facebook, Waze, ton lecteur de MP3, Twitter, Office, Netflix, Uber, ton appli de running, etc.
Pour ce qui est des applications bancaires, ce sont de très mauvaises candidates pour les trackers car elles ne sont actives que quelques secondes (pour s’authentifier ou valider une opération). Et puis quelle intérêt : savoir quel achat tu es en train de faire ? La banque le sait déjà puisqu’elle traite l’opération de ta carte bleue.
#27.2
C’est pourtant simple, sur un PC, tu as encore la liberté de vérifier et de contrôler un site web, de contrer à différent niveaux ce qui ne te plaît pas sur ce qui ce passe sur la machine qui t’appartiens, sur un smartphone non (pas facilement du moins (je ne vais pas rentrer dans les détails de xposed ou autre)).
Les applis que tu cites sont un bon exemple, ce sont des loisirs, des services conçus pour un fonctionnement saas tu n’as aucun contrôle mais à chacun de choisir si c’est indispensable pour lui.
Le domaine bancaire ce n’est pas du loisir, on a un contrat avec une banque, la teneur de tes transaction lui est connue et c’est bien normal. Le tracking bancaire ne porte pas dessus, mais sur les autres usages et données de ton mobile, ta position à un moment donné, etc dans le but de mieux te cibler pour t’offrir une expérience plus “personnalisée”. De là vendre ces données à des tiers je n’ai que ce cas en mémoire.
Globalement un smartphone est une passoire n’importe quelle appli peut aller faire sa petite collecte et distribuer ça à n’importe qui, c’est une des composantes du business model, soit, on l’accepte ou non, mais sur un sujet sérieux comme les transactions bancaires l’obligation d’appli me pose un problème dans ce contexte.
#28
Si il y a des problèmes dans SS7, bien sur qu’il faut les corriger. Et pas que à cause des banques ! (j’en ai montré un exemple avec les appels ou les SMS d’arnaque).
Et c’est la bonne solution, d’ailleurs !
Par contre , prendre ce prétexte pour imposer sa propre appli n’est pas correct.
Il existe des banques qui ont les 2 et qui utilisent les 2 à bon escient : Nickel me convient, par exemple, et Shine. Dans les 2 cas l’appli semble bien codée , marche sur un téléphone sans Google Service , et n’est pas indispensable pour utiliser le service. Ah, et utilisent le SMS comme second facteur.
Des vieux smartphones, oui. Parfois locké sur un seul opérateur !
Le protocole du SMS est vieux, je sais, et en ce moment des tas d’appli se battent pour le remplacer, tous basé sur IP et sans qu’il n’y ait de consensus (et de toute façon les anciens tel seront pas compatibles).
Le SMS ne disparaîtra qu’avec la fin de la 2G, et on y est pas, mais alors vraiment pas , n’importe qui qui a déjà utilisé un tel en voiture en dehors des villes le sait bien.
#29
Tu soulèves exactement un des problèmes : si on est pas d’accord on s’adapte, mais force est de constater que les alternatives disparaissent. Le jour ou les SMS seront purement interdits par la majorité des établissements bancaires, tout comme l’utilisation de cash dans la majorité des commerces comment fera-t on ?
#30
Je n’ai jamais lu ou entendu parler que l’utilisation du cash dans le commerce allait disparaître, ça n’a aucuns sens le cash reste utile, c’est pas demain par ex que j’acheterai mon pain par CB, tu va pas payer ta baguette à 80 centimes ou ton croissant à 2€ par CB c’est stupide, si une telle mesure venait à être proposé personne ne l’accepterait ni les commercants, t’as pleins de trucs où tu paies en monnaie ou en billet, en ce moment les commerces le déconseille selon les conseilles sanitaires, et encore j’en utilise si j’ai envie.
Pour les SMS, si ma banque un jour me permet de scanner un QR Code pour l’utiliser dans mon appli, je le ferais, en attendant je privilégie Paypal qui n’est pas prêt de disparaître.
#30.1
Le cash c’est un exemple, je suis entièrement d’accord avec tes points mais je reste pessimiste je pense qu’on y viendra.
Le sujet n’est pas là, je te parle d’alternatives qui disparaissent, tu parles de PayPal, mais trouves-tu cette alternative correcte ? C’est tout de même une société étrangère qui est soumis à d’autres lois et qui prend des positions arbitraires selon son bon vouloir.
#31
C’est ce qui est expliqué dans la planche xkcd, la phrase n’a pas besoin d’avoir le moindre sens. C’est même certainement mieux si elle n’en a aucun.
#31.1
Mais dans ce cas là, elle est aussi compliquée à retenir qu’un mot de passe…
#31.2
Au contraire, ça la rend plus facile à retenir.
Enfin, c’est le cas pour moi. Car je suis bien incapable de retenir une phrase qui a du sens en tant que mot de passe.
C’est d’ailleurs un sketch classique quand on met en scène un repaire de brigands qui changent la phrase régulièrement. L’un des brigands oublie la phrase actuelle (mais avec un peu de chance se souvient des précédentes).
#31.3
Pas forcément. Ca peut être une référence à quelque chose qui est connu de toi mais pas des autres (ta citation préférée de ton fim préférée, un peu détournée).
“Il faut blanchir les maquignons” par exemple, ça ne veut rien dire, mais c’est bien sécurisé. Par contre ça ne tient pas 5 secondes à une convention Kaamelott
#32
Ma banque est compatible avec Paylib, je n’ai pas compris comment m’en servir et je n’ai encore vu personne proposer ce moyen de paiement, donc vite désinstallé, cela m’obligeait en plus à installer une autre appli de ma banque.
#33
Des malwares peuvent lire les sms, sans même besoin de les ouvrir si le code de connexion apparaît dans la notification (ce qui arrive assez souvent).
#34
Je suis assez dubitatif sur les coffres forts. Tout le monde les recommande de nos jours, ça ne signifie pas que c’est une bonne solution (ça rejoint l’article qui cite les mots de passe compliqués qu’on nous a conseillé pendant des années). Le jour où on trouvera une 0-day sur ces coffres… Bonjour les dégâts.
Personnellement je préfère avoir un fichier de texte A, le chiffrer (j’obtiens B), et chiffrer B (alors un autre programme). C’est tout aussi sécurisé, et la compromission d’une étape est sécurisée par les autres (la probabilité que les deux soient cassés en même temps est proche de zéro). De plus ça passe dans un e-mail, ou autre moyen de transport/stockage pas forcément sécurisé, je peux ainsi y accéder de partout, sans avoir à installer un programme ou une extension.
#34.1
Note que tu peux croiser les deux approches : utiliser un coffre-fort qui dispose de son propre chiffrement/accès sécurisé (via une clé de sécurité ou autre) et chiffrer à froid le contenu de la base de mots de passe (qui est en général un fichier séparé) par ton propre moyen.
Le problème sera toujours le même au bout du compte : c’est une approche jouable sur un poste client classique où qui est habitué à un certain niveau d’exigence en matière de sécurité, mais quand tu veux mettre ça dans les mains d’un de tes collaborateurs qui doit pouvoir accéder à des services depuis un appareil mobile, c’est un peu une autre ambiance.
#34.2
Je n’ai pas tout compris donc si tu veux donner un peu plus de détails je suis preneur
Ce que je comprends :
Fichier A est chiffré en fichier B (par un programme de chiffrement qu’on appelle programme1)
Puis fichier B est chiffré en fichier C (par un autre programme de chiffrement appelé programme 2)
Puis tu envoies par mail ce fichier C ou tu le transportes par disque dur externe par exemple.
Si j’ai bon jusque là c’est la dernière étape que je ne comprends pas quand tu dis que tu peux y accéder de partout sans avoir a installer un programme ou une extension :
Si l’ordi sur lequel tu veux déchiffrer le fichier C (donc celui sur lequel tu ouvres le mail ou celui dans lequel tu branches le disque dur externe) n’a pas les programmes 1 et 2 tu es bien obligé de les installer, non ? (Ou alors il faut toujours avoir avec toi un ordi ou un tel qui contient ces 2 programmes ?)
#34.3
Oui je me suis vautré sur le fait d’avoir les bons programmes sur le pc final
#34.4
Merci pour la réponse et … Dommage j’étais preneur d’une telle solution !
#35
PS : J’ai mal lu, preuve que c’est du message codé
#36
Si ton tel a un malware, SMS ou appli bancaire ta confidentialité est mise à mal. Là-dessus, c’est comme un PC. (Et c’est pour ça que j’ai davantage confiance dans un Lineage qu’un android stock pas à jour sur un tel un peu ancien)
Pour moi la sécurité du SMS se joue surtout sur le transport : Est-ce qu’un “pirate” peux, facilement , accéder au SMS de confirmation de ta banque et aussi t’empêcher de le recevoir.
L’un des article que j’ai trouvé date un peu :
https://www.nextinpact.com/article/26416/104214-ss7-apres-interceptions-sms-securite-reseaux-mobiles-en-question (Mais le journaliste est très bon :-) )
Et la conclusion me rassure un peu sur ce sujet, là où je sais qu’aux USA ce genre d’attaque est apparu en masse , en France et en Europe ça reste ciblé. Or , si tu es effectivement ciblé par un groupe (de hacker , ou gouvernemental) c’est pas une appli qui va t’en sortir.
Je n’ai pas trouvé en France (ni en europe) de problèmes générique et structurels lié au SMS. Par contre on a quand même des problèmes notamment avec l’usurpation du caller-ID, qui est pénible sans plus lors des démarchages téléphoniques.
C’est ce qui me fait dire qu’on est dans un cas de “quand tu veux tuer ton chien tu dis qu’il a la rage”.
#37
Sur la CAF :
Des baffes se perdent.
#37.1
#37.2
Fait une phrase de mots pour obtenir un mot de passe
Undeux3nousironsauxbois
#38
Ok, si ces mêmes banques intégraient l’autre recommandation de ne pas forcer le changement de mot de passe.
#39
Tout cela je serais d’accord si cette même banque ne m’imposait pas de changer de mot de passe