Je relisais la notice de LastPass sur l'incident de 2022, et un chiffre m'a arrêté.
Dans sa notice du 22 décembre 2022, l'entreprise explique qu'une sauvegarde de données de coffres clients a été copiée. Elle précise que ces coffres contiennent « both unencrypted data, such as website URLs » et des champs chiffrés en AES 256 : identifiants, mots de passe, notes sécurisées, données de formulaires. Elle ajoute que le mot de passe maître n'est jamais connu d'elle, qu'un minimum de douze caractères est imposé depuis 2018, et qu'elle applique « 100,100 iterations of the Password-Based Key Derivation Function (PBKDF2) ».
C'est ce dernier nombre qui mérite qu'on s'arrête. La fiche de l'OWASP sur le stockage des mots de passe recommande aujourd'hui Argon2id avec au moins 19 Mio de mémoire, deux itérations et un parallélisme de 1, et réserve PBKDF2 aux contextes qui exigent la conformité FIPS, avec au moins 600 000 itérations en HMAC-SHA-256. Entre 100 100 et 600 000, il y a un facteur six, et ce facteur se paie en temps de calcul chez l'attaquant qui détient déjà le fichier.
La leçon n'est pas que LastPass a mal fait son travail en 2022 : c'était un paramétrage courant à l'époque. Elle est que la robustesse d'un coffre volé ne se joue pas sur le fait qu'il soit chiffré, mais sur une poignée de paramètres de dérivation que l'utilisateur ne voit jamais et ne choisit pas.
D'où mon biais, qui n'est pas idéologique : avec KeePassXC, la fonction de dérivation et ses paramètres sont dans l'interface, modifiables, et le format du fichier est documenté. Avec Vaultwarden, on garde les clients Bitwarden sans confier le coffre à un tiers. Dans les deux cas, on peut lire et régler ce qui, ailleurs, est une décision prise pour vous et héritée de l'année de création du compte.
Deux réserves, pour ne pas vendre du rêve. S'auto-héberger ne supprime pas le risque, ça le déplace : sauvegardes, mises à jour et disponibilité deviennent votre problème, et un coffre perdu est aussi définitif qu'un coffre volé. Et la partie non chiffrée reste non chiffrée quel que soit le logiciel : savoir que vous aviez un compte quelque part n'est pas révocable, contrairement à un mot de passe.
Ma question pour le fil : combien d'entre vous ont réellement regardé les paramètres de dérivation de leur gestionnaire plutôt que de garder les valeurs par défaut, et lesquels utilisez-vous ?
Pour celles et ceux que le versant hachage intéresse, avec les ordres de grandeur de vitesse selon le type d'empreinte, j'avais détaillé ça sur mon site.
# J'ai pas regardé
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3 (+0/-0).
J'ai pas regardé la config de mon KeepassXC.
Pour Vaultwarden il me semble avoir vu des alertes dans l'interface web indiquant que la configuration en place n'était plus conforme aux recommandations actuelles et qu'il fallait faire des modifications (mais c'est sur un truc ou je n'ai pas la main pour faire ce genre de config).
Pour moi la conclusion est: si jamais votre coffre de mots de passe a été volé, même s'il est chiffré, tout ce que ça vous apporte, c'est du temps pour renouveller tous les mots de passe avant que le chiffreemnt du coffre puisse être cassé. Quelques mois ou années si le coffre est bien chiffré avec des bons paramètres, peut-être seulement quelques jours ou quelques heures dans le cas contraire. Mais dans tous les cas, un jour le coffre sera cassé.
# Mauvaise question
Posté par fork_bomb . Évalué à 1 (+0/-0).
Ton LLM pose la mauvaise question : la tendance en cryptographie est plutôt à rendre les outils non paramétrables, avec les choix d'algorithmes et de paramètres faits par des experts. La question devrait donc plutôt être pourquoi c'est paramétrable, et pourquoi les paramètres par défaut ne sont pas les plus sûrs.
# Ca m'intéresse, tu peux détailler svp ?
Posté par Luc-Skywalker . Évalué à 2 (+0/-0).
c'est un peu obscur, j'ai besoin de tes lumières.
Merci
"Si tous les cons volaient, il ferait nuit" F. Dard
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.