• Le mot de passe maître
• Le fichier clé
• Le compte utilisateur Windows
• Pour les administrateurs : spécifications des propriétés minimales des clés principales

Votre fichier de base de données de KeePass est chiffré en utilisant une clé principale. Cette clé principale peut être constituée de plusieurs composants : un mot de passe maître, un fichier clé et/ou une clé qui est protégée en utilisant le compte utilisateur courant de Windows.

Pour ouvrir un fichier de base de données, alors tous les composants de la clé principale sont nécessaires.

Si vous oubliez/perdez un composant de la clé principale (ou oubliez la composition), alors toutes les données enregistrées dans la base de données sont perdues. Il n'y a pas de porte dérobée et ni de clé universelle qui puisse ouvrir votre base de données.

Le mot de passe maître

Si vous utilisez un mot de passe maître, vous n'avez qu'à seulement vous souvenir d'un mot de passe ou d'une phrase de passe (ce qui devrait être bon) pour ouvrir votre base de données.

KeePass propose une fonctionnalité de protection contre les attaques par force brute ou par dictionnaire sur la clé principale, lire la page d'informations sur la sécurité pour plus de détails.

Le fichier clé

Un fichier clé est un fichier qui contient une clé (et éventuellement d'autres données comme par exemple un hachage qui permet de vérifier l'intégrité d'une clé). L'extension du fichier est typiquement 'keyx' ou 'key'.

Un fichier clé ne peut pas être modifié, sinon vous ne pourrez plus du tout ouvrir votre base de données. Si vous souhaitez utiliser un fichier clé différent, alors ouvrez la boîte de dialogue pour changer la clé principale (via 'Fichier' → 'Modifier la clé principale...') et créer/sélectionner le nouveau fichier clé.

La protection à deux facteurs : un fichier clé est quelque chose que vous devez posséder afin d'être capable d'ouvrir la base de données (contrairement à un mot de passe maître, que vous devez connaître). Si vous utilisez à la fois un fichier clé et un mot de passe maître, alors vous avez une protection à deux facteurs : possession et connaissance.

Emplacement : comme mentionné ci-dessus, l'idée c'est que vous possédez quelque chose, si un attaquant s'accapare à la fois de votre base de données et de votre fichier clé, alors le fichier clé n'offre plus de protection. Donc, les deux fichiers doivent être stockés à deux endroits différents. Par exemple, vous pourriez enregistrer le fichier clé sur une clé USB à part.

En cachant la localisation : le contenu du fichier clé doit être tenu secret, pas sa localisation (chemin/nom du fichier). En essayant de cacher le fichier clé (par exemple : en le sauvegardant parmi des milliers d'autres fichiers, dans l'espoir qu'un attaquant ne saura pas quel fichier est celui qui est bon) n'augmentera pas typiquement la sécurité, parce qu'il est facile de trouver le bon fichier (par exemple : en inspectant le dernier temps d'accès des fichiers, les listes des fichiers récemment utilisés du système d'exploitation, l'audit des logs du système de fichiers, les logs du logiciel antivirus, etc.). KeePass possède une option pour se souvenir des chemins des fichiers clés, qui est activée par défaut ; le désactiver diminue seulement l'utilisation sans augmenter la sécurité.

Sauvegarde : vous devriez créer une sauvegarde de votre fichier clé (sur un équipement de stockage de données indépendant). Si votre fichier clé est un fichier XML (ce qui est le cas par défaut), alors vous pouvez également créer une sauvegarde au papier (KeePass 2.x fournit une commande pour imprimer une sauvegarde d'un fichier clé dans le menu 'Fichier' → 'Imprimer'). Dans tous les cas, la sauvegarde devrait être stockée à un endroit sécurisé, où seulement vous et éventuellement d'autres personnes en qui vous aurez confiance auront accès. Plus de détails à propos de la sauvegarde d'un fichier clé peuvent être trouvés dans la FAQ ABP.

KeePass prend en charge les formats de fichier clé suivants :

• XML (recommandé, par défaut) : il existe un format XML pour les fichiers clés. KeePass 2.x utilise ce format par défaut, c'est-à-dire que lorsqu'on crée un fichier clé dans la boîte de dialogue de la clé principale, un fichier clé XML est créé. La syntaxe et la sémantique du format XML permettent de détecter certaines corruptions (notamment celles causées par des erreurs matérielles ou des problèmes de transfert), et un hachage (en fichier clé XML version 2.0 ou supérieure) permet de vérifier l'intégrité de la clé. Ce format résiste à la plupart des changements d'encodages et de caractère nouvelle ligne (ce qui est utile par exemple quand l'utilisateur ouvre et enregistre le fichier clé ou quand on le transfert depuis/vers un serveur). Un tel fichier clé peut être imprimé (en guise de sauvegarde sur papier), et des commentaires peuvent être ajoutés au fichier (avec la syntaxe XML usuelle : <!-- ... -->). C'est le format le plus flexible ; de nouvelles fonctionnalités pourront être facilement ajoutées dans le futur.
• 32 octets : Si le fichier clé contient exactement 32 octets, alors ceux-ci sont utilisés comme une clé cryptographique de 256 bits. Ce format nécessite le moins d'espace disque.
• Hexadécimal : si le fichier clé contient exactement 64 caractères hexadécimaux (0-9 et A-F, en encodage ASCII/UTF-8, une ligne, aucun espace), ceux-ci sont décodés vers une clé cryptographique de 256 bits.
• Haché : si un fichier clé ne correspond pas à un des formats ci-dessus, alors son contenu est haché en utilisant une fonction de hachage cryptographique afin de fabriquer une clé (typiquement une clé de 256 bits avec SHA-256). Ceci permet d'utiliser des fichiers arbitraires en guise de fichier clé.

Réutilisation : Vous pouvez utiliser un fichier clé pour plusieurs bases de données. Ceci peut être intéressant, mais gardez à l'esprit que lorsqu'un attaquant obtient votre fichier clé, vous devez modifier les clés principales de tous les fichiers de base de données protégés avec ce fichier clé.

Afin de réutiliser un fichier clé existant, cliquez sur le bouton 'Parcourir...' dans la boîte de dialogue de création de la clé principale.

Le compte utilisateur Windows

KeePass peut rendre la base de données dépendante du compte courant de l'utilisateur Windows. Si vous activez cette option, alors vous pouvez seulement ouvrir la base de données que quand vous êtes connectés en tant que même utilisateur Windows qui a créé la base de données.

Faites très attention en utilisant cette option. Si votre compte utilisateur Windows venait à être supprimé, alors vous ne pourriez plus du tout ouvrir votre base de données KeePass. De plus, quand vous utilisez cette option chez vous et que votre ordinateur tombe en panne (par exemple : un disque dur endommagé), alors il ne suffit pas de créer simplement un nouveau compte Windows sur la nouvelle installation avec le même nom et mot de passe ; vous devez copier le compte complet (c'est-à-dire SID, etc.). Ce n'est pas une tâche simple, par conséquent si vous ne savez pas faire ceci, alors il est fortement recommandé que vous n'activiez pas cette option. Des instructions détaillées sur, " Comment retrouver un compte utilisateur Windows ? ", peuvent être trouvées ici : 'Recover Windows User Account Credentials' (un court tutoriel technique peut être trouvé dans un article TechNet de Microsoft : 'How to recover a Vault corrupted by lost DPAPI keys)'.

Vous pouvez modifier le mot de passe du compte de l'utilisateur Windows à volonté ; cela n'affecte pas la base de données de KeePass. Remarquer qu'en changeant le mot de passe (par exemple : un utilisateur en utilisant le panneau de configuration ou en appuyant sur Ctrl+Alt+Sup et en sélectionnant 'Modifier le mot de passe') et en le réinitialisant à un nouveau (par exemple : un administrateur utilisant la commande NET USER <Utilisateur> <NouveauMotDePasse>) sont deux choses différentes. Après avoir changé votre mot de passe, vous pouvez toujours ouvrir votre base de données KeePass. Quand on réinitialise le mot de passe à un nouveau, habituellement l'accès n'est plus possible (parce que les clés DPAPI de l'utilisateur sont perdues), mais il existe des exceptions (par exemple : quand l'utilisateur est dans un domaine, Windows peut retrouver les clés DPAPI de l'utilisateur depuis le contrôleur de domaine, ou un utilisateur chez soi peut utiliser un disque de réinitialisation de mot de passe précédemment créé). Des détails peuvent être trouvés dans l'article MSDN 'Windows Data Protection' et dans l'article de support 'How to troubleshoot the Data Protection API (DPAPI)'.


Si vous décidez d'utiliser cette option, alors il est fortement recommandé de ne pas compter exclusivement dessus, mais d'utiliser en plus l'une des autres deux options (mot de passe et fichier clé).

Au lieu de sauvegarder le compte utilisateur Windows, vous pouvez alternativement créer une sauvegarde non chiffrée de la clé en utilisant 'l'utilitaire de sauvegarde et de restauration du compte utilisateur Windows'. Une telle sauvegarde n’est pas chiffrée, elle doit être stockée dans un emplacement sécurisé.

Chaque fois que l'utilisateur tente d'ouvrir la base de données, KeePass déprotège la clé (à l'aide de DPAPI) et utilise le résultat dans le cadre de la clé principale.

La protection en utilisant des comptes utilisateur n'est pas prise en charge sous Windows 98/ME.

Pour les administrateurs : spécifications des propriétés minimales des clés principales

Des administrateurs peuvent spécifier une longueur minimale et/ou la qualité estimée minimale qu'un mot de passe maître doit avoir afin d'être accepté. Vous pouvez signaler à KeePass de vérifier ces deux exigences minimales en ajoutant/éditant les définitions appropriées dans le fichier de configuration INI/XML.

La valeur du nœud Security/MasterPassword/MinimumLength spécifie la longueur minimale du mot de passe maître (en caractères). Par exemple : en le positionnant à 10, alors KeePass n'acceptera que les mots de passe maîtres qui comprennent au moins 10 caractères.

La valeur du nœud Security/MasterPassword/MinimumQuality spécifie la qualité minimale estimée (en bits) que les mots de passe maîtres doivent avoir. Par exemple : en le positionnant à 80, alors seuls les mots de passe avec une qualité estimée d'au moins 80 bits seront acceptés.

Les nœuds Security/MasterKeyExpiryRec et Security/MasterKeyExpiryForce peuvent être positionnés à une date XSD ou une durée XSD (cf. XSD Date and Time Data Types). Si la clé principale n'a pas été modifiée depuis la date spécifiée ou que le temps qui s'échelonne entre maintenant et la dernière modification de la clé principale dépasse la durée spécifiée, alors KeePass recommande/force de/à la modifier. Ces paramètres s'appliquent à toutes les bases de données qui sont ouvertes avec cette instance de KeePass ; une expiration de clé principale peut également être configurée pour chaque base de données individuellement (dans 'Fichier' → 'Paramètres de la base de données' → onglet 'Avancé').

En spécifiant KeyCreationFlags et/ou KeyPromptFlags (dans le nœud UI), vous pouvez forcer les états (activé, désactivé, vérifié, non vérifié) des contrôles de source de clé dans les boîtes de dialogue de création de la clé principale et d'invite. Ces valeurs peuvent être des combinaisons au niveau du bit d'un ou plusieurs des flags suivants :

Les valeurs de KeyCreationFlags et KeyPromptFlags doivent être spécifiées en notation décimale.

Par exemple : si vous forcez l'utilisation de l'option du compte utilisateur, alors vous pourriez vérifier et désactiver le contrôle (de telle sorte que l'utilisateur ne pourrait plus ne pas le vérifier) en spécifiant 263168 comme valeur (0x40000 + 0x400 = 0x40400 = 263168).