Je rage à chaque fois que je saisis un mot de passe fort et que le site m’envoie bouler parce que je n’ai pas de caractère autre qu’alphanumérique.
Essayons quelque chose d’un peu plus smart pour évaluer la robustesse d’un mot de passe
Développeurs, vous savez probablement tout ça, mais continuez à lire parce que la fin vous est adressée
Traduit autrement, voici le nombre de combinaisons qu’on peut tester, et le même chiffre écrit en puissance de deux (arrondi à la décimale inférieure) :
1 €
3,5 × 10^12
2^41,6
10 €
3,5 × 10^13
2^44,9
100 €
3,5 × 10^14
2^48,3
1 000 €
3,5 × 10^15
2^51,6
10 000 €
3,5 × 10^16
2^54,9
100 000 €
3,5 × 10^17
2^58,2
Quand on vous parle ailleurs de bits d’entropie, ça correspond à ces puissances de 2. Avec 1 000 € on peut tester toutes les combinaisons de SHA 256 d’une chaîne aléatoire de 51 bits.
Ok, mais ça me dit quoi ? Une lettre c’est 26 combinaisons, environ 4,7 bits. Si vous ajoutez les majuscules vous doublez le nombre de combinaisons et vous ajoutez 1 bit. Si vous ajoutez les chiffres et quelques caractères spéciaux on arrive à à peine plus de 6 bits.
Petit calcul, en utilisant juste les 26 lettres de l’alphabet, on peut tester toutes les combinaisons de 8 caractères pour moins de 1 €. Vu qu’on aura de bonnes chances de tomber dessus avant d’avoir testé toutes les combinaisons, autant dire que même avec 9 caractères, votre mot de passe ne vaut pas plus de 1 €.
Combien faut-il de caractères pour se trouver relativement à l’abri (c’est à dire que la somme investie ne peut pas tester plus de 1% des combinaisons) ? Ça va dépendre de ce que vous y mettez comme types de caractères. J’ai fait les calculs pour vous :
a-z
a-z A-Z
a-z A-Z 0–9
a-z A-Z 0–9 +-%
1 €
11
9
9
8
10 €
11
10
9
9
100 €
12
10
10
10
1 000 €
13
11
10
10
10 000 €
14
11
11
11
100 000 €
14
12
11
11
Et là magie : 8 caractères, même avec des chiffres, des majuscules et des symboles, ça résiste tout juste à 1 €. Et encore, là c’est en partant du principe que vous choisissez réellement les caractères de façon aléatoire, pas que vous ajoutez juste un symbole à la fin ou que vous transformez un E en 3.
Vous voulez que votre mot de passe résiste à un voisin malveillant prêt à mettre plus de 10 € sur la table ? Prévoyez au moins 10 caractères.
Et là, seconde magie : Si vous mettez 10 caractères on se moque de savoir si vous y avez mis des chiffres ou symboles. La longueur a bien plus d’importance que l’éventail de caractères utilisé.
Maintenant que vous savez ça, tous les sites qui vous imposent au moins une majuscule et un symbole mais qui vous laissent ne mettre que 8 caractères : Poubelle.
Je ne suis pas en train de vous apprendre à faire un mot de passe fort. Vous devriez utiliser un gestionnaire de mots de passe et le générateur automatique qui y est inclus.
Je suis en train d’essayer de rendre honteux tous les développeurs qui acceptent de mettre ces règles à la con sur les sites web dont ils ont la charge : Vous imposez des mots de passe qui sont à la fois imbitables et peu robustes.
Vous voulez faire mieux ?
Regardez dans quelle colonne est l’utilisateur en fonction des caractères qu’il a déjà tapé et donnez-lui un indicateur en fonction de la longueur de son mot de passe.
Moins de 10 € ? mot de passe insuffisant, refusé
Moins de 100 € ? mot de passe faible, couleur rouge
Moins de 1 000 € ? mot de passe moyen, couleur orange
Mot de passe sûr, couleur verte, à partir de 10 000 €
Si vous gérez un site central, par exemple un réseau social public, vous pouvez probablement relever tout ça d’un cran.
Si ça donne accès à des données sensibles, à des possibilités d’achat, à la boite e-mail ou à l’opérateur téléphonique, mieux vaux relever tout ça de deux crans.
Le tout prend probablement moins de 10 lignes en javascript. C’est une honte que vous acceptiez encore d’implémenter des règles à la con « au moins une majuscule, un chiffre et un symbole, voici les symboles autorisés […] ».
Il y a peut-être des erreurs, probablement des mauvais termes, certainement des fautes ou mauvaises formulations. Vous êtes bienvenus à participer en proposant des corrections.
L’idée de base : Tous les mots de passe sont chiffrés. Personne d’autre que vous ne peut les relire sans votre accord. Ni le serveur sur lequel vous les envoyez, ni quelqu’un qui a accès au disque où vous les stockez, ni quelqu’un qui a ponctuellement accès à votre poste de travail.
Chiffrer c’est simple.
Pour chiffrer on a le choix. On va séparer deux catégories principales de chiffrement : les chiffrements symétriques et les asymétriques.
La plupart des gestionnaires de mots de passe ont choisi un chiffrement symétrique (une seule clef secrète qui sert à la fois à chiffrer et à déchiffrer). C’est simple à gérer, rapide à l’exécution, et il n’y a pas besoin de clef de grande taille. Tous ceux que j’ai vu utilisent de l’AES avec une clef de 256 bits. Au moins pour Bitwarden et Keepass, c’est le mode CBC, et un contrôle HMAC avec SHA256 comme fonction de hachage (mais vous pouvez ignorer tous ces détails s’ils ne vous disent rien).
J’ai dit « la plupart des gestionnaires de mots de passe ». Un projet au moins a fait un choix différent. L’outil pass utilise un chiffrement asymétrique (une clef publique et une clef privée, l’une sert à chiffrer et l’autre à déchiffrer). Plus exactement, ils utilisent l’outil GnuPG. Même si le choix de la clef est libre, par défaut on y utilise généralement une clef RSA de 2048 bits. Pass a fait ce choix en considérant le partage de mots de passes comme la fonctionnalité principale. On verra pourquoi quand on parlera partage. Entre temps on va se concentrer sur ceux qui font du chiffrement symétrique.
Dans les deux cas, on est là dans de l’ultra-standard au niveau cryptographie. Je serais étonné de voir autre chose ailleurs (et c’est une bonne chose).
Une clef ? quelle clef ?
Ok, nos mots de passe sont chiffrés mais où est la clef ?
Impossible de demander à l’utilisateur de se rappeler une clef de 256 bits. Ce serait plus de 40 signes entre minuscules, majuscules, chiffres et caractères spéciaux. Même avec une très bonne mémoire, ce serait ingérable à l’usage.
Stocker la clef de chiffrement en clair sur le disque n’est pas beaucoup mieux. Ce serait comme avoir coffre-fort haute sécurité dont on cache la clef sous le paillasson.
Ce qu’on demande à l’utilisateur c’est un mot de passe principal. Vu qu’il va permettre de déchiffrer tous les autres, on va l’appeler « mot de passe maître ». Il faut qu’il soit assez long et complexe pour éviter qu’un tiers ne puisse le deviner ou le trouver en essayant toutes les combinaisons une à une, mais assez court pour pouvoir s’en rappeler et le taper sans erreur.
Le mot de passe maître ne chiffre rien lui-même. Accompagné d’autres paramètres, il sert à calculer une clef de taille suffisante qui, elle, servira au chiffrement décrit plus haut et qu’on va appeler « clef maîtresse ». La fonction qui fait cette opération est dite fonction de dérivation de clef.
Bitwarden utilise le très classique PBKDF2 avec un hachage SHA256. Pour faire simple on prend le mot de passe, on le mélange à une chaîne aléatoire (stockée quelque part pour réutiliser la même à chaque fois), et on opère la fonction de hachage prévue. Normalement ça suffit pour avoir un résultat considéré comme relativement aléatoire et impossible à remonter en sens inverse.
En pratique on cherche aussi à ralentir quelqu’un qui chercherait à tester tous les mots de passe possibles un à un. Pour ça on va simplement répéter l’opération précédente un certain nombre de fois. Chaque itération prend en entrée le résultat de l’étape précédente. Si je fais 10 itérations, il faudra 10 fois plus de temps à un attaquant pour tester toutes les combinaisons. Ici on considère le résultat comme assez confortable à partir de 100.000 itérations.
Keepass utilise une fonction plus récente et considérée comme plus robuste aux possibilités des matériels actuels : Argon2.
Là aussi tout est très classique. Je n’ai pas regardé tous les gestionnaires de mots de passe mais je serais étonné de trouver autre chose que ces deux solutions standards.
On résume
À l’ouverture le gestionnaire de mots de passe vous demande votre mot de passe maître. À partir de ce mot de passe et de paramètres prédéterminés, il utilise une fonction de dérivation de clef et en sort une clef maitresse.
C’est cette clef maitresse qui permet de chiffrer ou déchiffrer vos mots de passe. Celui qui n’a pas accès à votre clef ne pourra rien faire des mots de passe chiffrés sur le disque.
Sécurité
À l’ouverture, le gestionnaire de mot de passe vous demandera votre mot de passe maître que pour calculer la clef maîtresse à l’aide d’une fonction de dérivation de clef. Une fois ceci fait, il garde la clef maîtresse en mémoire et oublie le reste. Quoi qu’il se passe, personne ne connaîtra votre mot de passe maître.
Le logiciel utilise cette clef maîtresse pour chiffrer et déchiffrer vos mots de passe. Cette clef maîtresse n’est jamais écrite nulle part. La plupart des gestionnaires de mots de passe oublieront volontairement cette clef en mémoire après un certain temps d’inactivité, ou à la mise en veille de votre poste de travail. L’idée c’est de limiter le risque de laisser qui que ce soit d’autre que vous y avoir accès. Dans ces cas là, on vous invitera à saisir de nouveau votre mot de passe maître pour retrouver la clef oubliée.
Une fois la clef maîtresse hors de la mémoire, vous n’avez que des blocs chiffrés que personne ne pourra déchiffrer sans le mot de passe maître. Pas même vous. Si vous oubliez votre mot de passe maître, vous ne pourrez plus jamais relire ce que vous avez stocké. Même votre ami qui s’y connait ne pourra rien pour vous.
Ne vous laissez toutefois par leurrer. On parle sécurité, chiffrement, complexité des fonctions de dérivation de clef, mais en réalité tout ça a peu d’importance comparé à votre mot de passe maître. C’est un peu comme un coffre-fort : Discuter du diamètre des barres de renfort n’a aucun intérêt s’il s’ouvre avec une combinaison de trois chiffres seulement.
S’il est possible de trouver votre mot de passe avec un nombre de tentatives limité, tout le reste ne servira à rien. « Limité » dans ce cas, ça dépasse la centaine de milliards de combinaisons. Il vaut mieux un mot de passe maître complexe avec une fonction de dérivation simple qu’un mot de passe maître simple avec une fonction de dérivation complexe.
Changer le mot de passe
Les plus alertes d’entre vous auront remarqué que si tout est déchiffré indirectement à partir du mot de passe, changer le mot de passe fait perdre l’accès à tout ce qui est déjà chiffré.
Quand vous changez votre mot de passe maître, Keepass déchiffre toutes les données en mémoire, calcule la nouvelle clef et rechiffre l’intégralité des données. Même si vous gérez une centaine de mots de passe, c’est quelque chose qui se fait rapidement sans avoir besoin de vous faire patienter longtemps.
Bitwarden utilise lui une clef intermédiaire totalement aléatoire appelée clef de chiffrement. C’est cette clef qui sert en réalité à chiffrer et déchiffrer les données stockées. Elle est elle-même chiffrée, à partir de la clef maîtresse, et stockée à côté des données.
On a donc un mot de passe maître qui sert à calculer une clef maîtresse. La clef maîtresse sert à déchiffrer la clef de chiffrement. La clef de chiffrement sert à chiffrer et déchiffrer les données sur le disque.
Lorsqu’on veut changer de mot de passe il suffit de chiffrer la clef de chiffrement avec la nouvelle clef maitresse. Il n’y a pas besoin de rechiffrer chaque donnée (vu que la clef de chiffrement ne change pas, elle).
L’avantage n’est pas tant dans le temps gagné (peu significatif) mais dans la résistance aux accès concurrents : On peut avoir plusieurs clients qui lisent et écrivent en parallèle des données différentes dans le même trousseau sans crainte que l’un d’eux n’utilise encore une ancienne clef de chiffrement et envoie des données illisibles par les autres.
Et justement, et si je partage ?
Avec ce qu’on a vu jusqu’à présent, si je partage des mots de passe je dois aussi partager la clef de chiffrement utilisée.
Bitwarden permet de partager des mots de passe à un groupe de plusieurs personnes (appelé « organisation »). Au lieu d’être chiffrés avec ma clef de chiffrement personnelle, ces mots de passe sont chiffrés avec une clef de chiffrement dédiée à l’organisation.
Le gros enjeu n’est pas dans le chiffrement mais dans comment transmettre cette clef d’organisation à chaque utilisateur de l’organisation.
Il faut un moyen pour que l’administrateur de l’organisation chiffre la clef d’organisation, me l’envoie sur le serveur d’une façon que seul moi puisse la relire.
Jusqu’à maintenant c’est impossible parce que nous utilisons des clefs symétriques. C’est la même clef qui sert au chiffrement et au déchiffrement. Si l’administrateur pouvait chiffrer avec ma clef, il pourrait aussi déchiffrer tous mes mots de passes personnels et ça c’est inacceptable.
C’est donc ici qu’on reparle des clefs asymétriques RSA. Chacun a une clef publique (diffusée à tout le monde) et une clef privée (garder secrète par chaque utilisateur). La clef publique sert à chiffrer. La clef privée sert à déchiffrer. Tout le monde est donc capable de chiffrer quelque chose avec ma clef publique, mais seul moi pourrait le déchiffrer.
La clef RSA fait 2048 bits mais ne vous laissez pas impressionner, ces 2048 bits sont en fait moins robustes que les 256 bits d’AES.
L’administrateur de l’organisation récupère ma clef publique, chiffre la clef d’organisation à l’aide de ma clef publique, et envoie ça sur le serveur. Quand je voudrais chiffrer ou déchiffrer quelque chose dans l’organisation, je récupère la clef d’organisation chiffrée avec ma clef publique, je la déchiffre avec ma clef privée, et je m’en sers dans mes opérations de chiffrement.
Ok, mais il va me falloir sécuriser ma clef privée. On a déjà les outils pour ça, il suffit de la chiffrer ! Bitwarden la chiffre donc avec la clef de chiffrement, celle dont on a déjà parlé plus haut.
On a donc un mot de passe maître qui sert à calculer une clef maîtresse. La clef maîtresse sert à déchiffrer la clef de chiffrement. La clef de chiffrement sert à déchiffrer ma clef RSA privée. La clef RSA privée sert à déchiffrer la clef d’organisation. La clef d’organisation sert à chiffrer et déchiffrer les données.
Pfiou! Ça semble long et complexe mais tout utilise toujours le même principe et la plupart de ces opérations ne servent qu’à l’initialisation logiciel quand vous le déverrouillez.
Rappelez-vous, votre clef de chiffrement ne change pas quand vous changez votre mot de passe. Pas besoin donc de changer ou rechiffrer vos clefs RSA non plus.
Et Pass alors ?
Pass fait le choix de sauter tout le chiffrement symétrique et de n’utiliser que l’asymétrique. Un dépôt contient les clefs GPG de tous les membres (clefs publiques). Chaque fois qu’un mot de passe est chiffré, il l’est avec toutes ces clefs. Quand un membre veut lire un des mots de passe, il le déchiffre avec sa propre clef privée.
Quand on ajoute un membre, quand on change une clef, il faut tout rechiffrer.
Le mainteneur d’un paquet NPM n’a plus eu envie et a donné la main à un tiers. Ce tiers a injecté un code malicieux dans une version publique et potentiellement infecté pas mal de monde. Ça n’a été détecté qu’au bout de deux mois et demi alors que le paquet est utilisé un peu partout.
J’en vois qui lancent des blâmes ou qui se moquent sur l’actualité du paquet NPM malicieux. Ça défoule mais : Faites-vous mieux ? Permettez-moi d’en douter très très fortement.
Le moindre projet React, Symfony ou Rails, c’est une centaine de dépendances directes et indirectes, certaines proviennent de sources dont vous n’avez jamais entendu parler. J’ai listé trois frameworks mais c’est bien la même chose sur les autres langages/technos.
C’est bien le sujet : Sauf si vous avez la taille d’un Facebook/Google ou la criticité d’un Thalès ou d’un état, vous n’avez ni les moyens de passer des années-homme à tout recoder en interne, ni les moyens d’auditer chaque source à chaque mise à jour (si tant est que ça suffise).
Même ceux que j’ai nommé, je ne suis pas certains qu’ils le fassent toujours, sur tous les types de projet. Je suis même assez convaincu du contraire. Le ratio bénéfice/risque n’est juste pas assez important pour ça. Les moyens et les délais ne sont pas dimensionnés pour.
Alors moquez-vous, de ceux qui utilisent NPM, de ceux qui ne contrôlent pas l’ensemble des dépendances, mais vous ne faites probablement pas mieux. Il y a pas mal d’hypocrisie dans les réactions que je vois passer.
Ne blâmez pas non plus le mainteneur d’origine. Lui ne vous a jamais rien promis. C’est même dit explicitement dans la licence « aucune garantie d’aucune sorte ». Ce n’est pas parce que d’autres utilisent son code gratuitement qu’il aurait magiquement des comptes à rendre. En fait avoir passé la main est plutôt quelque chose d’encouragé dans l’open source. S’il n’y avait pas eu cette issue, il aurait plutôt fallu le remercier.
Alors quoi ? Alors rien.
Le problème a été résolu. Si ça arrive trop souvent alors ça changera le ratio bénéfice/risque et la communauté évaluera le fait d’avoir trop de dépendances tierces un (tout petit) peu plus négativement, et ainsi de suite.
La question intéressante que personne ne semble poser c’est celle de l’honnêteté du mainteneur d’origine. A-t-il vraiment passé la main ? et s’il l’a fait, est-ce qu’il en a tiré un bénéfice tout en soupçonnant ce qui pouvait se passer ? C’est à peu près la seule chose qui pourrait à mon sens lui faire porter une quelconque responsabilité.
J’ai déjà parlé de testament numérique une ou deux fois ici. J’ai déjà vue une amie devoir appeler à l’aide pour se récupérer pas à pas une maigre partie de la vie numérique à la disparition de son mari.
On trouve toujours une solution à tout ce qui est administratif mais ça peut être une difficulté supplémentaire à un moment qui n’est déjà pas le plus simple.
À la maison c’est tout le reste qui risque de poser problème. On parle de toute la paperasse numérisée ou de tout l’historique de 15 ans de photos. J’utilise des mots de passe complexes, différents à chaque fois, et je chiffre tous mes disques. Autant dire que si je pars tout deviendra assez rapidement illisible malgré les meilleurs efforts de mes amis.
Je ne vois pas d’autres solutions que de laisser le double de mes clefs au crochet avant de partir.
La solution elle est connue depuis longtemps, j’avais déjà parlé du principe du secret de Shamir il y a quelques années mais j’ai procrastiné. Ce n’est jamais le bon moment pour penser à la mort.
J’ai pris mon courage à deux mains, je vous propose ce qui est en cours, en espérant l’enrichir par vos commentaires ou aider quelques autres personnes à faire leur propre chemin.
Le secret de shamir
Le principe est assez simple. C’est un calcul mathématique qui permet de diviser un secret en plusieurs parties. Chaque partie est illisible indépendamment mais permet de reconstituer le secret initial si on en met un certain nombre ensemble.
Je peux par exemple dire « je divise ce secret en cinq parties qui seront chacune détenue par des personnes différentes, pour reconstituer le secret initial il faudra la collaboration d’au moins trois personnes sur les cinq ».
Il y a plusieurs logiciels pour cela. La vraie contrainte est d’en trouver un qui sera utilisable dans 5 ou 10 ans. Je suis parti sur ssss de B. Poettering : Le logiciel a déjà 12 ans, open source, présent sur les différentes distributions Linux, et a quelques fork visibles. La durabilité semble acquise. J’avais hésité avec libgfshare qui partage à peu près les mêmes caractéristiques de vie.
Les destinataires
Les nombres de trois et cinq dans mon exemple précédent sont des choix arbitraires. Trois c’est permettre d’avoir assez de résistance pour que le secret ne fuite pas trop facilement, que ce soit par malveillance, par la tromperie d’un tiers, ou simplement par négligence. Cinq c’est le minimum pour permettre d’avoir au moins deux personnes injoignables le jour où on en a besoin.
Plus de cinq n’est pas si simple : Il faut des gens en qui j’ai totale confiance au point de leur laisser les clefs de ma vie numérique, qui ne vont pas en faire mauvais usage, qui ne vont pas laisser d’autres en faire mauvais usage, qui ne vont pas laisser trainer leur secret par négligence mais qui vont en assurer la pérennité sur potentiellement des années. Au delà, il faut idéalement des gens que connait bien ma femme pour que prendre contact ne soit pas une difficulté supplémentaire au mauvais moment, et qu’ils soient suffisamment au fait des questions technologiques pour que leur aide ne se limite pas à « tiens, j’ai un papier à te donner » mais soit plus proche de « prends soin de toi, on s’occupe de tout ». Et puis j’aimerais éviter de faire porter ce poids à cinquante amis.
En ce moment je les contacte pour leur demander leur accord. C’est quand je vois les réponses positives que je me rends compte que j’ai choisi les bons.
Le secret
Impossible de lister les centaines de mots de passe et comptes que je peux avoir partout. Même en limitant à ce qui est important, je crains que les mots de passe ne changent d’ici à ce que ça serve, ou qu’il y en ait de nouveaux.
Je vais laisser le mot de passe de ma boite email, de mon poste de travail, du serveur NAS avec toutes les photos, de mon espace de sauvegarde et quelques autres trucs du genre mais c’est plus pour avoir ceinture et bretelles.
L’idée c’est surtout que je partage le mot de passe et les identifiants de connexion de mon gestionnaire de mots de passe. Normalement tout est faisable à partir de là. Aujourd’hui c’est du Bitwarden. Je ne sais pas si la société est vraiment pérenne mais le code est open source et il y a déjà des clones, donc j’ai bon espoir de ne pas avoir à renvoyer un nouveau secret vers un autre système dans six mois.
C’est aussi dans Bitwarden que je peux laisser une note avec tout ce que je veux dedans comme informations et procédures, et la mettre à jour quand je veux sans savoir à générer et envoyer un nouveau secret à tout le monde.
Le document
Le secret lui même est donc très court, juste quelques mots de passe. Il n’est de toutes façons pas possible d’aller au delà de 1024 caractères ASCII avec ssss.
Je compte mettre ça dans un beau document PDF A4 que mes destinataires peuvent à la fois garder dans leurs archives numériques et imprimer pour leurs archives papier plus durables (même les geeks foirent leurs sauvegardes numériques).
Dans ma tête je me dis qu’il faudra joindre les amis formellement une fois par an pour leur demander de vérifier qu’ils n’ont pas perdu leur propre partie du secret et voir s’ils ont changé de coordonnées. En pratique je ne sais pas si je ferais ça aussi sérieusement qu’il le faudrait, donc je considère que le document doit tout contenir.
Au delà de leur partie du secret, ce document récapitule un peu tout ça : À quoi ça sert, quels sont les autres destinataires à joindre et à quelles coordonnées (email, téléphone, adresse postale, éventuellement adresses électroniques), mais aussi comment reconstituer le secret original (nom et adresse du logiciel, procédure) et ce que j’attends d’eux.
Un peu d’aide
Ce billet est déjà trop long. Je vous proposerai peut-être une suite avec le texte exact du document en question, pour aider les suivants à faire le leur.
Entre temps je veux bien vos commentaires pour avancer, ou quelques détails sur ce que vous avez mis en place de votre côté.
J’amorce mon départ de Gmail, dans la lignée de la reprise de contrôle sur mes données. Le problème avec les emails c’est qu’on est dans un écosystème où tout est échangé en clair.
J’ai abandonné l’idée de convertir tout le monde à GPG. En fait j’ai même abandonné l’idée de m’y convertir moi-même. J’ai longtemps eu des clefs exposées sur mes profils en ligne et malgré un réseau très geek sensible à ces questions, je crois que je n’ai jamais reçu un seul email chiffré.
Bref, vous échangez les emails en clair avec l’extérieur et vous ne pourrez rien faire contre ça. Vous pouvez cependant chiffrer vos archives et tout email dès sa réception. C’est ce que font Protonmail, Tutanota et Mailden.
Mailden ce sont des versions modifiés de Postfix et Dovecot qui chiffrent et déchiffrent les emails à la volée pour vous. Le serveur a donc accès à vos clefs quand vous vous y connectez mais promet de les oublier dès que la connexion prend fin. L’avantage c’est que de votre point de vue vous avez un serveur email tout ce qu’il y a de plus classique.
Protonmail et Tutanota gèrent eux un vrai chiffrement de bout en bout. Le serveur ne voit jamais passer votre clef de déchiffrement. Seul vous pourrez lire vos email une fois qu’ils ont été chiffrés. En échange il vous faudra des applications email spécifiques ou un proxy de déchiffrement intermédiaire.
Aucun des deux modèles n’est parfait. Tutanota me tente mais ça reste assez spartiate et j’ai peur que leur approche de la recherche m’empêche d’y indexer toutes mes archives. Disons que ça sera à tester avant de s’engager.
Mailden pourrait être une option mais si c’est pour faire confiance au serveur lors de la réception des emails, lors de l’envoi des email, lors de chaque accès, et que contacts comme calendriers devront être gérés totalement en clair chez un autre hébergeur…
… Je commence à me demander si tout ça vaut le coup et si je ne devrais pas juste souscrire à la gamme complète chez Fastmail. Ce ne sera pas chiffré mais c’est un bon choix et je leur fais confiance pour ne pas exploiter mes données privées. Ce pourrait être un compromis pertinent le temps que Tutanota et les offres similaires soient un peu plus abouties.
Pourquoi pas Protonmail plutôt que Tutanota ?
Sécurité : Tutanota chiffre les contacts et le sujet des emails, pas Protonmail. Tutanota propose aussi ses applications clientes en open source, ce qui apporte un peu plus de garantie ou permet d’héberger soi-même le webmail.
Utilisation : Protonmail a la bonne idée d’offrir un proxy pour utiliser un vrai client email sur le poste fixe mais en échange l’app mobile ne saura pas faire de recherche dans le contenu des emails, ce qui me parait un défaut très sérieux.
Prix : Au delà de 5 Go, Protonmail est prohibitif. On parle de 1€ le Go par mois.
Pour mon usage, avec un gros quota et un usage mobile complet, le choix est vite fait.
Je cherche essentiellement à me protéger de quelqu’un qui volerait mon disque après s’être introduit chez moi. Je garde donc une partition en clair pour le système principal et je mettrai les données sur une partition chiffrée que je monte manuellement.
Certaines documentations proposent de mettre la clef de chiffrement sur un petit stockage USB mais ça ne me semble pas pertinent pour la menace dont je cherche à me protéger.
J’ai une passphrase dans mon gestionnaire de mots de passe et ça me suffira. Je ne compte pas m’en servir souvent de toutes façons. Avantage supplementaire par rapport à la version sur USB : Je peux me connecter en SSH et monter la partition à distance pour peu que je ne craigne pas que quelqu’un se soit introduit sur ma partition système entre temps.
Des documentations je retiens le chiffrement de blocs avec luks, et le fait de bien passer par cryptsetup plutôt que de tout gérer à la main.
La passphrase vient du générateur aléatoire de mon gestionnaire de mot de passe. J’ai cherché un intermédiaire entre « le plus long possible » et « si ça se trouve j’aurais à la taper à la main un jour ». En temps normal ce ne sera que des copier/coller donc ça ira.
Script de montage
#!/bin/bash
# /usr/local/sbin/mount.data
cryptsetup luksOpen /dev/sda4 data
mount /mnt/data
Script de démontage
#!/bin/bash
# /usr/local/sbin/umount.data
umount /mnt/data
cryptsetup luksClose data
Je l’ai créé mais j’avoue que je vois mal dans quel cas je vais avoir envie de démonter ma partition sans arrêter totalement le système (et dans ce cas ça sera fait tout seul sans mon intervention de toutes façons).
Faire de la cryptographie dans le navigateur se révèle bien plus simple que prévu.
Laissez tomber les portages de libsodium & co. Quasiment tous les navigateurs supportent désormais une API native dédiée. Seul IE11 ne le fait pas totalement mais il a au moins le minimum qu’est la génération de nombres réellement aléatoires. Ceux qui veulent vraiment pourront compléter l’implémentation d’IE11 avec un polyfill sans risquer de problème de sécurité.
Il y a plein de jolis exemples sur qnimate mais certaines choses datent un peu. J’ai tenté de résumer ici pour ceux que ça intéresse. Ici pour du déchiffrement à partir d’une clef secrète.
Avant-propos
Je ne suis pas un expert en chiffrement et ce genre de choses est toujours à manier avec précaution. Si vous faites quelque chose de sérieux, ne vous contentez pas d’exemples et embauchez quelqu’un qui sait.
Rien que choisir l’algorithme pertinent demande de savoir ce qu’on fait. AES-CTR semble pertinent pour mon cas d’usage où n’ai pas besoin de vérifier l’authenticité du message, où je n’ai pas envie de me coltiner les questions de padding, et où je serai heureux de profiter des multiples cœurs des smartphones.
Si l’algorithme choisi ou autre chose vous dérange et que vous en savez plus que moi, n’hésitez pas à commenter.
Récupérer une clef
Le plus simple est de récupérer directement une clef au format JSON Web Key (en gros la clef en base64url plus un peu de métadonnées). Dans ce cas il suffit de passer par importKey :
Si on veut partir d’une phrase secrète mémorisable et non d’une clef complète, on commence par créer une clef temporaire et on utilise un algorithme de dérivation comme PBKDF2.
Malheureusement pour créer cette première clef il faut passer par un TextEncoder et ArrayBuffer. peut toujours dériver la clef à partir de là. TextEncoder n’existe pas sous Edge et IE11, il vous faudra utiliser une fonction comme unibabel qui fait ça pour vous.
La sécurité de tout ça dépend de la longueur et de l’unicité de votre phrase secrète initiale. À vous de trouver le bon compromis entre la sécurité et la puissance des smartphones qui risquent d’utiliser votre code. Le 25 ici est purement arbitraire et le temps de calcul nécessaire est proportionnel.
Déchiffrer
Déchiffrer n’est pas plus difficile.
Le vecteur d’initialisation (iv) et la donnée chiffrée (encrypted) sont attendus sous forme d’ArrayBuffer. Il faudra de nouveau passer par unibabel ou une autre solution si vous avez ça sous forme de chaîne binaire ou codé en base64.
Le résultat de decrypt() vous est retourné sous la même forme. S’il est petit le plus simple est d’utiliser TextDecoder ou unibabel. Si vous avez quelque chose de plus volumineux vous pouvez aussi passer par un Blob et un FileReader.
Je partage, ça peut servir à d’autres. Je cherchais à garder confidentiel une information confidentielle le temps d’une session de navigation. En gros je cherchais un genre de cookie de session mais qui reste côté client sans jamais transiter sur le réseau.
Le localStorage est top mais il persiste au delà de la session de navigation. Le sessionStorage est top mais il n’est pas partagé entre les onglets.
Visiblement certains se sont penchés sur la question il y a quelques années et sont revenus avec une solution toute bête mais efficace : Faire dialoguer les différents sessionStorage en surveillant les écritures dans le localStorage.
Je ne veux plus gérer de serveur en ligne. Je me sens de moins en moins capable d’assurer la sécurité d’un tel environnement 24/7 seul et sur mon temps personnel. Je n’en ai pas la motivation, ne souhaite pas y investir le temps nécessaire. Ne parlons même pas de la possibilité de prendre des congés deux semaines hors de France sans connexion Internet ni veille sécurité. Rien qu’avoir ce blog sous wordpress me gêne.
Je vais déplacer mes services sur un environnement mutualisé, géré par des professionnels qui ont les moyens, le temps et les compétences. Je vais en profiter pour passer à peu près tout en fichiers HTML statiques. Publier des fichiers html, css et images sur un espace à 2€, ça limite pas mal la maintenance.
* * *
Mon problème c’est que j’ai aussi des parties de site à accès restreint, avec des documents qui ne doivent pas sortir n’importe où.
Je peux facilement trouver un hébergement mutualisé qui me permet de faire des accès restreints par authentification HTTP ou avec un bout de PHP en façade, mais j’ai une confiance limitée dans la confidentialité des fichiers que je peux poser sur un hébergeur mutualisé.
Du coup j’imagine utiliser du chiffrement côté client, avec un croisement entre Jekyll/Pelican et 0bin/cryptopad. Je chiffre les contenus lors de la génération et je les envoie chiffrés sur l’hébergement. Les contenus sont déchiffrés dans le navigateur du client avec un gros bout de JS, en utilisant un dérivé de mot de passe ou une clef cachée dans l’URL.
Le seul défaut que je vois c’est interdire l’accès à ceux qui désactivent volontairement Javascript, et imposer un peu d’attente aux autres pour déverrouiller les contenus : Pas idéal, pas pertinent pour tous les usages, mais ici ça me semble acceptable.
* * *
Il y a 0bin et Cryptopad (ainsi que d’autres) qui fonctionnent un peu sur ce principe, mais brancher ça dans Jekyll ou Pelican me semble nécessiter un peu de travail, surtout si je veux avoir plus que du texte et que je veux présenter à l’utilisateur uniquement les liens auxquels il a accès.
Si vous connaissez un CMS à publication statique qui a envisagé quelque chose du genre, je suis preneur.
Oui, je sais, ça agace tout le monde alors plutôt que de vous dire quoi ne pas faire, on va se contenter de dire quoi faire, et on va être réaliste en y mettant un niveau d’effort et d’emmerdement très bas. J’écris des tartines mais ça se résume en 5 principes :
La première règle théorique c’est de ne pas réutiliser le même mot de passe deux fois, de ne pas les écrire en clair dans un fichier informatique (et si ce sont des mots de passe professionnels sensibles, de ne pas les écrire du tout).
Je ne sais pas vous mais j’ai trois zillions de sites, appareils et services qui me demandent un mot de passe. Cette première règle théorique est déjà impossible à suivre humainement. Il n’y a pas à tortiller, la première recommandation est incontournable :
1. Utilisez un gestionnaire de mots de passe
Un gestionnaire de mots de passe c’est une sorte de coffre fort pour vos mots de passe. Seul vous y avez accès.
Certains vous permettent de synchroniser ce coffre-fort sur vos différents appareils et vous offrent une interface pratique pour trouver et remplir les mots de passe qui vous sont demandés tout au long de la journée. Non seulement c’est plus sûr que vos anciennes habitudes, mais en plus ça sera plus pratique qu’avant. Tout bénef.
Je peux par exemple vous recommander l’open source Bitwarden mais il y a bien d’autres alternatives.
Oh, et comme vous avez un beau gestionnaire de mots de passe dédié, désactivez la mémorisation automatique des mots de passe de votre navigateur, votre gestionnaire de mots de passe s’en chargera à sa place. Je parie une bière que vous ne l’aviez de toutes façons pas configuré pour être aussi robuste que ce dernier (Chrome ne le permet d’ailleurs même pas pas).
2. Désactiver la mémorisation des mots de passe de votre navigateur
Maintenant il va falloir créer tous ces mots de passe différents qu’on va ensuite stocker dans le gestionnaire de mots de passe. Un bon mot de passe est long, complexe, aléatoire, unique.
Bien évidemment, n’utilisez *jamais* de générateur de mot de passe en ligne. Vous auriez un risque que votre mot de passe se retrouve immédiatement dans les listes à tester par les robots.
Tous les gestionnaires de mots de passe vous offriront un moyen sûr de générer des mots de passe de bonne qualité. Ils feront dans les 16 caractères avec différentes casses et des caractères spéciaux mais on s’en moque : Vous n’aurez ni à les retenir ni à les taper. En fait vous n’avez même pas besoin de savoir à quoi ils ressemblent.
3. Utilisez le générateur de mots de passe intégré à votre outil
Parfois un administrateur ou un service choisissent eux-même un mot de passe initial. Changez-le avec un généré par vos soins.
Si on vous dit qu’il est nécessaire de laisser le mot de passe qu’on vous a donné, ça doit lancer une alarme dans votre tête : Au mieux votre interlocuteur n’est pas compétent ou le service n’est pas sûr, au pire quelqu’un se réserve volontairement la capacité d’accéder à vos données. Dans tous les cas vous n’êtes pas en zone sécurisée sur ce service.
4. Ne laissez jamais les mots de passe par défaut, changez-les
Il reste qu’il faut retenir le mot de passe qui donne accès au gestionnaire de mots de passe lui-même. Il faut aussi retenir celui pour ouvrir la session sur le poste de travail personnel et celui pour le pendant professionnel. Personnellement je retiens aussi celui de ma boite email perso, qui donne virtuellement accès à tout si je perds les autres clefs.
J’ai trois possibilités :
Retenir 4x 16 caractères et symboles aléatoires.
Utiliser une suite de symboles qui dérivent d’une phrase qu’on peut retenir
Utiliser une suite de mots plutôt qu’une suite de caractères
Le (2) c’est ce que propose par exemple l’outil de la CNIL. Il est un peu agaçant parce qu’il reconnait assez peu de choses comme des caractères spéciaux, mais ça montre bien la démarche.
Le (3) part de l’idée opposée. On tire au hasard une suite de mots dans une liste. Certains proposent de simplement les tirer au dé. Il est possible d’améliorer la mémorisation de ces mots en imaginant une petite histoire ou petite comptine qui les utilise.
Dans les deux cas l’idée est de relier le mot de passe à une phrase ou des mots qui se mémorisent plus facilement.
5. Utilisez une méthode « sure » pour générer les quelques mots de passe que vous devrez vraiment retenir vous-même
Le danger c’est que notre imagination est limitée par notre environnement.
N’utilisez pas un proverbe ou un refrain pour le (2), même si ça vous semble peu connu (un ordinateur est capable de tester des dizaines de millions de proverbes ou refrains « peu connus », c’est à dire plus que vous n’en connaissez vous-même et les variantes que vous pouvez en imaginer).
Chaque suite de termes évidents affaiblira votre mot de passe. Tiens, est-ce que vous avez commencé votre phrase par « Je », « Il » ou « Le » ? Vous avez le droit de rajouter un mot/symbole parce que le premier ne compte plus.
Ne choisissez pas vous-même les mots pour le (3). Le vocabulaire passif de quelqu’un de cultivé est limité à quelques milliers de mots. Le vocabulaire courant est bien plus faible et celui que vous aurez le loisir d’avoir en tête sera de quelques centaines tout au plus, avec une série de mots à très forte probabilité (par exemple tout ce qui est lié à l’informatique, à la sécurité ou à ce qui se trouve proche de votre bureau).
N’utilisez rien qui vous est propre (date, nom, entreprise, événement, musique préférée, etc.) Ne vous croyez pas plus fin que les autres en cherchant activement un mot complexe, en opérant des variations ou remplacements de lettres. Un robot sera bien plus efficace que vous à ces petits jeux. Vraiment.
* * *
Et voilà. Maintenant vous avez des mots de passe sûrs, uniques, stockés en sécurité. C’est déjà infiniment mieux que la moyenne, et ça ne vous a pas coûté grand chose en effort.
La dernière étape c’est de renouveler vos anciens mots de passe : ceux qui peuvent être trouvés par des robots, ceux qui sont les mêmes sur plusieurs services, etc. Certains gestionnaires de mots de passe comme Dashlane peuvent même le faire pour vous.
Bonus : Renouvelez vos anciens mots de passe peu sûrs
Si vous avez envie d’aller plus loin on peut parler de ne pas laisser déverrouillé votre gestionnaire de mots de passe, de mettre en place une authentification à double facteur, de bien penser à ce que vos postes de travail et votre smartphone se verrouillent immédiatement après une courte période d’inactivité, qu’ils demandent une authentification au réveil, qu’ils aient des disques chiffrés… mais tout ça est pour un second épisode.
