Définition
Un mot de passe est un mot ou une série de caractères utilisés comme
fr.wikipedia.org
moyen d’authentification pour prouver son identité lorsque l’on désire accéder à un lieu protégé, à une ressource (notamment informatique) ou à un service dont l’accès est limité et protégé.
Le mot de passe constitue l’un des piliers majeurs de la sécurité informatique. C’est pourquoi tant de pirates essayent de l’obtenir par des moyens toujours plus imaginatifs et complexes. Il représente le vecteur « ce que je sais » qui, combiné à un nom d’utilisateur suffit pour s’authentifier sur la plupart des ordinateurs et systèmes d’information. Le mot de passe ne permet pas de donner un droit d’accès, il permet uniquement d’assurer l’imputabilité dans l’usage de ces droits.
L’identification et l’authentification
Il s’agit de deux notions différentes bien que liées. On parle d’identification lorsque l’on répond à la question « Qui suis-je ? ». On comprend vite qu’il est tout à fait possible de fausser la réponse en donnant une identité volée ou inventée. Le mot de passe joue alors le rôle d’authentifiant. Il apporte la preuve que l’identifiant fourni est bien le nôtre. C’est là qu’on apprécie l’importance d’avoir un mot de passe qui ne ressemble pas à celui du voisin …
L’authentification forte
L’authentification forte ajoute une couche de sécurité supplémentaire puisqu’il s’agira d’attester son identité en fournissant en général un élément que l’on possède : un badge, un certificat, une carte à puce … On parle alors d’authentification à double facteurs souvent abrégé 2FA. On peut pousser le concept jusqu’au MFA (Multiple Factor Authentication) lorsqu’on utilise plus de deux facteurs afin de lever toute ambiguïté d’identité. Il existe actuellement quatre principaux facteurs : la connaissance d’un secret (mot de passe ou passphrase), la possession d’un objet, l’inhérence à une personne (typiquement la biométrie par empreinte digitale, rétinienne, faciale voire pavillonnaire) et la localisation (connexion d’un périphérique à un réseau localisé, position GPS ou Galileo).
Pour s’authentifier auprès d’un service, on peut en outre faire appel à des tiers de confiance appelés « Identity Providers ». Dans ce cas, l’entreprise cliente d’un tel système délègue la gestion des identités à une autre entreprise comme France Connect, Gemalto, Google ou Facebook.
Il existe différents protocoles permettant de s’authentifier sur une plateforme tierce parmi lesquels OpenID Connect (OIDC) et Security Assertion Markup Language (SAML). OIDC est utilisé par Google, l’État français, Microsoft… Il spécifie une API HTTP RESTful, en utilisant JSON comme format de données. C’est une simple couche d’identification basée sur le protocole OAuth 2.0.
SAML est basé sur XML. La version 2.0 du protocole est ratifiée en 2005. SAML 2.0 permet une authentification unique (SSO) inter-domaines basée sur le Web, ce qui réduit la charge administrative liée à la distribution de plusieurs jetons d’authentification à l’utilisateur. Une trentaine de personnes issues de plus de 24 entreprises et organisations ont participé à la création de SAML 2.0. Liberty Alliance a notamment fait don à OASIS de sa spécification Identity Federation Framework (ID-FF), qui a servi de base à la spécification SAML 2.0.
Les phrases de passe
Vaste débat qu’est celui de l’utilisation des phrases de passe (ou passphrases en anglais) au lieu des mots de passe classiques. Un mot de passe tel qu’on le connaît est composé de lettres et symboles parfois aléatoires voire parfois d’un simple mot du dictionnaire (cas à bannir). Une phrase de passe est plus longue qu’un mot de passe et peut contenir des espaces entre les mots : « Je suis le seul à connaître mon mot de passe ! ». À noter qu’une phrase de passe peut contenir des symboles et n’a pas besoin d’être grammaticalement correcte. La principale différence entre ces deux systèmes est que les mots de passe n’ont généralement pas d’espace alors que les phrases de passe si.
Les phrases de passe sont plus faciles à retenir qu’une combinaison aléatoire de symboles et de lettres pour un humain. En effet, il est plus simple de se souvenir d’un passage d’une chanson ou d’une citation que de se rappeler d’un mot de passe plus court mais compliqué. D’un point de vue critique, c’est déplacer le problème car il faudra toujours se rappeler de plusieurs phrases de passe puisqu’il doit y en avoir autant que de services utilisés. En outre, il semblerait que ce type de secret soit moins robuste face aux attaques d’ingénierie sociale contrairement à un mot de passe généré aléatoirement.
Heureusement il existe d’autres avantages à utiliser de phrases de passe, notamment elles satisfont facilement les règles de complexité. L’utilisation de la ponctuation, des majuscules et des minuscules dans celles-ci répond à ces exigences. Les systèmes d’exploitation les plus répandus autorisent des phrases de passe d’une longueur de 127 caractères. Par conséquent, on peut opter pour des phrases de passe longues pour une sécurité maximale. Enfin, les phrases de passe sont pratiquement impossibles à « casser » car la plupart des outils de cassage prendraient un temps considérable à aboutir.
Il y a tout de même certaines règles à respecter pour générer une bonne phrase de passe. Sur son blog l’entreprise helvète Protonmail propose que sa taille dépasse cinq mots, de ne pas utiliser de citation, de favoriser les phrases les plus aléatoires possibles avec des mots peu utilisés (en gros des phrases qui ne veulent absolument rien dire) et comme pour les mots de passe d’utiliser une passphrase différente par compte.
Les recommandations de l’ANSSI
L’Agence Nationale de la Sécurité des Systèmes d’Information (ANSSI) dans sa note technique du 5 juin 2012 Recommandations de sécurité relatives aux mots de passe propose de respecter certaines exigences en matière de génération et de gestion des mots de passe :
- Utiliser autant que faire se peut l’authentification à deux facteurs,
- Utiliser un mot de passe différent par système (serveur, ordinateur, site web, portable),
- Choisir un mot de passe qui ne peut être deviné en connaissant bien la personne,
- Ne pas demander à un tiers de créer un mot de passe pour une personne,
- Changer de mot de passe au moins tous les 90 jours sur les systèmes critiques,
- Modifier immédiatement et systématiquement les mots de passe par défaut des systèmes,
- Ne pas stocker les mots de passe sur les postes sensibles ou sur un papier,
- Ne pas transférer les mots de passe par email ou messagerie instantanée,
- Ne pas laisser les logiciels se souvenir des mots de passe sauf s’il est dédié à cet usage,
- Le mot de passe doit être composé d’au moins 12 caractères parmi 90 symboles,
- Le mot de passe devrait être composé de 16 caractères dans un alphabet de 36 symboles.
L’agence recommande par ailleurs une entropie minimale de 100 bits pour les mots de passe protégeant les clés privées de systèmes critiques, 128 bits étant l’idéal pour une protection pour plusieurs années encore. Il reste à résoudre la question de la mémorisation du mot de passe puisqu’à 128 bits d’entropie, il est humainement quasiment impossible de s’en souvenir.
Les constatations et recommandations du NIST
Le National Institute of Standards and Technology (NIST) est une agence du département du Commerce des États-Unis d’Amérique. Dans sa mission de promotion de l’économie, elle conseille et développe pour les industries américaines mais aussi pour les agences fédérales, des standards technologiques. Cela passe notamment par les aspects de protection des systèmes d’information là où la NSA a majoritairement un rôle de renseignement visant à la défense des intérêts des USA. Dans ses recommandations introduites dans le NIST Special Publication 800-63 Revision 3 de juin 2017, l’agence insiste pour que les mots de passe deviennent plus « user-friendly ». En effet, les utilisateurs ont tendance, pour retenir leur multitude de mots de passe, à diminuer leur complexité et à les réutiliser trop fréquemment sur différents services.
En 2016, l’entreprise Experian, spécialiste de l’information et de la gestion de la relation client a affirmé que les milléniaux ont en moyenne quarante services liés à une seule adresse email pour seulement cinq mots de passe différents.
Contre toute attente, le NIST pousse à abandonner les règles de complexité imposées que l’on rencontre dans les entreprises mais aussi lors de la création de comptes sur les services en ligne. Par exemple, on aura fréquemment tendance, pour être conforme à la politique, à ajouter un caractère de ponctuation à la fin du mot de passe ce qui ne le rend pas plus difficile à casser.
Le NIST va beaucoup plus loin que l’ANSSI quant à la taille préconisée. Pour lui, l’idéal est d’au moins 64 caractères ce qui représente environ une force cryptographique de 350 bits avec un alphabet de 62 symboles. Il recommande par ailleurs de :
- Autoriser la copie du mot de passe depuis le presse-papier vers son champ,
- Vérifier la présence des mots de passe saisis dans un dictionnaire pour les bloquer,
- Ne pas utiliser le système de récupération par questions réponses,
- Limiter le nombre de tentatives infructueuses de saisie de mots de passe,
- Ne pas utiliser l’email ni la VoIP comme canal d’authentification 2FA.
Toutes ces mesures visent à faciliter l’expérience de l’utilisateur et à ne pas le frustrer. Auquel cas, il risquerait de détériorer volontairement la complexité de son mot de passe. En outre, utiliser des mots de passe forts sans les stocker de manière pérenne reviendrait à ne pas en utiliser du tout. L’agence américaine propose donc en parallèle de :
- Saler les mots de passe avec au moins 32 bits de données,
- Hasher ceux-ci avec une fonction de dérivation de clé (KDF) comme PBKDF2,
- Itérer ce hash au moins dix mille fois,
- Réaliser un dernier hash avec un sel stocké à un autre endroit.
Pour terminer, à l’heure où la commission européenne a déclaré que l’usage des SMS comme moyen d’authentification pour les transactions bancaires ne devra plus être supporté après septembre 2019, le NIST ne considère toujours pas ce canal comme désuet. Certains analystes pensent que cela fait suite à un intense lobbying du CTIA, l’association professionnelle représentant l’industrie des communications sans fil aux États-Unis puisqu’il y a de gros enjeux financiers. Rappelons que le canal SMS peut être attaqué par des malwares installés sur les smartphones voire par un piratage direct du réseau sémaphore 7. De plus, la possibilité de transférer les messages et de changer librement de numéro ou de téléphone signifie que l’accès aux SMS ne prouve pas toujours la possession d’un appareil.
Calculer la force cryptographique d’un mot de passe et son entropie
Avant d’expliquer ce type de calcul, je souhaite partager un outil parmi d’autres qui accomplit cette tâche de façon intuitive et visuelle. howsecureismypassword, souvent abrégé HSIMP, est une service gratuit, accessible à tout un chacun dont le code source est disponible librement sur GitHub sous licence MIT.
Il est donc possible de l’installer sur un serveur privé au lieu de passer par le site Internet qui lui est dédié (site qui pourrait très bien constituer une base de données géante dans notre dos). Il simule le temps que prendrait un ordinateur pouvant analyser 10 milliards de mots de passe à la seconde pour venir à bout de celui entré par l’utilisateur. L’internaute obtiendra un score et devra modifier en conséquence son mot de passe pour le rendre plus robuste. Par ailleurs l’outil vérifie que le mot de passe à analyser ne fait pas partie des 10000 les plus répandus. Comment est calculée la force d’un mot de passe ?
En fait, il existe plusieurs algorithmes qui permettent de réaliser cette tâche ce qui implique qu’un même mot de passe n’aura pas la même force en fonction de l’algorithme choisi. Il s’agit donc d’une estimation qui ne doit pas être prise pour argent comptant. En outre, une autre notion intimement liée à la force intervient dans cette évaluation. C’est l’entropie. Il s’agit d’une mesure qui donne l’imprédictibilité d’un mot de passe.
En augmentant l’entropie d’un bit, il est deux fois plus incertain de prédire le mot de passe ce qui signifie que l’attaquant doit essayer une quantité deux fois plus importante de mots de passe avant de trouver le bon.
Pour calculer la qualité d’un mot de passe, autrement dit sa force, le très connu gestionnaire KeePass va préalablement comparer la chaîne de caractères saisis avec un dictionnaire des mots de passe les plus utilisés.
Voyons cela avec un exemple. La chaîne “pikach” obtient un score de 29 bits contre 12 bits pour “pikachu” alors qu’on ajouté un caractère, ce qui va à l’encontre de la règle mathématique ci-dessous. Ceci est normal puisque “pikachu” est un nom propre susceptible d’être plus utilisé que “pikach”. Stricto sensu, un mot de passe déjà connu, typiquement tous les mots du dictionnaire et ceux présents dans les leaks, ont une entropie à 0 bit. Abordons maintenant quelques aspects mathématiques.
𝑛 bits d’entropie signifie qu’il faut en moyenne \(\small 2^{n-1}\) tentatives à un attaquant pour trouver un mot de passe. On parle bien de moyenne donc le nombre réel d’exécutions peut être inférieur ou supérieur. L’entropie est calculée avec la formule suivante :
\(E = log_2(R^L)\)
- E entropie du mot de passe généré aléatoirement,
- R total du pool de caractères uniques,
- L nombre de caractères dans le mot de passe,
- \(R^L\) nombre de combinaisons possibles.
Disons qu’un attaquant est actuellement capable de réaliser 2,2 milliards de hash SHA-1 à la seconde grâce à ses GPU (qui est au passage un algorithme considéré comme désuet). Si le mot de passe attaqué a une entropie de 44 bits, il faudra en théorie une moyenne de \(2^{43}\) tentatives avant de trouver la bonne correspondance ce qui prendrait à l’attaquant 4000 secondes soit un peu plus d’une heure. Maintenant, si l’entropie passe à 63 bits l’attaquant devrait patienter environ 133 ans sans modifier la technologie d’attaque. On voit donc l’importance de générer des mots de passe ayant une entropie importante tout comme les stocker après passage dans une fonction de hachage éprouvée. On peut s’amuser à extrapoler la résistance des mots de passe dans le temps en appliquant les très connues conjectures de Gordon Moore (co-fondateur du fondeur Intel en 1968). La seconde loi empirique de 1975 indique que le nombre de transistors des microprocesseurs sur une puce de silicium doublera tous les deux ans.
L’intérêt du sel dans le hachage
Afin d’identifier les avantages apportés par le sel dans le processus de hachage des mots de passe, on va d’abord analyser les attaques sur les bases de données de hashs non salés. La façon la plus simple de déchiffrer un hachage est d’essayer de deviner le mot de passe enregistré en hachant les suppositions et en les comparant à l’enregistrement haché en base de données. Si les hachages sont égaux, la supposition est le bon mot de passe. Les deux façons les plus courantes de deviner les mots de passe sont les attaques par dictionnaire et les attaques par force brute.
Une attaque par dictionnaire utilise un fichier contenant des mots, des phrases, des mots de passe courants et d’autres chaînes de caractères qui sont susceptibles d’être utilisés comme mot de passe. En général, chaque mot dans le fichier dictionnaire est déjà haché pour gagner du temps (lookup tables), sinon ils sont hachés à la volée. Un traitement ultérieur est souvent appliqué au dictionnaire, par exemple en remplaçant les mots par leurs équivalents en alphabet 1337 (« hello » devient « h3110 ») pour ajouter encore plus de variantes.
A contrario, une attaque par force brute tente toutes les combinaisons possibles de mots de passe jusqu’à une certaine longueur. Ces attaques sont très coûteuses en ressource CPU et sont moins efficaces en temps que les attaques par dictionnaires mais elles finissent logiquement par trouver le bon mot de passe.
Pour ralentir ces attaques, on sale les mots de passe. Cela consiste à concaténer le mot de passe en clair avec une autre chaîne de caractères aléatoire (le sel) et différente pour chaque mot de passe. Même si le sel est connu de l’attaquant, le résultat hashé sera différent des entrées éventuellement présentes dans les lookup tables, les reverse lookup tables ou les rainbow tables les rendant ainsi inopérantes.
sha256(‘pikachu’) = 43999461d22f67840fcd9b8824293eaa4f18146e57b2c651bcd925e3b3e4e429 sha256(‘pikachu + bQugGkWYdRVf’) = 49527b39c1e9a5b492c39209ee6e4d0b25c77d90b848008e7008199325b7b5f0
Les tables arc-en-ciel
Les rainbow tables sont des outils qui furent créés par Philippe Oechslin de l’Institut Fédéral Suisse de Technologie à Lausanne en 2003. Il s’agit en fait d’une amélioration des compromis temps-mémoire proposés par Martin Hellman dans les années 1980 (de l’algorithme d’échange de clés cryptographiques Diffie-Hellman). Plus récemment Gildas Avoine de l’Institut National des Sciences Appliquées de Rennes, affina encore cette technique.
Voici une façon de procéder parmi d’autres. On passe dans un premier temps le mot de passe de départ P0 dans une fonction de hachage. On obtient H(P0) que l’on envoie dans une première fonction de réduction R1 ce qui aboutit à la création d’un nouveau mot de passe R1(H(P0)) que l’on nomme P1. On recommence cette procédure un nombre fixé de fois. Ainsi R2(H(P1)) donne P2, R3(H(P2)) donne P3 etc… Les fonctions de réductions changent à chaque itération afin d’éviter les collisions. Avec certaines rainbow tables, on s’arrête lorsque le hash commence par vingt zéros. Un tel hash apparaît environ une fois tous les un million de hashes (\(2^{20}\)).
Seule la paire [P0, Rn(H(Pn)] est stockée dans la table. Le reste de la chaîne n’est pas conservé afin de limiter la mémoire nécessaire. Il est toutefois possible de les retrouver en calculant l’ensemble de la chaîne à partir de l’élément en tête de liste c’est-à-dire P0. Un grand nombre d’autres paires sont ensuite calculées en faisant varier P0.
Comment exploiter un rainbow table afin de trouver le mot de passe original d’un compte obtenu à partir d’une fuite de données ? Nous avons en notre possession H0, le hash du mot de passe volé que l’on souhaite révéler. On calcule R3(H0) afin d’obtenir un nouveau mot de passe P3 que l’on compare au second membre des paires [P0, Rn(H(Pn)] présentes dans la rainbow table (dernière colonne de la table).
On peut logiquement déduire que si aucune occurrence n’est trouvée, H0 ne se trouve pas à la fin des chaînes. On calcule alors R2(H0) et on obtient un nouveau mot de passe P2 qu’on hache ce qui revient à faire H(R2(H0)) donc H(P2). Enfin, on applique à ce hash H1 la fonction de réduction R3 qui aboutira à la génération d’un nouveau mot de passe P1. On aura donc fait R3(H(R2(H0))) autrement dit R3(H(P2)) ou encore R3(H1).
Si P3 est présent dans la dernière colonne de la table, on récupère le premier membre des paires [P0, Rn(H(Pn)] c’est-à-dire P0, le mot de passe de la première colonne de la ligne correspondante. On calcule à nouveau la chaîne H(P0) puis R1(H(P0)) puis H(R1(H(P0))) si nécessaire jusqu’à ce qu’on retombe sur H0. Le mot de passe à révéler est donc le dernier calculé. Pour bien comprendre, voici une explication étape par étape fournie par Wikipédia.
- Le hash « re3xes » est récupéré d’une base de données piratée. On calcule la dernière réduction utilisée dans la table, ici R3(re3xes) et on regarde si le mot de passe « rambo » apparaît dans la seconde colonne de la table. Ce n’est pas le cas,
- On construit une nouvelle chaîne et on regarde si le mot de passe qui est cette fois « linux23 » apparaît dans la seconde colonne de la table,
- C’est le cas,
- On récupère le mot de passe « passwd »,
- On construit une nouvelle chaîne et on compare à chaque itération le hash généré avec le hash original « re3xes ». S’ils sont égaux, on arrête l’itération et on récupère le mot de passe recherché qui est celui qui a généré le hash du début.
Les rainbow tables sont inefficaces si les mots de passe sont salés.
La recette de la bonne salaison
Pour stocker correctement et avec le moins de risque possible les mots de passe en base de données, on veillera à :
- Utiliser un sel différent par hash,
- Le sel doit être généré par un générateur de nombre pseudo-aléatoire cryptographiquementsécurisé (CSPRNG),
- Employer idéalement un sel dont la longueur est égale à la sortie de la fonction de hash,
- Ne pas prendre le nom d’utilisateur comme sel puisque prédictible et réutilisé,
- Intégrer uniquement des algorithmes connus et reconnus comme SHA256, SHA512, RipeMD,WHIRLPOOL, Argon2, bcrypt, scrypt, ou PBKDF2,
- Préférer le hachage des mots de passe côté serveur seulement,
- Ne pas hacher et saler les mots de passe uniquement côté client.
Un sel réutilisé implique qu’un attaquant pourra efficacement lancer une attaque par dictionnaire à l’aide d’une reverse lookup table sur chaque hash en même temps. Il n’aura qu’à appliquer le même sel sur chaque mot de passe testé avant de hacher le tout. Si le sel est trop court, un attaquant pourra construire une lookup table pour chaque sel possible.Par exemple, si le sel n’est constitué que de trois caractères ASCII imprimables, il n’y a que \(95^3\) = 857375 sels possibles. Cela peut sembler beaucoup, mais si chaque lookup table ne contient que 1 Mo des mots de passe les plus courants, le total des combinaisons ne pèserait « que » 837 Go.
La technique du key stretching
On a vu jusqu’ici des techniques empêchant de retrouver facilement le mot de passe original « caché » dans le hash mais elles n’empêchent pas de lancer une attaque par force brute ou par dictionnaire.
Pour vraiment ralentir l’attaque, de sorte qu’il soit impossible de décrypter le hash en un temps raisonnable, on peut soit intégrer un système de lock-out de x secondes après n tentatives infructueuses, soit utiliser une fonction de hachage sciemment développée pour être intensive au niveau du CPU/GPU comme PBKDF2 ou bcrypt.
Malgré tout, à l’usage, l’utilisateur légitime ne remarquera pas les quelques millisecondes supplémentaires nécessaires à la comparaison. Ce temps supplémentaire est paramétrable par l’intermédiaire d’un argument passé à la fonction. Il est toutefois important de bien dimensionner la puissance du serveur hébergeant la base de données de ces hashs puisqu’il sera plus vulnérable aux attaques DDoS.
La sécurité des gestionnaires de mots de passe
L’entreprise états-unienne Independent Security Evaluators (ISE) localisée à Baltimore dans le Maryland a publié le 19 février dernier un article intitulé Password Managers: Under the Hood of Secrets Management.
Elle a testé quatre gestionnaires de mots de passe grand public parmi les plus utilisés à savoir 1Password, Dashlane, KeePass et LastPass installés sur la plateforme Windows 10.
Les gestionnaires de mots de passe deviennent une cible de choix pour les pirates puisqu’ils renferment de plus en plus de secrets. Idéalement un tel logiciel devrait :
- Ne pas stocker le mot de passe maître dans un fichier à plat,
- Empêcher tout décryptage si la base de données chiffrée est récupérée par un attaquant,
- Bloquer toute tentative de brute force du mot de passe maître,
- Rendre impossible l’extraction du mot de passe maître de la mémoire,
- Interdire l’extraction des mots de passe non utilisés (ni affiché, ni copié) de la base de données depuis l’ouverture de celle-ci,
- Empêcher la récupération d’informations cryptographiques dérivées du mot de passe maître,
- Bloquer toute tentative visant à exploiter des mots de passe non chiffrés présents en mémoire et en base de données,
- Proposer un outil de détection de keyloggers,
- Limiter l’exposition des mots de passe présents dans le presse-papier,
- Intégrer un mot d’autoprotection comme le font certains antivirus afin d’éviter une modification des bibliothèques et autres binaires,
- Proposer un générateur aléatoire à forte entropie.
Résumons les travaux de cette firme. La première conclusion d’ISE est que ces quatre gestionnaires chiffrent correctement leur base de données locales sur le disque de masse ce qui empêche de passer celle-ci en clair. Cela est vrai tant que l’attaquant possède une puissance de calcul modérée.
| Gestionnaire | Algorithme de dérivation | Itérations |
| 1Password v4 (legacy) | PBKDF2-SHA256 | 40k |
| 1Password v7 | PBKDF2-SHA256 | 100k |
| Dashlane | Argon2 | 3 |
| KeePass | AES-KDF | 60k |
| LastPass | PBKDF2-SHA256 | 100,1k |
1Password v4 prend soin d’effacer le mot de passe en clair précédemment utilisé avant d’en copier un autre. Cependant le mot de passe maître sous sa forme obfusquée (a priori facilement réversible) reste en mémoire même si le logiciel est verrouillé.
Étrangement la version 7 de 1Password est moins sécurisée puisqu’il déchiffre chaque mot de passe une fois la base de données déverrouillée une première fois. En sus, il ne pratique aucun nettoyage un cas de verrouillage. Ainsi pour réaliser cette tâche, il faut quitter le logiciel. Celui-ci devait supporter la technologie Intel SGX utilisée pour protéger des secrets en créant des enclaves dans la mémoire de telle sorte que seuls certains processus peuvent y accéder. Cette fonctionnalité fut abandonnée après les premières sous-version du gestionnaire.
Dashlane de son côté ne conserve en mémoire qu’un seul mot de passe à la fois tout comme 1Password v4. Toutefois, lorsque l’utilisateur du programme modifie une entrée dans la base (qui est sous forme d’objet XML), le gestionnaire expose en mémoire tous les secrets en clair même après verrouillage. En outre, et contrairement aux autres gestionnaires de mots de passe, il n’est pas possible de fermer simplement Dashlane depuis l’interface graphique ce qui implique que les secrets peuvent être référencés longtemps en mémoire.
KeePass est le seul projet open-source analysé dans l’étude. Il laisse en mémoire tous les secrets déchiffrés avec lesquels l’utilisateur a interagi. Ils ne sont donc pas nettoyés au fur et à mesure. Le mot de passe maître quant à lui, est supprimé de la mémoire sans possibilité de le récupérer. Il y a des problèmes dans la fonctionnalité de nettoyage du mode verrouillé puisque ISE a pu récupérer des entrées. Le gestionnaire utilise en effet des API Windows qui peuvent faire des copies de divers tampons mémoire qui ne peuvent pas être exposés à la suppression.
LastPass obscurcit le mot de passe maître. Une fois que la clé dérivée est générée, le mot de passe maître est écrasé en mémoire par la chaîne « lastpass rocks ». S’il y a interaction avec le secret souhaité, il est déchiffré en mémoire. Par contre, tous les mots de passe précédemment utilisés restent en mémoire même après verrouillage de l’application. En outre, comme pour KeePass, pendant le processus de génération de la clé de déchiffrement, le mot de passe maître fuit en mémoire et n’est jamais effacé, même lorsque LastPass est placé dans un état verrouillé.
Étude relative à la qualité de générateurs de mots de passe
Aaron Toponce est un administrateur et architecte système qui travaille pour un fournisseur local d’accès à Internet aux USA dans l’état de l’Utah. Outre ses connaissances avancées en environnements GNU/Linux et autres UNIX-like, il étudie actuellement la cryptographie et les standards du Web.
Il a audité quantitativement et qualitativement des générateurs de mots de passe qu’ils soient commerciaux ou libres puis les a classés en fonction de 10 critères :
- Nature de la licence, Open Source ou propriétaire,
- Position du générateur, côté client ou serveur,
- Type, aléatoire ou déterministe,
- Générateur aléatoire cryptographique de nombres, oui ou non,
- Répartition uniforme des nombres, oui ou non,
- Délivré en HTTPS, oui ou non,
- Moyenne de l’entropie, suffisante ou non,
- Version mobile existante, oui ou non,
- Présence de trackers Web, oui ou non,
- Intégrité des sous-ressources, oui, non ou non-applicableAu final, seuls sept générateurs de mots de passe ou phrases de passe obtiennent un 10/10 et répondent de façon positive à tous ces critères.
| Nom | Licence | Generator | Type | CNRG | Uniform | HTTPS | Entropy | Mobile | Trackers | SRI |
| Aaron Toponce | Open Source | Client | Random | Yes | Yes | Yes | 70 | Yes | No | Yes |
| Dicepass | Open Source | Client | Random | Yes | Yes | Yes | 77 | Yes | No | Yes |
| Glenn Rempe | Open Source | Client | Random | Yes | Yes | Yes | 77 | Yes | No | Yes |
| Niceware | Open Source | Client | Random | Yes | Yes | Yes | 80 | Yes | No | Yes |
| One Shall Pass | Open Source | Client | Random | Yes | Yes | Yes | 72 | Yes | No | N/A |
| Taylor Campbell | Open Source | Client | Random | Yes | Yes | Yes | 129 | Yes | No | N/A |
| Privacy Tools | Open Source | Client | Random | Yes | Yes | Yes | 190 | Yes | No | N/A |
Pourquoi avoir choisi ces critères ? Il paraît tout d’abord évident qu’un logiciel Open Source est préférable puisque l’audit du code est laissé libre à tout à chacun ce qui autorise l’analyse fine des fonctions utilisées et de leurs implémentations.
Ensuite, un générateur de mot de passe doit être complètement indépendant d’un serveur puisque le secret doit être uniquement produit côté client. Ainsi, il a moins de chance d’être volé (sauf si un malware est installé sur le client évidemment). En outre, un outil pour lequel il est possible de prédire le secret fourni n’est tout simplement pas un générateur. Le non-déterminisme doit être de mise. Par ailleurs, afin d’obtenir un mot de passe de bonne qualité, faire appel à un générateur aléatoire cryptographique n’est pas dénué de sens. On veillera donc à utiliser sha256crypt, sha512crypt, PBKDF2, bcrypt, scrypt ou Argon2. HTTPS quant à lui, assurera que le code appelé pour générer le secret ne sera pas modifié par un éventuel man-in-the-middle (en tout cas si TLSv1.2 est correctement configuré).
Comme on l’a vu plus haut, une entropie suffisamment élevée est primordiale puisqu’elle est directement liée à l’imprédictibilité du mot de passe. La mise à disposition d’une version mobile est un atout ergonomique et pousse les propriétaires de périphériques mobiles à utiliser ces services.
D’autre part, la non présence de trackers publicitaires assure un bon niveau de confidentialité et évite aussi les vols de secrets. Enfin, l’intégrité des sous-ressources (Subresource Integrity), qui est une recommandation du W3C, valide les données (scripts, images, texte …) servis par un serveur tiers. Pour cela, l’auteur du site utilise le hash de la ressource distante couplé à son emplacement.
Les navigateurs qui vont chercher la ressource peuvent alors comparer le hash fourni par l’auteur du site avec le hachage calculé à partir de la ressource. Si les hachages ne correspondent pas, la ressource est rejetée.
Quand les mots de passe s’invitent dans le Droit récent
Depuis le 1 octobre 2018 en Nouvelle-Zélande, le Customs and Excise Act 2018 autorise les douaniers à exiger des voyageurs la communication des mots de passe de leurs appareils électroniques. Il suffit de soupçonner qu’une personne est impliquée dans une infraction (par exemple l’importation de produits interdits), ou d’avoir un « motif raisonnable » pour demander les codes de la personne. Comme indiqué dans la section 228-5 du texte :
Les informations d’accès, incluent les codes, les mots de passe et les clés de chiffrement, ainsi que toute information associée permettant d’accéder à un appareil électronique.
Customs and Excise Act 2018 – Parliamentary Counsel Office of New Zealand
Certains garde-fous sont tout de même prévus. Les opérations de contrôle ne doivent pas endommager l’appareil ni le rendre instable. En outre, il ne peut être utilisé comme passerelle pour accéder à d’autres contenus distants. Cependant, en cas de refus sans raison valable, le contrevenant s’expose à une amende de 2800 euros. Qui plus est cela pourra justifier des investigations plus approfondies comme une copie de l’appareil pour investigation ultérieure.
Le 28 septembre 2018, l’État de Californie a promulgué la loi SB-327 Information privacy: connected devices bannissant les mots de passe par défaut du type « 123456 » ou « admin » de tous les appareils connectés qui seront vendus à partir de 2020. Chaque dispositif devra obligatoirement intégrer un mot de passe préprogrammé différent. De plus, le logiciel devra demander à l’utilisateur de changer immédiatement le mot de passe par défaut à la première connexion à l’interface de gestion. Par contre cette loi n’impose pas aux fabricants de procéder à une mise à jour du logiciel embarqué si un bug ou une vulnérabilité est trouvé.
ji32k7au4a83
Ce mot de passe semble assez intéressant à utiliser de prime abord. D’une part il est assez long (12 caractères) et d’autre part il ne s’agit pas d’un mot commun du dictionnaire. Son entropie est de 55 bits pour KeePass et 39 bits pour ae7.st l’outil d’Aaron Toponce. Pourtant ce mot de passe à récemment « buzzé » sur la Toile.
Il est répertorié dans 141 brèches sur les 346 recensées par le site Have I Been Pwned? Nous savons tous que l’un des principaux mots de passe utilisés dans le monde est le très original « password ».
D’après Robert Ou, un ingénieur logiciel et matériel États-Unien, taper « ji32k7au4a83 » sur un clavier chinois ou taiwanais permet de former la série d’idéogrammes 我的密碼 qui n’est ni plus ni moins que « my password » en mandarin. C’est la même chose pour « au4a83 » littéralement « password ».
