Comment un fichier de clé augmente-t-il la sécurité d'un gestionnaire de mots de passe?
Les gestionnaires de mots de passe comme KeePass ont souvent la possibilité d'utiliser un fichier clé en plus d'un mot de passe principal.
Je ne comprends pas comment cela augmente la sécurité.
(Remarque: KeePass permet également d'utiliser un fichier de clé à la place d'un mot de passe principal, mais dans cette question, je demande spécifiquement à propos de l'utilisation d'un en plus à un mot de passe maître.)
Étant donné que la base de données de mots de passe ne peut pas être déchiffrée sans le fichier de clés, le fichier de clés doit être stocké quelque part - un peu comme la base de données de mots de passe elle-même. Pourquoi le fichier clé est-il plus difficile à obtenir pour un adversaire que la base de données de mots de passe elle-même?
Les méthodes d'authentification peuvent souvent être divisées en trois domaines: quelque chose que l'utilisateur sait, quelque chose que l'utilisateur possède et quelque chose que l'utilisateur est.
Les mots de passe sont quelque chose que l'utilisateur sait. L'utilisateur le mémorise dans sa tête et peut le "récupérer" de la mémoire au fur et à mesure des besoins.
Le fichier clé agit comme quelque chose que possède l'utilisateur. Idéalement, ce fichier clé doit être stocké dans un emplacement sécurisé.
Personnellement, j'ai des copies de ma base de données de mots de passe partout. Mon bureau en a une copie, mon ordinateur portable en a une copie, mon téléphone en a une copie, ma tablette en a une copie. Je stocke ma base de données de mots de passe sur Dropbox, ce qui me permet de la synchroniser entre mes différents appareils.
Cependant, je ne stocke pas mon fichier de clés ensemble avec ma base de données de mots de passe. Mon téléphone et ma tablette en ont une copie, car je ne peux pas insérer de clé USB dans ces appareils, mais pas mon ordinateur de bureau ni mon ordinateur portable. Je stocke mon fichier de clés sur une clé USB que je garde en permanence sur moi. Cela rend un peu plus difficile pour un attaquant d'obtenir mon fichier de clés.
L'utilisation d'un fichier de clé en plus vers un mot de passe principal est utile, car elle soulève la difficulté de compromettre avec succès votre base de données de mots de passe.
Le fichier de clés contient la clé utilisée pour crypter la base de données. Il est également souvent protégé par un mot de passe. Si vous n'avez pas le fichier de clé, il est impossible de dériver la clé du texte chiffré pour obtenir l'équivalent en texte brut. Donc, si un attaquant obtenait votre base de données, il aurait toujours besoin d'obtenir votre fichier de clés, quelque chose que vous avez . Si le fichier de clés est également chiffré avec un mot de passe (comme vous devriez), il a également besoin de quelque chose que vous connaissez . C'est donc deux facteurs d'authentification.
Si vous stockez le fichier de clés le long de la base de données, un attaquant aurait "juste" besoin d'attaquer brutalement ou par dictionnaire le fichier de clés (qui est beaucoup plus petit et prend beaucoup moins de temps que d'attaquer la base de données entière). Cependant, si vous avez un mot de passe complexe, cela devrait prendre presque toujours (en fonction de l'aléa/entropie de votre mot de passe).
Mais ajouter un autre facteur ajoute une sécurité supplémentaire car un attaquant devra toujours obtenir deux choses de vous, plutôt qu'une seule.
C'est un peu comme stocker vos clés sur un trousseau. Mais vous ne stockerez pas votre clé à côté de votre porte verrouillée, non? Eh bien, c'est similaire.
En plus d'agir comme "quelque chose que vous avez", l'option d'utiliser un fichier clé permet plus de flexibilité dans les deux autres facteurs ( "quelque chose que vous savez" et "quelque chose que vous êtes") sans avoir à implémenter explicitement un tel comportement dans l'application.
Exemple 1: "Quelque chose que vous savez" pourrait être exécuté via une commande personnalisée ou plus fort fonction de dérivation de clé que KeePass (en particulier compatible v1.x) peut prendre en charge; puis chargé en tant que fichier clé.
Exemple 2: "Quelque chose que vous êtes" pourrait être exécuté à travers un scanner biométrique qui écrit une bio-signature qui est ensuite exécuté via une fonction Trapdoor et/ou une fonction de dérivation de clé à charger dans KeePass qui n'a pas de connaissance native de la biométrie, en particulier sur les systèmes d'exploitation sans norme biométrique équivalente "TWAIN".
Exemple 3: "Quelque chose que vous êtes" dans le sens plus générique de prouver que vous êtes un être humain * en régénérant le fichier clé (ou une étape de celui-ci) à partir d'une saisie humaine dans une image CAPTCHA (ou n ou n autre successeurs possibles) stockés publiquement avec le magasin de clés.
Fondamentalement, l'option keyfile peut agir comme un fourre-tout générique pour n'importe quelle source d'entropie que vous pouvez imaginer - dans la limite du schéma de chiffrement du magasin de clés sous-jacent ( 256 bits pour KeePass).
* Ou HAL 9000.
Il existe un deuxième avantage d'un fichier de clé, distinct de la simulation de l'authentification à deux facteurs (2FA). Bien que votre révision de votre question suggère que la réponse à deux facteurs correspond à ce que vous recherchez dans votre réponse.
Une autre raison pour ne pas faire dériver la clé de chiffrement directement à partir du mot de passe principal est de permettre la création de la clé au hasard au lieu d'être directement dérivée du mot de passe principal. Si nous créons la clé avec un CSPRNG et que nous chiffrons ensuite cette clé avec une clé de chiffrement (KEK), nous pouvons nous assurer que la clé principale a la pleine force de sa taille en bits. C'est une clé de 128 bits qui sera vraiment forte de 128 bits, même si une personne choisit un mauvais mot de passe principal.
Bien que ce ne soit pas obligatoire pour les clés symétriques (telles qu'utilisées dans les gestionnaires de mots de passe), c'est absolument vital lorsque l'on regarde les systèmes de clés publiques. Dans ces cas, la clé privée ne peut pas être n'importe quoi et ne peut donc pas vraiment être fonction d'un mot de passe et d'un peu de sel. C'est pourquoi, pour des choses comme PGP ou SSH, les clés sont générées par le logiciel et sont ensuite chiffrées avec une KEK dérivée du mot de passe.
Bien sûr, la dérivation de la KEK à partir du mot de passe principal doit encore être "étirée" avec une fonction de dérivation de clé telle que PBKDF2 ou scrypt.
Deux facteurs, mais pas l'authentification
Remarque: La raison pour laquelle j'ai dit "simuler authentification à deux facteurs" est qu'il n'y a en fait aucune authentification dans ces cas. Au lieu de cela, il y a le décryptage. À de nombreuses fins, la distinction n'a pas d'importance, mais il existe des cas cruciaux où la distinction entre un mot de passe d'authentification (ou jeton) et un jeton de chiffrement est énorme.
Dans le cas de quelque chose comme KeePass, qui ne sont pas basés sur l'authentification (vous ne prouvez pas qui vous êtes à un service qui vous communique ensuite des informations en cas de succès), vous devez obtenir votre fichier de clé sur chaque ordinateur ou appareil que vous devez utiliser. vos données. Donc, le mettre sur une clé USB peut ne pas fonctionner si vous souhaitez également décrypter vos données sur un téléphone. Il peut très bien y avoir des moyens de le faire avec KeePass, mais étant donné ma compréhension (peut-être erronée) de l'architecture, cela présenterait certaines difficultés qui devraient être surmontées.
Les réponses ici sont très bonnes mais je pense que quelque chose devrait être noté ici de manière plus explicite:
Le fichier clé dans la base de données KeePass n'est pas comme les autres méthodes à deux facteurs utilisées dans les comptes en ligne. le fichier Key ici (et aussi le plugin OTPKeyProv si quelqu'un l'utilise à la place de) sont comme votre mot de passe.
Je veux dire que si quelqu'un veut forcer brutalement votre base de données KeePass, il n'a pas besoin d'avoir votre fichier de clé ou votre code OTP parce que KeePass a utilisé ces éléments comme votre mot de passe pour crypter la base de données. donc il n'y en a pas beaucoup quelque chose que vous avez comme les comptes en ligne ici en termes de sécurité.
Le seul avantage de ces méthodes est que votre base de données aura une meilleure KEK en termes de qualité/sécurité utilisée pour le chiffrer et si votre mot de passe est de faible qualité, cela n'affectera pas beaucoup la sécurité de la base de données par rapport à l'utilisation du mot de passe lui-même .