Est-il raisonnable d'utiliser KeePassXC avec YubiKey?
En ce moment, j'utilise KeePassXC avec un mot de passe principal relativement fort. Pour améliorer encore la sécurité, j'ai pensé à acheter une YubiKey pour avoir une authentification à 2 facteurs.
KeePassXC prend en charge ce qu'on appelle le "mode de réponse au défi HMAC-SHA1".
Dans le KeePassXC FAQ ils disent:
KeePassXC prend-il en charge l'authentification à deux facteurs (2FA) avec YubiKeys?
Oui et non. KeePassXC prend en charge YubiKeys pour sécuriser une base de données, mais à proprement parler, ce n'est pas une authentification à deux facteurs. KeePassXC génère un défi et utilise la réponse de YubiKey à ce défi pour améliorer la clé de chiffrement de votre base de données. Donc, dans un sens, cela renforce votre mot de passe, mais techniquement, il ne constitue pas un deuxième facteur distinct, car la réponse attendue ne change pas chaque fois que vous essayez de décrypter votre base de données. Il change cependant à chaque fois que vous enregistrez votre base de données.
En supposant qu'un attaquant a accès à ma base de données KeePassXC et a peut-être même installé un enregistreur de frappe sur mon système, la YubiKey supplémentaire est inutile dans ce cas, suis-je ici?
Alors, est-il raisonnable d'utiliser une clé de sécurité matérielle pour KeePassXC si vous utilisez déjà un mot de passe maître fort?
Les gestionnaires de mots de passe bien conçus ne dépendent pas de l'authentification pour leur sécurité; ils s'appuient plutôt sur le chiffrement. Ainsi, le déverrouillage d'une base de données du gestionnaire de mots de passe n'implique même pas l'authentification à un seul facteur, encore moins l'authentification à plusieurs facteurs.
Comment un gestionnaire de mots de passe peut utiliser un Yubikey
Cela signifie que le type de chose qui est normalement utilisé pour renforcer un processus d'authentification (et les YubiKeys sont très bons dans ce domaine) joue un rôle intrinsèquement différent en ce qui concerne quelque chose dont la sécurité est largement basée sur local ou de bout en bout. chiffrement. Il existe à peu près trois approches, mais les détails de chaque question.
1. Théâtre de sécurité
Dans certains cas, le deuxième facteur apparent est le théâtre purement sécuritaire. Il est possible de faire quelque chose qui ressemble à 2FA à l'utilisateur mais qui peut être évité par n'importe quel attaquant qui devrait s'inquiéter. Nous (chez 1Password, où je travaille) avons résisté à la pression intense des clients pendant des années.
Ignorons simplement cette option. Cela ne fait de bien à personne et a un potentiel de préjudice substantiel si les utilisateurs finissent par utiliser des mots de passe principaux plus faibles ou ne protègent pas leur mot de passe principal comme ils le feraient autrement. Autrement dit, si les gens affaiblissent ce qui est déjà le point faible de la sécurité de leur gestionnaire de mots de passe, parce qu'ils se sentent protégés par 2FA théâtral, ils affaiblissent beaucoup leur sécurité effective.
2. Sur certains composants d'authentification
Bien que de nombreux gestionnaires de mots de passe puissent être utilisés hors ligne, sans nécessiter d'authentification auprès d'un service distant, un composant d'authentification est généralement requis lors de la configuration d'un nouveau périphérique pour que la synchronisation des données fonctionne (au moins). 2FA peut être ajouté à ce composant d'authentification, même s'il s'agit d'un élément mineur de la sécurité de l'utilisateur.
C'est d'ailleurs ce que nous faisons avec 1Password. Si vous activez 2FA, cela est nécessaire lors de la configuration d'un nouvel appareil. L'espoir est qu'en le limitant à cela, nous ne faisons pas croire aux utilisateurs qu'ils peuvent s'en tirer avec des mots de passe principaux plus faibles ou que la 2FA les protège comme par magie d'un attaquant qui accède à leurs données cryptées localement.
3. En tant que fournisseur d'une clé statique
Le déchiffrement des données nécessite une clé, et la dérivation de cette clé nécessite des secrets détenus par l'utilisateur (généralement leur mot de passe principal et peut-être d'autres choses). La difficulté ici est que la fonction de dérivation de clé (KDF) doit être déterministe (car elle doit dériver la même clé à chaque fois).
Mais la beauté de quelque chose comme un Yubikey est qu'il peut prouver la connaissance d'un secret sans le révéler. Ils sont conçus pour fonctionner de manière défi-réponse, où chaque défi est aléatoire, ce qui rend les réponses uniques à chaque fois; pourtant, chaque réponse correcte prouve la connaissance d'un secret. C'est ce qui rend ces choses vraiment bonnes dans les contextes d'authentification. Mais cela est inutile lors de la dérivation des clés.
Donc, faire en sorte que le Yubikey crache un secret statique fait fonctionner l'appareil dans un mode qui abandonne ses fonctions de sécurité les plus importantes. C'est faisable (comme Keepass l'utilise apparemment et certains de nos utilisateurs ont truqué quelque chose de similaire), mais il n'offre vraiment pas les garanties de sécurité qu'un Yubikey fait normalement.
Bien qu'il ne s'agisse pas uniquement d'un théâtre de sécurité (il y a un réel gain), il est toujours possible que les utilisateurs surestiment le gain de sécurité et affaiblissent ainsi les parties de leur sécurité (mot de passe principal) qui devraient être plus solides.
Est-ce raisonnable?
Revenons donc à la question initiale. Il est raisonnable d'utiliser un Yubikey comme décrit dans (3)? L'utiliser n'est pas déraisonnable tant que vous comprenez ce qu'il fait et ne vous protège pas (et que ceux-ci sont distincts de ce contre quoi un Yubikey vous protège généralement.)
Cependant, chez 1Password, nous pensons qu'il n'est pas judicieux pour un gestionnaire de mots de passe d'encourager (3), car les avantages pour la sécurité ne semblent pas valoir les menaces pour la sécurité qui découlent de la mauvaise compréhension des propriétés de sécurité par les gens. Cependant, je très bien comprends la pression des clients pour ce genre de chose. Je comprends également que des personnes raisonnables peuvent arriver à des conclusions différentes.
Le Yubikey dans ce cas n'est pas MFA car le mode challenge-response ne nécessite pas l'utilisation d'un mot de passe en plus de la sortie CR. C'est pourquoi un yubikey tape souvent du charabia dans des champs de texte avec un utilisateur qui heurte accidentellement le côté de son jeton. Fonctionnant dans ce mode, le Yubikey n'est rien de plus qu'un clavier automatisé pour la sortie de votre mot de passe.
Maintenant, ce qui est intéressant, c'est que le système de base de données KeePassXC ne met pas à jour son défi vers Yubikey, sauf lorsque la base de données est enregistrée. Donc, si votre base de données n'est lue que de temps en temps sans aucun changement, le défi attendu ne change pas. Cela signifie que le Yubikey retournera la même valeur de réponse car le système d'authentification ne demande pas de nouvelle réponse. Dans ma compréhension limitée de l'application, il s'agit d'une limitation que KeePassXC pourrait changer, mais pas pour une raison quelconque.
Informations Yubico sur le mode Challenge-Response:
https://www.yubico.com/products/services-software/personalization-tools/challenge-response/
Cela signifie que ... si vous vous engagez à enregistrer votre base de données KeePassXC à chaque exécution, vous pouvez toujours faire confiance à l'utilisation du Yubikey même avec un enregistreur de frappe. La base de données attend une nouvelle réponse chaque fois qu'elle est déchiffrée dans ce scénario et la réponse précédente ne fonctionnera pas. Cependant, cela nécessitera une grande diligence de votre part en tant qu'utilisateur et peut ne pas être souhaitable sur une longue période de temps.
En supposant qu'un attaquant a accès à ma base de données KeePassXC et qu'il a peut-être même installé un enregistreur de frappe sur mon système, la YubiKey supplémentaire est inutile dans ce cas, suis-je ici?
Oui, mais peut-être pas pour la raison pour laquelle vous pensez. Si un attaquant a un malware sur votre système, vous devez supposer que vos mots de passe sont compromis dès que vous déverrouillez la base de données, quel que soit le nombre de facteurs qui l'exigent. De nos jours, la plupart des "enregistreurs de frappe" font bien plus qu'un simple enregistrement de frappe.
Même si tout ce que le malware fait est de journaliser les frappes (et en supposant que la journalisation inclut l'entrée yubikey), tout attaquant a besoin de la base de données KeePass, de votre mot de passe et de la réponse HMAC-SHA1 correspondant à cette instance de base de données. Même si KeePassXC décidait de réécrire la base de données avec un nouveau défi à chaque fois qu'elle était déverrouillée, cela ne changerait vraiment rien dans ce cas, l'attaquant peut toujours obtenir les 3.
Oui, c'est raisonnable (sous certaines hypothèses supplémentaires).
Bien que très peu puisse être fait contre les logiciels malveillants locaux (comme expliqué ci-dessus), il existe également d'autres vecteurs d'attaque à connaître.
Faites attention à vos fuites de mot de passe de déverrouillage vers les caméras autour de vous partout où vous utilisez votre ordinateur portable.
Avec la clé matérielle physique, il existe une couche de sécurité supplémentaire. Étant donné que l'ordinateur portable et la clé matérielle voyagent généralement et sont saisis ensemble, cela n'a de sens que si la clé matérielle elle-même est protégée (ne peut être branchée et utilisée par personne).