Stockage de mots de passe

Attention : Stocker ses mots de passe dans des fichiers, c'est mal ! Ne le faîte pas, à moins de prendre un maximum de précautions sur la manière dont ils sont saisis, stockés, et extraits pour utilisation, de préférence avec des outils de gestion de mot de passe dédiés et matures. keepassxc est un exemple d'un tel outil ; mais il n'est pas idéal non plus car il doit encore fréquemment composer avec un serveur X, peu connu pour la robustesse de sa sécurité.

Palaiseau, le dimanche 3 mai 2020

Cher Journal,

Je note l'astuce suivante, trouvée dans le manuel de Mutt, puisque c'est très pratique. Pour envoyer du courrier, jusqu'à présent, j'ai plusieurs mots de passe, un pour le serveur IMAP de mon fournisseur de courrier électronique, passé au lancement de fetchmail, un pour son serveur SMTP, passé au moment d'envoyer un courrier, et un pour déchiffrer la clé GPG afin de signer, voir chiffrer, mes messages. Ce qui fait trois mots de passe à taper. En pratique, les mots de passe IMAP et SMTP sont souvent les même, car lié à un seul compte de courrier, et la phrase de passe GPG est, c'est important, différente. De fait, je ne démarre pas fetchmail très souvent, mais nourrir l'agent GPG, et authentifier la connexion au serveur SMTP, c'est pour moi beaucoup plus fréquent; je ne laisse pas tourner mon MUA, je démarre une nouvelle instance quand je reçois un courriel, et l'arrête quand il est traité. C'est probablement très sûr comme configuration, mais c'est aussi très lourd ; il m'arrive fréquemment de me louper dans mon mot de passe SMTP, ce qui me doit des alertes de la part de mon fournisseur.

Mutt propose de stocker les mots de passe IMAP et SMTP dans la configuration, à priori en clair, ce qu'il ne faut pas faire. Toutefois, il est possible d'exécuter des commandes pour remplir les champs de configuration de Mutt, via les apostrophes inversées backtick : « ` ». Du coup, l'astuce, c'est de stocker le mot de passe dans un fichier chiffré avec GPG, et capable uniquement d'être décodé avec ma clé secrète :

$ gpg --encrypt --recipient etienne.mollier@mailoo.org > .motdepasse
C3c1 n'e5t pa5 un m0t 2 passe.$ _

Dans le doute, une fois que j'ai fini de taper le mot de passe, pour ne pas enregistrer le saut de ligne, je force la fin de fichier dans fin de ligne en tapant deux fois Ctrl+D, d'où le prompt qui apparait directement à la fin de la ligne dans la liste précédente. Pour vérifier le contenu, je le déchiffre une fois :

$ gpg --decrypt .motdepasse
gpg: encrypted with 3072-bit RSA key, ID 640C990CE4C02D9B, created 2019-08-21
      "Étienne Mollier <etienne.mollier@mailoo.org>"
C3c1 n'e5t pa5 un m0t 2 passe.$ _

Pas d'erreur, j'ai pu récupérer mon mot de passe, c'est le moment de lancer une commande reset ou de fermer le terminal pour que le mot de passe ne soit plus visible dans l'historique de l'affichage :

$ reset

Maintenant, pour indiquer à Mutt comment récupérer le mot de passe, il suffit de lui indiquer dans le fichier ~/.muttrc l'option suivante :

set smtp_pass = "`gpg --batch -q --decrypt ~/.motdepasse`"

Comme dit, les backticks indiquent qu'au lieu de considérer le texte suivant comme un argument, c'est plutôt une commande qu'il faudra exécuter. Au lancement de Mutt, la fenêtre Pinentry qui sert d'ordinaire à la signature et au chiffrement va s'afficher afin de décoder le mot de passe chiffré dans ~/.motdepasse, dont le contenu sera ensuite utilisé par Mutt pour envoyer au serveur SMTP au moment d'un envoi. Dans la foulée, si la clé est toujours enregistrée dans l'agent au moment d'envoyer un courrier, alors elle ne sera pas redemandée au moment de la signature ou du chiffrement.

Les danger sont évidemment toujours les même, si la clé GPG est compromise, alors en plus des problèmes de confidentialité et d'usurpation d'identité que ça va pauser, ça donnera en plus accès à la boîte de courriel. Il faudra également suivre les vulnérabilités de sécurité à la fois de Mutt et de GPG, mais étant donné que ce sont deux composants déjà très utilisés ensemble, le second étant tout de même un peu critique, on devrait pouvoir compter sur un peu de suivi de la part de la plupart des distributions un peu sérieuses.

[ICO]NameLast modifiedSize
[PARENTDIR]Parent Directory  -

  —