Carnet de notes

Catégorie : Technique

  • Un serveur email chif­fré

    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 écosys­tème où tout est échangé en clair.

    J’ai aban­donné l’idée de conver­tir tout le monde à GPG. En fait j’ai même aban­donné l’idée de m’y conver­tir moi-même. J’ai long­temps eu des clefs expo­sées sur mes profils en ligne et malgré un réseau très geek sensible à ces ques­tions, je crois que je n’ai jamais reçu un seul email chif­fré.

    Bref, vous échan­gez les emails en clair avec l’ex­té­rieur et vous ne pour­rez rien faire contre ça. Vous pouvez cepen­dant chif­frer vos archives et tout email dès sa récep­tion. C’est ce que font Proton­mail, Tuta­nota et Mail­den.

    Mail­den ce sont des versions modi­fiés de Post­fix et Dove­cot qui chiffrent et déchiffrent les emails à la volée pour vous. Le serveur a donc accès à vos clefs quand vous vous y connec­tez mais promet de les oublier dès que la connexion prend fin. L’avan­tage c’est que de votre point de vue vous avez un serveur email tout ce qu’il y a de plus clas­sique.

    Proton­mail et Tuta­nota gèrent eux un vrai chif­fre­ment de bout en bout. Le serveur ne voit jamais passer votre clef de déchif­fre­ment. Seul vous pour­rez lire vos email une fois qu’ils ont été chif­frés. En échange il vous faudra des appli­ca­tions email spéci­fiques ou un proxy de déchif­fre­ment inter­mé­diaire.

    Aucun des deux modèles n’est parfait. Tuta­nota me tente mais ça reste assez spar­tiate et j’ai peur que leur approche de la recherche m’em­pêche d’y indexer toutes mes archives. Disons que ça sera à tester avant de s’en­ga­ger.

    Mail­den pour­rait être une option mais si c’est pour faire confiance au serveur lors de la récep­tion des emails, lors de l’en­voi des email, lors de chaque accès, et que contacts comme calen­driers devront être gérés tota­le­ment en clair chez un autre héber­geur…

    … Je commence à me deman­der si tout ça vaut le coup et si je ne devrais pas juste sous­crire à la gamme complète chez Fast­mail. Ce ne sera pas chif­fré mais c’est un bon choix et je leur fais confiance pour ne pas exploi­ter mes données privées. Ce pour­rait être un compro­mis perti­nent le temps que Tuta­nota et les offres simi­laires soient un peu plus abou­ties.

    Pourquoi pas Proton­mail plutôt que Tuta­nota ?

    Sécu­rité : Tuta­nota chiffre les contacts et le sujet des emails, pas Proton­mail. Tuta­nota propose aussi ses appli­ca­tions clientes en open source, ce qui apporte un peu plus de garan­tie ou permet d’hé­ber­ger soi-même le webmail.

    Utili­sa­tion : Proton­mail a la bonne idée d’of­frir un proxy pour utili­ser 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, Proton­mail est prohi­bi­tif. 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.

  • Mes données dans une parti­tion chif­frée sous Linux

    Je cherche essen­tiel­le­ment à me proté­ger de quelqu’un qui vole­rait mon disque après s’être intro­duit chez moi. Je garde donc une parti­tion en clair pour le système prin­ci­pal et je mettrai les données sur une parti­tion chif­frée que je monte manuel­le­ment.

    Certaines docu­men­ta­tions proposent de mettre la clef de chif­fre­ment sur un petit stockage USB mais ça ne me semble pas perti­nent pour la menace dont je cherche à me proté­ger.

    J’ai une pass­phrase dans mon gestion­naire de mots de passe et ça me suffira. Je ne compte pas m’en servir souvent de toutes façons. Avan­tage supple­men­taire par rapport à la version sur USB : Je peux me connec­ter en SSH et monter la parti­tion à distance pour peu que je ne craigne pas que quelqu’un se soit intro­duit sur ma parti­tion système entre temps.

    Des docu­men­ta­tions je retiens le chif­fre­ment de blocs avec luks, et le fait de bien passer par crypt­se­tup plutôt que de tout gérer à la main.

    Je reco­pie ici mes quelques commandes mais c’est tout bien expliqué sur la docu­men­ta­tion crypt­se­tup du wiki Ubuntu.

    Créa­tion

    sudo apt install cryptsetup
sudo cryptsetup luksFormat -c aes -h sha256 /dev/sda4
sudo cryptsetup luksOpen /dev/sda4 data
sudo mkfs.ext4 -L data /dev/mapper/data
sudo mkdir /mnt/data
sudo echo "data /dev/sda4 none luks,noauto,quiet" >> /etc/crypttab
sudo echo "/dev/mapper/data /mnt/data ext4 rw,nosuid,exec,noauto,async,user,noatime,nodiratime 0 0" >> /etc/fstab
sudo mount /mnt/data

    La pass­phrase vient du géné­ra­teur aléa­toire de mon gestion­naire de mot de passe. J’ai cher­ché un inter­mé­diaire entre « le plus long possible » et « si ça se trouve j’au­rais à 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émon­tage

    #!/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émon­ter ma parti­tion sans arrê­ter tota­le­ment le système (et dans ce cas ça sera fait tout seul sans mon inter­ven­tion de toutes façons).

  • Comment on fait de la crypto dans le navi­ga­teur ?

    Faire de la cryp­to­gra­phie dans le navi­ga­teur se révèle bien plus simple que prévu.

    Lais­sez tomber les portages de libso­dium & co. Quasi­ment tous les navi­ga­teurs supportent désor­mais une API native dédiée. Seul IE11 ne le fait pas tota­le­ment mais il a au moins le mini­mum qu’est la géné­ra­tion de nombres réel­le­ment aléa­toires. Ceux qui veulent vrai­ment pour­ront complé­ter l’im­plé­men­ta­tion d’IE11 avec un poly­fill sans risquer de problème de sécu­rité.

    Il y a plein de jolis exemples sur qnimate mais certaines choses datent un peu. J’ai tenté de résu­mer ici pour ceux que ça inté­resse. Ici pour du déchif­fre­ment à partir d’une clef secrète.

    Avant-propos

    Je ne suis pas un expert en chif­fre­ment et ce genre de choses est toujours à manier avec précau­tion. Si vous faites quelque chose de sérieux, ne vous conten­tez pas d’exemples et embau­chez quelqu’un qui sait.

    Rien que choi­sir l’al­go­rithme perti­nent demande de savoir ce qu’on fait. AES-CTR semble perti­nent pour mon cas d’usage où n’ai pas besoin de véri­fier l’au­then­ti­cité du message, où je n’ai pas envie de me colti­ner les ques­tions de padding, et où je serai heureux de profi­ter des multiples cœurs des smart­phones.

    Si l’al­go­rithme choisi ou autre chose vous dérange et que vous en savez plus que moi, n’hé­si­tez pas à commen­ter.

    Récu­pé­rer une clef

    Le plus simple est de récu­pé­rer direc­te­ment une clef au format JSON Web Key (en gros la clef en base64url plus un peu de méta­don­nées). Dans ce cas il suffit de passer par importKey :

    const crypto = window.crypto.subtle;

const jwk = {
  "kty": "oct",
  "use": "enc",
  "k": "SDRSTgdOpUGfgn3iAwiC1cpzsevLM98r_6ehMXlK1Gk",
  "alg": "A256CTR"
};
const algo = {name: "AES-CTR"};
const exportable = false;
const usage = ["decrypt"];

const key = await crypto.importKey("jwk", jwk, algo, exportable, usage);
    Déri­ver une clef

    Si on veut partir d’une phrase secrète mémo­ri­sable et non d’une clef complète, on commence par créer une clef tempo­raire et on utilise un algo­rithme de déri­va­tion comme PBKDF2.

    Malheu­reu­se­ment pour créer cette première clef il faut passer par un TextEn­co­der et ArrayBuf­fer. peut toujours déri­ver la clef à partir de là. TextEn­co­der n’existe pas sous Edge et IE11, il vous faudra utili­ser une fonc­tion comme uniba­bel qui fait ça pour vous.

    const crypto = window.crypto.subtle;
const encoder = TextEncoder();

const passphrase = "l'eau ça mouille, le feu ça brûle";
const buffer = encoder.encode( passphrase );
const d_algo =  {name: 'PBKDF2'};
const d_exportable = false;
const d_usage = ['deriveBits', 'deriveKey'];
const d_key = await crypto.importKey('raw', buffer, d_algo, d_exportable, d_usage);

const deriv = { 
  name: 'PBKDF2',
  salt: encoder.encode( "c'est le week-end !" ),
  iterations = 25,
  hash: 'SHA-256',
};
const algo = {name: "AES-CTR", length: 256}; 
const exportable = false; 
const usage = ["decrypt"];

const key = await crypto.deriveKey(deriv, d_key, algo, exportable, usage);

    La sécu­rité de tout ça dépend de la longueur et de l’uni­cité de votre phrase secrète initiale. À vous de trou­ver le bon compro­mis entre la sécu­rité et la puis­sance des smart­phones qui risquent d’uti­li­ser votre code. Le 25 ici est pure­ment arbi­traire et le temps de calcul néces­saire est propor­tion­nel.

    Déchif­frer

    Déchif­frer n’est pas plus diffi­cile.

    Le vecteur d’ini­tia­li­sa­tion (iv) et la donnée chif­frée (encryp­ted) sont atten­dus sous forme d’Ar­rayBuf­fer. Il faudra de nouveau passer par uniba­bel ou une autre solu­tion si vous avez ça sous forme de chaîne binaire ou codé en base64.

    Le résul­tat de decrypt() vous est retourné sous la même forme. S’il est petit le plus simple est d’uti­li­ser TextDe­co­der ou uniba­bel. Si vous avez quelque chose de plus volu­mi­neux vous pouvez aussi passer par un Blob et un FileRea­der.

    const crypto = window.crypto.subtle;
const decoder = TextDecoder

const key = ...
const iv = ...
const encrypted = ...

const algo = { name: 'AES-CTR', iv: iv }
const buffer = await crypto.decrypt(alg, key, encryted);

  • Trou­ver un héber­geur pour des fichiers statiques

    Je conti­nue l’ex­plo­ra­tion pour la bascule de mon héber­ge­ment, et plus préci­sé­ment l’hé­ber­ge­ment de mes fichiers statiques.

    Idéa­le­ment j’ai besoin d’un quota de 1 ou 2 Go, de pouvoir y bran­cher 4 domaines diffé­rents avec du HTTPS, de pouvoir régler des entêtes de cache correctes sur les fichiers que je veux, et si possible défi­nir des règles de redi­rec­tion ou de réécri­ture. Pas de PHP, pas de base de données, pas de trucs qui consomment du CPU.

    On m’a proposé pas mal de choses, pour l’ins­tant je retiens, dans cet ordre :

    Netlify, qui est opti­misé pour ça et qui a un compte gratuit qui semble conve­nir. Un système qui ne prévoit pas de PHP et de choses consom­ma­trices ça me garan­tit que je ne vais pas me retrou­ver sur une machine à bout de souffle et que tout est dédié à mon usage.

    Lautre.net, asso­cia­tif héri­tage indi­rect de altern.org. On se retrouve sur les clas­siques pas cher qui permettent du PHP et tout plein de choses, et qui géné­ra­le­ment sont un peu à la peine, mais altern.org fut mon premier accès au web et rien que pour ça ça me ferait plai­sir de contri­buer à son survi­vant. La coti­sa­tion à 23€ est abor­dable et c’est pour une asso.

    Gandi simple hosting, dont l’offre small+ssl semble à priori conve­nir et les 36 € de la première année sont accep­tables. Pour les suivantes ça dépen­dra de ce que j’y trouve. J’ima­gi­nais pouvoir héber­ger de bêtes fichiers statiques pour moins cher que 70 €.

    OVH avec les offres d’hé­ber­ge­ment web mutua­lisé. L’offre «  perso » est à 43 € l’an­née mais je ne sais pas trop à quoi m’at­tendre côté qualité.

    Always­data, figure connue, je sais que ça le fera mais le prix commence à monter avec les 80 €.

    Online.net a une offre « perso » à 30 € l’an­née mais je ne sais pas si elle gère plusieurs domaines. Ce n’est pas clair et j’ai les mêmes réserves que les mutua­li­sés OVH.

    Sur le reste, si ça en inté­resse d’autres avec des besoins simi­laires, on m’a aussi pointé o2switch.fr, phpnet.org

    J’ai écarté tout ce qui est à plus de 100 € l’an­née et les « quasi­ment gratuit tout illi­mité » qui ne m’ins­pirent pas du tout confiance, et les offres VPS vu que mon but était juste­ment d’avoir du managé.

    Si vous avez d’autres noms, des recom­man­da­tions ou des commen­taires critiques sur l’un ou sur l’autre, c’est le moment.

  • Donnée confi­den­tielle dans une session de navi­ga­tion.

    Je partage, ça peut servir à d’autres. Je cher­chais à garder confi­den­tiel une infor­ma­tion confi­den­tielle le temps d’une session de navi­ga­tion. En gros je cher­chais un genre de cookie de session mais qui reste côté client sans jamais tran­si­ter sur le réseau.

    Le localS­to­rage est top mais il persiste au delà de la session de navi­ga­tion. Le sessionS­to­rage est top mais il n’est pas partagé entre les onglets.

    Visi­ble­ment certains se sont penchés sur la ques­tion il y a quelques années et sont reve­nus avec une solu­tion toute bête mais effi­cace : Faire dialo­guer les diffé­rents sessionS­to­rage en surveillant les écri­tures dans le localS­to­rage.

    C’est tout con, ça prend juste 20 lignes, mais il fallait y penser.

    Merci Rik

  • Un espace de publi­ca­tion chif­fré côté client

    Je ne veux plus gérer de serveur en ligne. Je me sens de moins en moins capable d’as­su­rer la sécu­rité d’un tel envi­ron­ne­ment 24/7 seul et sur mon temps person­nel. Je n’en ai pas la moti­va­tion, ne souhaite pas y inves­tir le temps néces­saire. Ne parlons même pas de la possi­bi­lité de prendre des congés deux semaines hors de France sans connexion Inter­net ni veille sécu­rité. Rien qu’a­voir ce blog sous word­press me gêne.

    Je vais dépla­cer mes services sur un envi­ron­ne­ment mutua­lisé, géré par des profes­sion­nels qui ont les moyens, le temps et les compé­tences. Je vais en profi­ter 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 main­te­nance.

    * * *

    Mon problème c’est que j’ai aussi des parties de site à accès restreint, avec des docu­ments qui ne doivent pas sortir n’im­porte où.

    Je peux faci­le­ment trou­ver un héber­ge­ment mutua­lisé qui me permet de faire des accès restreints par authen­ti­fi­ca­tion HTTP ou avec un bout de PHP en façade, mais j’ai une confiance limi­tée dans la confi­den­tia­lité des fichiers que je peux poser sur un héber­geur mutua­lisé.

    Du coup j’ima­gine utili­ser du chif­fre­ment côté client, avec un croi­se­ment entre Jekyll/Peli­can et 0bin/cryp­to­pad. Je chiffre les conte­nus lors de la géné­ra­tion et je les envoie chif­frés sur l’hé­ber­ge­ment. Les conte­nus sont déchif­frés dans le navi­ga­teur du client avec un gros bout de JS, en utili­sant un dérivé de mot de passe ou une clef cachée dans l’URL.

    Le seul défaut que je vois c’est inter­dire l’ac­cès à ceux qui désac­tivent volon­tai­re­ment Javas­cript, et impo­ser un peu d’at­tente aux autres pour déver­rouiller les conte­nus : Pas idéal, pas perti­nent pour tous les usages, mais ici ça me semble accep­table.

    * * *

    Il y a 0bin et Cryp­to­pad (ainsi que d’autres) qui fonc­tionnent un peu sur ce prin­cipe, mais bran­cher ça dans Jekyll ou Peli­can me semble néces­si­ter un peu de travail, surtout si je veux avoir plus que du texte et que je veux présen­ter à l’uti­li­sa­teur unique­ment les liens auxquels il a accès.

    Si vous connais­sez un CMS à publi­ca­tion statique qui a envi­sagé quelque chose du genre, je suis preneur.

  • [Aide] Commu­ni­ca­tion entre une page et une exten­sion navi­ga­teur

    J’ai une page qui fait des trai­te­ments javas­cripts basés sur des appels XHR authen­ti­fiés vers son origine et sur des commu­ni­ca­tions en window.postMes­sage avec des <iframe>. Elle n’a besoin d’au­cune permis­sion privi­lé­giée, c’est juste une page web avec une origine normale.

    J’ai­me­rais pouvoir inter­ro­ger cette page depuis une exten­sion Fire­fox et qu’elle me commu­nique le résul­tat de ses trai­te­ments, mais sans que ça n’af­fiche la page à l’uti­li­sa­teur.

    Au départ j’ima­gi­nais que l’ex­ten­sion pouvait lancer une <iframe> cachée et discu­ter avec elle en postMes­sage. On me dit que ce n’est pas possible.

    Embarquer direc­te­ment le code de la page dans l’ex­ten­sion n’est pas envi­sa­geable pour des raisons de sécu­rité (et on ne ferait que repor­ter le problème vu que cette page lance elle-même des iframes pour commu­niquer avec elles).

    Dis, public, est-ce que tu aurais une sugges­tion ou une piste à explo­rer ?

  • La base de travail pour 2018

    Une progres­sive web app prévue d’abord pour mobile, fonc­tion­nant tota­le­ment hors ligne avec une synchro à la prochaine recon­nexion et des données chif­frées côté client.

    Oui, votre besoin a peut-être des usages ou des contraintes qui ne cadrent pas avec ce stéréo­type mais ça mérite proba­ble­ment d’y réflé­chir deux fois avant d’écar­ter un des éléments.

    Quand je vois nombre de projets sans chif­fre­ment des données ou quasi­ment inutiles une fois hors ligne, j’ai l’im­pres­sion de retrou­ver les projets d’il y a quelques années qui consi­dé­raient le mobile comme acces­soire.

  • Et mes mots de passe ?

    Oui, je sais, ça agace tout le monde alors plutôt que de vous dire quoi ne pas faire, on va se conten­ter de dire quoi faire, et on va être réaliste en y mettant un niveau d’ef­fort et d’em­mer­de­ment très bas. J’écris des tartines mais ça se résume en 5 prin­cipes :

    La première règle théo­rique c’est de ne pas réuti­li­ser le même mot de passe deux fois, de ne pas les écrire en clair dans un fichier infor­ma­tique (et si ce sont des mots de passe profes­sion­nels sensibles, de ne pas les écrire du tout).

    Je ne sais pas vous mais j’ai trois zillions de sites, appa­reils et services qui me demandent un mot de passe. Cette première règle théo­rique est déjà impos­sible à suivre humai­ne­ment. Il n’y a pas à tortiller, la première recom­man­da­tion est incon­tour­nable :

    1. Utili­sez un gestion­naire de mots de passe

    Un gestion­naire 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 synchro­ni­ser ce coffre-fort sur vos diffé­rents appa­reils et vous offrent une inter­face pratique pour trou­ver et remplir les mots de passe qui vous sont deman­dés tout au long de la jour­née. Non seule­ment c’est plus sûr que vos anciennes habi­tudes, mais en plus ça sera plus pratique qu’a­vant. Tout bénef.

    Je peux par exemple vous recom­man­der l’open source Bitwar­den mais il y a bien d’autres alter­na­tives.

    Oh, et comme vous avez un beau gestion­naire de mots de passe dédié, désac­ti­vez la mémo­ri­sa­tion auto­ma­tique des mots de passe de votre navi­ga­teur, votre gestion­naire de mots de passe s’en char­gera à sa place. Je parie une bière que vous ne l’aviez de toutes façons pas confi­guré pour être aussi robuste que ce dernier (Chrome ne le permet d’ailleurs même pas pas).

    2. Désac­ti­ver la mémo­ri­sa­tion des mots de passe de votre navi­ga­teur

    Main­te­nant il va falloir créer tous ces mots de passe diffé­rents qu’on va ensuite stocker dans le gestion­naire de mots de passe. Un bon mot de passe est long, complexe, aléa­toire, unique.

    Bien évidem­ment, n’uti­li­sez *jamais* de géné­ra­teur de mot de passe en ligne. Vous auriez un risque que votre mot de passe se retrouve immé­dia­te­ment dans les listes à tester par les robots.

    Tous les gestion­naires de mots de passe vous offri­ront un moyen sûr de géné­rer des mots de passe de bonne qualité. Ils feront dans les 16 carac­tères avec diffé­rentes casses et des carac­tères spéciaux mais on s’en moque : Vous n’au­rez ni à les rete­nir ni à les taper. En fait vous n’avez même pas besoin de savoir à quoi ils ressemblent.

    3. Utili­sez le géné­ra­teur de mots de passe inté­gré à votre outil

    Parfois un admi­nis­tra­teur ou un service choi­sissent eux-même un mot de passe initial. Chan­gez-le avec un généré par vos soins.

    Si on vous dit qu’il est néces­saire de lais­ser le mot de passe qu’on vous a donné, ça doit lancer une alarme dans votre tête : Au mieux votre inter­lo­cu­teur n’est pas compé­tent ou le service n’est pas sûr, au pire quelqu’un se réserve volon­tai­re­ment la capa­cité d’ac­cé­der à vos données. Dans tous les cas vous n’êtes pas en zone sécu­ri­sée sur ce service.

    4. Ne lais­sez jamais les mots de passe par défaut, chan­gez-les

    Il reste qu’il faut rete­nir le mot de passe qui donne accès au gestion­naire de mots de passe lui-même. Il faut aussi rete­nir celui pour ouvrir la session sur le poste de travail person­nel et celui pour le pendant profes­sion­nel. Person­nel­le­ment je retiens aussi celui de ma boite email perso, qui donne virtuel­le­ment accès à tout si je perds les autres clefs.

    J’ai trois possi­bi­li­tés :

    1. Rete­nir 4x 16 carac­tères et symboles aléa­toires.
    2. Utili­ser une suite de symboles qui dérivent d’une phrase qu’on peut rete­nir
    3. Utili­ser une suite de mots plutôt qu’une suite de carac­tères

    Le (2) c’est ce que propose par exemple l’ou­til de la CNIL. Il est un peu agaçant parce qu’il recon­nait assez peu de choses comme des carac­tères spéciaux, mais ça montre bien la démarche.

    Le (3) part de l’idée oppo­sée. On tire au hasard une suite de mots dans une liste. Certains proposent de simple­ment les tirer au dé. Il est possible d’amé­lio­rer la mémo­ri­sa­tion de ces mots en imagi­nant une petite histoire ou petite comp­tine 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émo­risent plus faci­le­ment.

    5. Utili­sez une méthode « sure » pour géné­rer les quelques mots de passe que vous devrez vrai­ment rete­nir vous-même

    Le danger c’est que notre imagi­na­tion est limi­tée par notre envi­ron­ne­ment.

    N’uti­li­sez pas un proverbe ou un refrain pour le (2), même si ça vous semble peu connu (un ordi­na­teur est capable de tester des dizaines de millions de proverbes ou refrains « peu connus », c’est à dire plus que vous n’en connais­sez vous-même et les variantes que vous pouvez en imagi­ner).

    Chaque suite de termes évidents affai­blira votre mot de passe. Tiens, est-ce que vous avez commencé votre phrase par « Je », « Il » ou « Le » ? Vous avez le droit de rajou­ter un mot/symbole parce que le premier ne compte plus.

    Ne choi­sis­sez pas vous-même les mots pour le (3). Le voca­bu­laire passif de quelqu’un de cultivé est limité à quelques milliers de mots. Le voca­bu­laire 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 proba­bi­lité (par exemple tout ce qui est lié à l’in­for­ma­tique, à la sécu­rité ou à ce qui se trouve proche de votre bureau).

    N’uti­li­sez rien qui vous est propre (date, nom, entre­prise, événe­ment, musique préfé­rée, etc.) Ne vous croyez pas plus fin que les autres en cher­chant acti­ve­ment un mot complexe, en opérant des varia­tions ou rempla­ce­ments de lettres. Un robot sera bien plus effi­cace que vous à ces petits jeux. Vrai­ment.

    * * *

    Et voilà. Main­te­nant vous avez des mots de passe sûrs, uniques, stockés en sécu­rité. C’est déjà infi­ni­ment mieux que la moyenne, et ça ne vous a pas coûté grand chose en effort.

    La dernière étape c’est de renou­ve­ler vos anciens mots de passe : ceux qui peuvent être trou­vés par des robots, ceux qui sont les mêmes sur plusieurs services, etc. Certains gestion­naires de mots de passe comme Dash­lane peuvent même le faire pour vous.

    Bonus : Renou­ve­lez vos anciens mots de passe peu sûrs

    Si vous avez envie d’al­ler plus loin on peut parler de ne pas lais­ser déver­rouillé votre gestion­naire de mots de passe, de mettre en place une authen­ti­fi­ca­tion à double facteur, de bien penser à ce que vos postes de travail et votre smart­phone se verrouillent immé­dia­te­ment après une courte période d’inac­ti­vité, qu’ils demandent une authen­ti­fi­ca­tion au réveil, qu’ils aient des disques chif­frés… mais tout ça est pour un second épisode.

  • Dis Mozilla, et si tu écou­tais tes utili­sa­teurs ?

    La première fois que Mozilla a imaginé de mettre des publi­ci­tés dans la page « nouvel onglet ». Quand on réflé­chit à des pistes nouvelles, parfois on s’égare. Pas de problème. La conclu­sion de la commu­nauté était que non, il ne fallait pas de publi­ci­tés dans les nouveaux onglets. Même en opt-out, même en respec­tant le « do not track ». À partir de là on sait.

    La seconde fois, quand Mozilla a parti­cipé à un contexte promo­tion­nel pour une série TV, on a bien voulu parler de faux pas. L’exer­cice était limité, la réponse a toute­fois été sans appel : Non.

    Un verre ça va, trois verres bonjour les dégâts. Après ces deux tenta­tives, remettre le couvert une troi­sième fois avec une idée quasi iden­tique à la première, ça commence à être un problème dont il faut parler, plus des erre­ments.

    Mozilla, je comprends le problème de finan­ce­ment mais si tu n’écoutes pas tes utili­sa­teurs, tout le finan­ce­ment imagi­nable se révé­lera bien vain.