KeePass multiplateforme en authentification forte avec une YubiKey

Magazine
Marque
MISC
Numéro
103
|
Mois de parution
mai 2019
|
Domaines


Résumé

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.


Body

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 mots 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 sont 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és :

$ 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 mots 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 ?

La 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 (One Time Password, dit 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 :

  • StaticPassword : 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-basedOne-TimePassword (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.

 

1_HMAC-SHA1-process

 

Fig. 1 : Authentification HMAC-SHA1.

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 10possibilité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 codes demandé.

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) peut 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 Personalization Tool [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é !

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 mots 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.

 

2_New-Master-Key-and-Secret-Key

 

Fig. 2 : Saisir une clé secrète dans KeePass.

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ée à 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.

 

3_SchВmaSolutionYukikey-Keechallenge

 

Fig. 3 : Schéma de fonctionnement de la solution KeeChallenge et YubiKey.

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_LoginUbuntuKeepass

 

Fig. 4 : Accès à un trousseau Keepass sous Ubuntu avec une YubiKey.

4.3.3 Accès depuis Android

Sous Android, l’application Keepass2Android supporte le mode challenge-response, moyennant l’installation préalable de l’application ykDroid [23] qui rend disponible 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_KeePass2Android_Et_Yubikey

 

Fig. 5 : Une YubiKey et Keepass2Android.

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, or 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 un 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

 

Sur le même sujet

Hébergement privé de dépôts Git

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
109
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Nous allons voir comment mettre en place un hébergement de dépôts Git privé indépendant et évolutif, avec seulement trois containers. Cela comprendra une interface web, la possibilité de gérer plusieurs utilisateurs, organisations et leurs dépôts, qu’ils soient privés ou publics.

Introduction à Zero Trust 

Magazine
Marque
MISC
Numéro
110
|
Mois de parution
juillet 2020
|
Domaines
Résumé

La sécurité informatique adore les modes. Le « Zero Trust » fait partie de ces concepts qui sont devenus populaires du jour au lendemain. Et comme le sexe chez les adolescents, « tout le monde en parle, personne ne sait réellement comment le faire, tout le monde pense que tous les autres le font, alors tout le monde prétend le faire* ».

Pré-authentification Kerberos : de la découverte à l’exploitation offensive

Magazine
Marque
MISC
Numéro
110
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Les opérations relatives à l’authentification Kerberos ne sont pas toujours remontées dans les journaux des contrôleurs de domaine, ce qui fait de ce protocole une arme de choix pour mener des attaques furtives en environnement Active Directory. Le mécanisme de pré-authentification de ce protocole offre par exemple des possibilités intéressantes pour attaquer les comptes d’un domaine.

Les enjeux de sécurité autour d’Ethernet

Magazine
Marque
MISC
HS n°
Numéro
21
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Quand nous parlons attaque, cela nous évoque souvent exploit, faille logicielle, ou même déni de service distribué. Nous allons revenir à des fondamentaux réseaux assez bas niveau, juste après le monde physique, pour se rendre compte qu’il existe bel et bien des vulnérabilités facilement exploitables par un attaquant. Nous verrons également qu’il existe des solutions pour s’en protéger.

Implémentation d’une architecture processeur non supportée sur IDA PRO et Ghidra

Magazine
Marque
MISC
HS n°
Numéro
21
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Malgré le nombre d’outils aidant au désassemblage voire à la décompilation de programmes, il arrive parfois que les mécanismes ou les processeurs étudiés ne soient pas nativement supportés. Pour cette raison, certains outils proposent des API permettant d’implémenter une nouvelle architecture. Cet article détaillera les grandes étapes de ce travail pour deux outils majoritairement utilisés, à savoir IDA PRO et Ghidra.

Cluster et orchestration de conteneurs avec Docker Swarm

Magazine
Marque
Linux Pratique
HS n°
Numéro
47
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Cet article prolonge mon précédent article [1] et parle de la capacité à introduire de la haute disponibilité dans les environnements de conteneurs Docker, critère indispensable pour pouvoir utiliser ces technologies jusqu’à la production, ceci au travers de la notion de cluster et d’orchestration de conteneurs.

Par le même auteur

Zero Trust : anti-SOC, tu perds ton sang froid ?

Magazine
Marque
MISC
Numéro
110
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Les security operation centers, au sens large, sont aujourd’hui au cœur des systèmes d’information des entreprises. En revanche, beaucoup adoptent encore et toujours une approche traditionnelle de la sécurité du SI. Comment le paradigme Zero Trust va-t-il impacter nos supervisions ? Repensons un peu à toutes ces années de service pour voir ce que Zero Trust peut apporter au SOC, et réciproquement comment ces derniers peuvent accompagner la transition.

KeeRest : mettez du DevOps dans votre KeePass

Magazine
Marque
MISC
Numéro
108
|
Mois de parution
mars 2020
|
Domaines
Résumé

Nous avions vu dans MISC n°103 comment déployer une base KeePass en mode SaaS ciblant les particuliers ou de petits périmètres professionnels. Dans un autre monde, les pratiques DevOps se démocratisent et demandent d’augmenter l’agilité des développements tout en réduisant les délais de mise en production. Cet article est le fruit d’une collaboration entre un DevOps et un ingénieur SSI pour voir de quelle manière il est possible de tirer profit de KeePass dans ces environnements.

KeePass multiplateforme en authentification forte avec une YubiKey

Magazine
Marque
MISC
Numéro
103
|
Mois de parution
mai 2019
|
Domaines
Résumé

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.