Salut à tous, vous vous rappelez fin avril que j’avais sorti un article dans MISC sur KeePass et Yubikey ? Comme pour ma précédente publication chez eux, j’ai repris une licence de « type B », c’est à dire : une cession de droits temporaire, suivi d’une publication sous licence « Creative Commons BY-NC-ND » (détails).
Ce qui me permet de vous partager cet article sur KeePass et YubiKey sur le blog désormais. J’espère que ça vous intéressera, pour ceux qui ne l’ont pas déjà lu, et que ça permettra aux autres d’y accéder facilement. Je rappel aussi que ce papier est aussi la version « complète » du billet KeePass2 et la synchronisation SSH/SFTP entre Windows, Linux et Android sur le site (article qui génère une proportion non-négligeable de vues sur le site d’ailleurs).
Enfin si vous n’êtes pas déjà abonné à MISC, je ne peux vous conseiller de le faire ! (même si je ne touche rien sur les ventes, 😉 ) !
Sur ce, bonne lecture à tous et @+
KeePass multiplateforme en authentification forte avec une YubiKey
MISC n° 103| mai/juin 2019 | Étienne LADENT
De nos jours, l’authentification forte devient la norme (paiements en ligne, Google authenticator, etc.) et les gestionnaires de mots de passe se démocratisent, le plus souvent dans des solutions cloud. Voyons comment aller plus loin en combinant une solution matérielle comme la YubiKey, et un logiciel open source, comme KeePass, pour gérer nos mots de passe « on-premise » en authentification double facteurs.
La bonne application des règles de sécurité concernant les mots de passe [1] est complexe. En effet, la multiplication des systèmes, sites internet et de leurs comptes associés rend parfois laborieuse l’application des bonnes pratiques sur ces mots de passe. L’actualité nous rappelle pourtant régulièrement leur nécessité [2]. Les particuliers comme les entreprises sont demandeurs d’outils les aidant dans cette démarche. Un gestionnaire de mot de passe permet à son utilisateur de créer, modifier, sauvegarder, accéder et supprimer ses mots de passe : c’est-à-dire de gérer le cycle de vie. Et cela, au sein d’une base de données chiffrée et protégée généralement par un unique mot de passe maître. Les principaux avantages d’un gestionnaire de mots de passe sont les suivants :
- L’utilisateur ne doit plus se souvenir que d’un seul mot de passe.
- L’utilisateur peut choisir, ou générer automatiquement, des mots de passe très complexes et donc plus robustes, sans avoir à s’en souvenir pour autant.
- La possibilité d’utiliser des mots de passe différents par compte, site, système. De sorte que la compromission d’un couple nom d’utilisateur, mot de passe ne fournira pas d’accès supplémentaire à un attaquant.
La principale contrepartie est que le logiciel, le mot de passe maître et la base stockant les mots de passe deviennent des éléments critiques pour la sécurité du système d’information.
1 Tour d’horizon des gestionnaires de mots de passe
Il existe aujourd’hui un grand nombre de gestionnaires de mots de passe : gratuits ou non, open source ou propriétaires, s’intégrant dans les navigateurs, cloud ou locaux, etc. Ils proposent diverses fonctionnalités adaptées selon les cas aux particuliers, aux familles ou aux entreprises…
Les produits sur ce marché sont désormais nombreux : 1Password, Bitwarden, Dashlane, KeePass, LastPass ou encore Pleasant Password Server sont quelques-uns des plus connus.
1.1 KeePass
KeePass est donc un gestionnaire de mots de passe sous licence GNU GPL utilisé par une communauté assez nombreuse depuis 2003. Il protège vos mots de passe en les stockant dans un fichier chiffré. Pour accéder à cette base de mots de passe, vous devez fournir le mot de passe maître, potentiellement séparé en plusieurs éléments : la composite master key.
KeePass est le seul gestionnaire, à l’heure actuelle, qui dispose d’une certification de premier niveau (CSPN) délivrée par l’ANSSI [3] (dans sa version 2.10 portable). Dans cet article, nous utiliserons la version 2.41.
1.2 Recommandation de mise en œuvre
Le RSSI cherchant à mettre en œuvre KeePass dans son entreprise aura idéalement fait réaliser une étude des options à configurer par rapport à l’état de l’art. Au minimum dans un contexte d’entreprise, le mot de passe maître devrait se voir imposer une complexité élevée. Et dans cette optique, le fichier de configuration de KeePass (config.xml qui implémente ces règles) ne devrait être modifiable que par les administrateurs de l’entreprise.
Le lecteur notera qu’en cas d’oubli du mot de passe maître par l’utilisateur, ou qu’en cas de corruption du fichier de base (.kdbx), il n’est pas possible de récupérer le contenu de la base. Il est donc impératif de stocker ce fichier dans un espace bénéficiant de sauvegardes régulières.
1.3 Vulnérabilités connues de KeePass
Malgré sa certification de sécurité, KeePass n’est pas invulnérable. Les attaques de type force brute sur le fichier de base de mots de passe existent, même s’il est possible de les atténuer en augmentant le nombre d’itérations lors de la dérivation du mot de passe. Il reste néanmoins indispensable que le mot de passe maître soit robuste. De plus, les attaques sur la mémoire existent également, il est donc souhaitable de ne charger votre base que sur des terminaux maîtrisés. Ceux qui souhaitent en savoir plus sur ces attaques de KeePass et leurs contre-mesures, peuvent aller lire l’excellente série A Case Study in Attacking KeePass [4] [5] par Will « harmj0y ».
1.4 Plugins
L’un des intérêts de KeePass est la modularité qu’apportent les plugins communautaires, que vous trouverez sur le site officiel [6]. Néanmoins :
« Les plugins ne sont pas forcément développés par l’équipe de développement et peuvent donc contenir du code hostile. Il est donc conseillé d’utiliser de manière précautionneuse ces plugins. »
Cible de Sécurité CSPN KEEPASS v2.10 portable [7]
Si KeePass bénéficie de la certification CSPN, ce n’est pas le cas de ses plugins. Dans la suite de cet article, nous allons utiliser deux plugins qui n’ont pas bénéficié de cette certification. Le choix de faire confiance ou non aux développeurs de ces plugins, et aux contrôles de la communauté, est à évaluer dans une analyse de risque en fonction de chaque contexte, potentiellement après un audit de leur code source.
2 KeePass sur un serveur
L’intérêt et l’inconvénient de KeePass par rapport à des solutions Cloud est que vous devez gérer vous-même le fichier de base : accessibilité, sauvegarde, restauration, synchronisation ne sont pas gérées par un tiers. En cas de perte de votre base, il n’y aura aucun moyen de la récupérer. Une réponse à ce problème est de déporter le fichier de base sur un serveur et d’y accéder à distance. Cela permet à la fois de simplifier les questions de sauvegarde et d’accéder à la même base depuis plusieurs appareils.
Dans cet article, nous allons utiliser une synchronisation en SFTP grâce au plugin IOProtocolExt. Les plugins s’installent en copiant les fichiers associés (.plgx) dans le sous-dossier plugins du répertoire d’installation de KeePass (par défaut sous Windows : C:\Program Files (x86)\KeePass PasswordSafe 2\Plugins). Il faut redémarrer le logiciel pour qu’ils soient chargés.
Nous allons voir ci-dessous comment mettre en place la synchronisation de notre base sur un serveur distant accessible en SSH. Nous admettrons ici que vous avez déjà créé une base et l’avez transférée sur ce serveur (un serveur dédié chez un hébergeur, par votre entreprise ou un Raspberry Pi derrière une Box ADSL par exemple).
2.1 Accès sous Windows
Une fois KeePass et le plugin IOProtocolExt installés, il suffit de cliquer sur Fichier > Synchroniser > Synchroniser avec une URL avec la syntaxe suivante et en renseignant les champs d’authentification :
sftp://server.fq.dn/Path/To/keepasskxdbDir/keepass.kdbx
Et KeePass utilisera, et synchronisera, ce fichier distant plutôt qu’une base locale.
2.2 Accès sous Linux Ubuntu 18.04
Pour Linux, les distributions fournissent en général un paquet keepass2 dans les dépôts officiels, qui n’est le plus souvent pas à jour. Une alternative simple est le ppa de Julian Taylor [8] qui fournit les dernières versions du logiciel pour mono. Il s’ajoute sans trop de difficulté :
$ sudo add-apt-repository ppa:jtaylor/keepass $ sudo apt-get update $ sudo apt-get install keepass2
Paradoxalement, nous pourrions nous attendre à ce que la synchronisation SSH sous Linux se fasse simplement. Mais l’utilisation sous Linux de la version Windows de KeePass, à travers mono, empêche l’utilisation du plugin IOProtocolExt qui n’est pas compatible avec Linux. Mais il est assez simple de contourner le problème, par exemple, à l’aide d’un SSHFS pour monter la base distante.
$ mkdir /mnt/keepass $ sshfs user@sserver.fq.dn:/Path/To/keepasskxdbDir /mnt/keepass
Exécuter alors KeePass et charger sur le fichier /mnt/keepass/keepass.kdbx.
2.3 Accès sous Android
Pour Android, l’application KeePass2Android [9] supporte nativement le protocole SSH. Il faut sélectionner l’accès SFTP dans l’application et renseigner ainsi les informations sur l’emplacement de votre base :
IP : server.fq.dn Chemin : /Full/Path/To/keepasskxdbDir/keepass.kdbx
Vous aurez alors accès à votre base de mot de passe depuis votre téléphone.
2.4 Accès simultanés
Le format de fichier KDBX supporte les accès parallèles. Le mécanisme de synchronisation se fait par entrée, tant que vous ne modifiez pas la même entrée simultanément depuis 2 appareils il n’y a pas de problèmes. Le mécanisme en cas de conflit est bien décrit dans la documentation [10] et utilise l’onglet history dans l’interface de KeePass.
3 Authentification forte avec une YubiKey
À ce stade, nous avons vu comment accéder à une base KeePass placée sur un emplacement réseau. Nous allons maintenant voir comment ajouter un second facteur d’authentification à l’aide d’une YubiKey.
3.1 Une Yubi quoi ?
a YubiKey est un appareil électronique, produit par la société Yubico, de la taille d’une clé USB et conçu pour l’authentification coûtant environ 50 € pour la version 5 NFC utilisée dans cet article. Lorsqu’elle est branchée à un ordinateur, elle se présente comme un clavier dans certains modes ce qui permet de limiter les problèmes de pilotes et de compatibilité, ce qui rend les YubiKeys compatibles avec beaucoup de systèmes. Le principe de sécurité proposé ici est celui de l’authentification forte, c’est-à-dire que pour s’authentifier, il faut :
- connaître un secret (le mot de passe) ; et
- détenir quelque chose (la YubiKey).
Les YubiKeys supportent de nombreux standards d’authentifications [11] du mot de passe à usage unique (OTP), au mot de passe statique, en passant par le HMAC-SHA1 et le FIDO U2F [12]. Ils s’appuient, selon le mode choisi, sur un mécanisme de secret partagé, de clé publique/privée, le temps ou encore un compteur.
De nombreux services très populaires sur Internet sont compatibles avec les YubiKeys [13] : Google, GitHub, AWS, etc.
3.2 Static Password, OTP ou challenge-response mode ?
Nous allons donc nous intéresser à comment protéger une base KeePass avec une YubiKey tout en restant accessible depuis Windows, Linux et Android. KeePass supporte les YubiKeys dans trois modes d’usage différents [14] via ses plugins.
- Static Password : dans ce mode, la YubiKey remplace le mot de passe de votre base et c’est la clé qui saisira une chaîne de caractères, constante, dans le champ mot de passe. Il ne s’agit donc pas d’authentification forte et vous transférez simplement la sécurité de votre base sur la détention de l’objet au lieu de la connaissance du secret.
- HMAC-based One-Time Password (RFC6238 [15]) : dans ce mode, l’authentification se fait par mots de passe à usage unique à l’aide d’un compteur synchronisé et d’une clé secrète entre votre base et le client. C’est le plugin OtpKeyProv qui implémente ce mode dans KeePass.
- Challenge-response : dans ce mode, c’est la fonction HMAC-SHA1 qui est utilisée pour prouver la détention de la YubiKey, via le plugin KeeChallenge [16]. La sécurité se base alors sur une clé secrète partagée.
Le mot de passe statique ne répond pas au critère d’authentification forte et l’implémentation de OTP n’est pas adaptée dans ce cadre comme nous allons le voir plus loin. C’est donc sur le mode challenge-response que nous allons nous concentrer dans la suite de cet article.
3.3 Challenge-response
3.3.1 HMAC-SHA1, comment ça fonctionne ?
En HMAC-SHA1, il faut un secret partagé entre la YubiKey et la base. Le fonctionnement de HMAC est très bien expliqué sur Internet [17]. Pour cet article, il suffit de retenir que c’est une fonction de hachage qui mélange la donnée avec une clé secrète. Cela implique que celui qui souhaite vérifier l’intégrité de la donnée détienne cette même clé secrète pour recalculer le même HMAC que l’émetteur. Nous pouvons vulgariser (voir RFC2104 [18] sinon) la formule de HMAC-SHA1 ainsi :
HMAC-SHA1(data,clé) = SHA1(clé XOR SHA1(data XOR clé)
3.3.2 En challenge-response, comment ça fonctionne ?
Si cet algorithme permet de vérifier l’intégrité et l’authenticité d’un message, s’en servir pour authentifier quelqu’un n’est pas immédiat. Il est intéressant de détailler le fonctionnement de HMAC-SHA1 en mode challenge-response, qui n’est pas autant documenté.
Il faut commencer par générer une clé partagée connue uniquement par le client et le serveur. Le serveur doit alors préparer un challenge à l’attention du futur client. Pour cela, il va générer un bloc de données aléatoires ou utiliser des données relatives au client comme un User Id, un code PIN. Le serveur doit ensuite calculer le HMAC-SHA1 de ces données, avec sa clé en commun avec le client. Il peut enfin se servir du résultat du HMAC pour chiffrer en AES des données, par exemple une clé secrète permettant d’accéder à une base KeePass…
À partir de là, le client souhaitant s’authentifier va recevoir le challenge du serveur. Il doit alors calculer à son tour le HMAC-SHA1 du challenge avec sa propre clé. Ce dernier peut alors s’en servir pour déchiffrer le bloc protégé en AES qu’il stocke et récupérer le secret nécessaire pour s’authentifier.
3.4 Pourquoi pas l’OTP ?
D’abord, le plugin OTP vous demande de saisir plusieurs OTP (nombre réglable), cela s’avère peu pratique à l’usage car l’utilisateur doit appuyer n fois sur sa YubiKey pour générer les n codes nécessaires.
De plus, dans ce mode, si nous nous intéressons à la complexité d’une attaque en brute-force, la sécurité repose majoritairement sur la protection d’une clé secrète partagée et d’un compteur. En mode challenge-response HMAC-SHA1, cette clé fait 20 octets, soit un ensemble de 2160 clés possibles. Dans le mode OTP, avec un seul code demandé, le challenge ne ferait que 6 chiffres, soit 106 possibilités. Il faut également tenir compte de la fenêtre de désynchronisation tolérée pour le compteur (le look-ahead) qui augmente le nombre de valeurs valides. Il faut donc configurer plusieurs codes pour rajouter de la complexité au système. La formule suivante peut résumer la complexité du système OTP.
log2(10^(6*n) / look-ahead) où n est le nombre de code demandés. et look-ahead étant le nombre d’écarts tolérés du compteur.
Avec un look-ahead théorique à 1, il faudrait saisir 8 OTP pour obtenir la même complexité face à un brute-force qu’en HMAC-SHA1. Cette valeur passe même à 9 si nous suivons les recommandations de la communauté de KeePass [19], soit autant d’appuis manuels sur la YubiKey. La mise en place de contre-mesures pour ce mode (délais, incrémentation du compteur sur chaque tentative échouée) peuvent permettre à un attaquant de créer un déni de service, forçant le recours au mode récupération. Au final, le mode OTP n’est ni pratique, ni sécurisé pour l’utilisateur, en comparaison du challenge-response.
4. KeePass, YubiKey et KeeChallenge
Il nous reste donc à mettre en place la double authentification dans KeePass avec KeeChallenge et la YubiKey.
4.1 Création de la clé partagée
Nous allons créer la clé partagée avec le logiciel YubiKey PersonalizationTool [20]. Il faut suivre dans les menus Challenge-response> HMAC-SHA1, sélectionner le Configuration Slot 2 (utilisé par défaut par le plugin) et générer une nouvelle clé d’une taille fixe de 64 bits [21] et cliquer sur Write Configuration après avoir connecté la clé.
SAUVEGARDEZ CETTE CLÉ !
Attention
KeePass ne fournit aucun moyen de recouvrement sur la base. Si votre YubiKey venait à se perdre ou être détruite : vous n’auriez aucun moyen d’accéder à votre base de mot de passe sans cette clé. Donc, conservez précieusement une copie de la clé dans un emplacement sécurisé (coffre-fort, enveloppe scellée, etc.).
4.2 Protection initiale de la base
C’est le plugin KeeChallenge qui implémente le challenge-response HMAC-SH1 pour KeePass et une YubiKey. Il s’installe de la même manière que IOProtocolExt que nous avons utilisé au départ.
Que vous rajoutiez un accès YubiKey sur une base existante (menu Fichier > Changer la Clé Maître) ou lors de la création d’une nouvelle base, la procédure est la même. Au moment où la fenêtre Create Composite Master Key s’affiche : rentrez le mot de passe maître, puis cliquez sur Show expert options > Key File / provider > YubiKey challenge-response, avant de valider.
Vous devrez ensuite valider une première fois ce challenge avec votre YubiKey. C’est une sécurité du plugin pour s’assurer que vous détenez bien une YubiKey avec la même clé et que vous avez la connaissance de cette clé. Une fois cette opération réalisée, votre base est protégée grâce à la clé secrète HMAC-SHA1 de votre YubiKey, en plus du mot de passe
4.2.1 Implémentation technique
En mode challenge-response, le plugin va stocker à côté de votre base KeePass un fichier XML contenant le défi et une partie de la clé composite , chiffrée en AES et associé à un hash de contrôle. Le serveur ne possédant pas KeePass, ce fichier sera téléchargé en même temps que la base et déchiffré localement par le client. Dans notre cas et par rapport au schéma vu plus haut, le serveur est en fait le client KeePass qui vient de télécharger le XML contenant le challenge et la YubiKey devient alors le client souhaitant accéder au service.
Les plus curieux pourront aller jeter un œil aux sources du projet [22] pour en vérifier l’implémentation.
4.3 KeePass avec une YubiKey sur un serveur
4.3.1 Accès depuis Windows
Sous Windows, une fois le plugin KeeChallenge installé, il faut ouvrir votre base et saisir le mot de passe maître puis sélectionner le provider Key File > YubiKey challenge-response et brancher votre YubiKey avant de cliquer sur OK.
Le programme va alors vous demander de valider votre présence devant la clé en appuyant sur celle-ci (pour le cas où la clé serait restée branchée en votre absence), et votre base va s’ouvrir normalement.
4.3.2 Accès depuis Linux
Pour Ubuntu 18.04. Il manque quelques bibliothèques pour pouvoir faire fonctionner la YubiKey avec le plugin, Yubico les met à disposition dans un ppa. Voici les dépendances à installer.
sudo add-apt-repository ppa:yubico/stable sudo apt-get update sudo apt-get install libjson-c-dev libyubikey0 libykpers-1-1
Une fois le plugin KeeChallenge installé, il vous suffira de démarrer KeePass et d’effectuer les mêmes opérations que sous Windows pour accéder à votre base.
4.3.3 Accès depuis Android
Sous Android, l’application Keepass2Android supporte le mode challenge-response, moyennant l’installation de l’application ykDroid [23], un pilote supportant ce mode. Dans l’application, il vous suffira alors de sélectionner : type de clé maître > Mot de passe + Défi-Réponse > Charger le fichier OTP auxiliaire… Puis de présenter votre YubiKey contre le lecteur NFC de votre téléphone, et saisir enfin votre mot de passe avant d’appuyer sur déverrouiller pour accéder à votre base depuis votre smartphone Android.
5 Analyse de la sécurité de la solution
5.1 Renouvellement du challenge
Le plugin KeeChallenge utilise comme source du challenge un nombre aléatoire, et change ce nombre à chaque ouverture de la base. Vous pouvez le vérifier en surveillant le contenu du fichier XML entre deux ouvertures.
Le déchiffrement s’effectuant localement sur le client, un attaquant en interception réseau n’aurait accès qu’au challenge et au bloc AES chiffré. En théorie, multiplier les chiffrés d’un même message clair avec des clés différentes affaiblit sa sécurité, néanmoins AES est robuste vis-à-vis de la cryptanalyse différentielle. L’autre axe d’attaque consiste à essayer de prédire le secret partagé à partir de challenges interceptés, hors ces derniers ne sont que des nombres aléatoires sans lien avec le secret. Le fait de renouveler le challenge à chaque ouverture, permet alors de le rendre inutilisable sur des versions ultérieures ou antérieures du bloc chiffré.
Il faut garder en tête qu’un attaquant obtenant une réponse valide en plus du bloc chiffré AES correspondant, obtiendra la moitié de la clé maître. Il est donc indispensable d’utiliser un mot de passe en plus de la YubiKey et de chiffrer la communication qui permet de rapatrier la base KeePass et le fichier XML du challenge.
5.2 Utilisation de SHA1
Certains auront noté que le plugin utilise HMAC-SHA1 et que SHA1 est désormais obsolète. Néanmoins, l’attaque sur SHA1 n’est, d’une part, pas triviale et pose, d’autre part, plusieurs prérequis notamment sur la capacité de l’attaquant à modifier le document source. Cela s’avère difficile lorsque le document source est XORé avec une clé secrète. Les algorithmes HMAC sont plus résistants aux collisions que les fonctions de hachage seules qu’ils utilisent. Cela rend l’utilisation de SHA1 acceptable dans ce cadre, néanmoins une mise à jour de KeeChallenge pour HMAC-SHA2 serait souhaitable.
5.3 YubiKey non libre
La YubiKey n’est pas un équipement open source, ni open hardware, il s’agit d’un produit commercial d’une société installée aux États-Unis. Elle implémente en tête de liste le protocole FIDO, résultat de l’alliance de petites compagnies américaines comme Google, Amazon, Facebook, Microsoft. C’est un élément à garder en tête en fonction de ce que vous cherchez à protéger. Si la YubiKey paraît adaptée pour protéger votre boite mail personnelle, elle ne l’est pas pour des données sous mention de protection du secret…
5.4 Nécessité de conserver un mot de passe maître
La YubiKey ne demande pas de code PIN pour être utilisée. Il n’y a rien qui empêche de l’utiliser en cas de vol, ce qui impose de conserver un mot de passe maître sur votre base en plus de l’accès KeeChallenge.
S’ajoute qu’en NFC la YubiKey ne demande pas de valider une présence pour répondre. Un attaquant pourrait se contenter de s’approcher suffisamment de votre poche dans le métro pour tenter de valider un accès par exemple. Les plus paranoïaques pourront toujours la stocker dans conteneur TEMPEST !
Conclusion
KeePass reste, du fait de sa certification de sécurité, une référence en matière de gestionnaires de mots de passe. Sa compatibilité avec les YubiKeys le rend d’autant plus attrayant à utiliser pour les particuliers. Et cela pour un prix qui reste compétitif face aux solutions commerciales, par exemple en utilisant un Raspberry Pi et une connexion internet.
Et même si la solution présentée ne semble pas adaptée à de très larges déploiements en entreprise, son usage peut parfaitement convenir à de petites équipes qui souhaitent conserver en interne la maîtrise de leurs mots de passe.
Il est intéressant de voir qu’il existe aujourd’hui des solutions d’authentification forte abordables à base de matériels dédiés. Ces équipements, combinés aux nombreux travaux de la communauté permettent d’obtenir des niveaux de sécurité tout à fait pertinents en dehors de besoins réglementaires et légaux.
Remerciements
Merci à Laure, François, Grégoire, Marion et Jean-Marc, ainsi qu’à l’ensemble du service, pour leurs relectures attentives et leurs avis constructifs !
Références
[1] Recommandations de sécurité relatives aux mots de passe, ANSSI : https://www.ssi.gouv.fr/guide/mot-de-passe/
[2] Hackers Are Passing Around a Megaleak of 2.2 Billion Records – https://www.wired.com/story/collection-leak-usernames-passwords-billions/
[3] Produits certifiés CSPN, KeePass Version 2.10 Portable, ANSSI : https://www.ssi.gouv.fr/entreprise/certification_cspn/keepass-version-2-10-portable/
[4] A Case Study in Attacking KeePass, harmj0y : https://www.harmj0y.net/blog/redteaming/a-case-study-in-attacking-keepass/
[5] KeeThief – A Case Study in Attacking KeePass Part 2, harmj0y : https://www.harmj0y.net/blog/redteaming/keethief-a-case-study-in-attacking-keepass-part-2/
[6] Site officiel de KeePass : https://keepass.info/
[7] Cible de Sécurité CSPN KEEPASS v2.10 portable, ANSSI THALES : https://www.ssi.gouv.fr/uploads/IMG/cspn/anssi-cspn-cible_2010-07fr.pdf
[8] ppa de Julian Taylor : https://launchpad.net/~jtaylor
[9] GitHub de l’application keepass2android : https://github.com/PhilippC/keepass2android
[10] Documentation KeePass Synchronization, KeePass : https://keepass.info/help/v2/sync.html
[11] Liste des fonctions supportées, Yubico : https://www.yubico.com/why-yubico/how-yubikey-works/
[12] Security Keys: Practical Cryptographic Second Factors for the Modern Web, Juan Lang, Alexei Czeskis, Dirk Balfanz, Marius Schilder : https://ai.google/research/pubs/pub45409
[13] Service compatible avec les YubiKeys, Yubico : https://www.yubico.com/works-with-yubikey/catalog/
[14] KeePass & YubiKey, KeePass : https://keepass.info/help/kb/yubikey.html
[15] RFC6238 : https://tools.ietf.org/html/rfc6238
[16] Site officiel de KeeChallenge : http://richardbenjaminrush.com/keechallenge/
[17] HMAC, Wikipédia : https://en.wikipedia.org/wiki/HMAC
[18] RFC2104 : https://tools.ietf.org/html/rfc2104
[19] SourceForge KeePass, Discussion Synch kdbx, incl. OTPKeyProv config file : https://sourceforge.net/p/keepass/discussion/329220/thread/3c469350/#1b66
[20] YubiKey Personalization Tool, Yubico : https://www.yubico.com/products/services-software/personalization-tools/use/
[21] Breaking HMAC, Aaron Toponce : https://pthree.org/2016/07/29/breaking-hmac/
[22] GitHub de KeeChallenge : https://github.com/brush701/keechallenge/tree/master/KeeChallenge/src
[23] GitHub de ykDroid : https://github.com/pp3345/ykDroid
