Gestion des mots de passe : sécurité auto-hébergée par niveaux

La gestion des mots de passe impose un compromis entre sécurité, accessibilité, disponibilité et complexité opérationnelle.

J’utilise un système autogéré fondé sur des outils Linux standards : pass, GnuPG, YubiKey, Git et LUKS. Ici, auto-hébergé signifie que je contrôle les fichiers de mots de passe et leurs clés de déchiffrement ; l’accès ne nécessite pas un service de gestion de mots de passe.

Tous les secrets ne nécessitent pas la même protection. Plus un identifiant est sensible, plus son accès exige une procédure délibérée.

Trois niveaux d’accès

Je classe les identifiants en trois niveaux, chacun avec un équilibre différent entre commodité et sécurité.

La distinction concerne les conditions de déchiffrement autant que le lieu de stockage.

Chiffrement et contrôle d’accès avec pass

pass stocke chaque secret dans un fichier individuellement chiffré par GnuPG, généralement dans ~/.password-store. Un répertoire peut être configuré pour un ou plusieurs destinataires GPG. Des répertoires différents peuvent utiliser des groupes différents. Manuel de pass.

Les secrets à faible impact peuvent être chiffrés pour une clé locale. Les identifiants plus sensibles peuvent utiliser une clé dont la sous-clé privée de déchiffrement est sur YubiKey. GnuPG applique la politique de destinataires.

Ajouter un destinataire crée une autre voie de déchiffrement du même secret. Cela n’exige pas la participation de tous. Pour imposer l’usage du token au quotidien, chiffrez les répertoires sensibles uniquement pour les identités matérielles prévues. Un destinataire local fournirait une alternative contournant le token.

Accès matériel avec YubiKey

Pour les identifiants sensibles, j’utilise des clés GPG dont les données privées de déchiffrement sont sur YubiKey. Le dispositif effectue l’opération privée sans exporter ces données vers le système de fichiers de l’hôte.

Cela sépare les fichiers chiffrés de la clé nécessaire au déchiffrement. Répliquer les fichiers ne nécessite pas de copier les clés privées sur chaque poste.

Cette méthode peut fonctionner sous Linux et Android avec un logiciel compatible et un token adapté, par NFC ou USB. La compatibilité dépend du client, du token et des algorithmes ; testez la combinaison prévue. Documentation des tokens OpenKeychain.

Préservez et testez la récupération cryptographique avant de transférer les clés sur un token. Garder le secret hors de la machine traite de la séparation des clés ; Un token n’est pas le secret traite de la récupération après perte du dispositif.

Un coffre hors ligne pour les identifiants critiques

Pour les identifiants critiques, je conserve un magasin pass distinct sur une clé USB chiffrée avec LUKS. Le support reste déconnecté par défaut.

L’accès suit cette séquence :

1. Connecter le support USB à une machine de confiance.
2. Déverrouiller le volume LUKS avec une phrase de passe.
3. Monter le système de fichiers déchiffré.
4. Effectuer un montage bind du coffre à l’emplacement attendu du magasin.
5. Utiliser pass avec déchiffrement GnuPG via YubiKey.
6. Démonter le montage bind et le système de fichiers, fermer le mapping LUKS et déconnecter le support.

J’automatise le montage et le démontage par un script. Le déverrouillage du stockage et l’autorisation d’utiliser la clé restent explicites.

LUKS protège le stockage lorsqu’il est verrouillé. GnuPG protège chaque secret à l’intérieur. Même lorsque le système de fichiers est déverrouillé, les secrets restent chiffrés jusqu’à leur déchiffrement.

Aucune des deux couches ne protège un mot de passe déchiffré sur un hôte compromis. Je limite donc l’accès au coffre à des appareils choisis et de confiance. Un token protège sa clé privée ; il ne rend pas l’ordinateur demandeur fiable.

Réplication, synchronisation et récupération

Pour les magasins quotidiens, Git fournit historique et synchronisation. Les fichiers chiffrés peuvent être répliqués entre appareils ou conservés dans une forge Git privée. L’historique validé peut permettre de récupérer des modifications ou suppressions accidentelles tant qu’il reste disponible.

Pour le coffre hors ligne, je conserve plusieurs supports USB chiffrés. Un script dédié propage les mises à jour. Les supports peuvent être actualisés successivement sans être tous connectés en même temps.

Cela exige de la discipline. Les copies hors ligne peuvent contenir des versions différentes jusqu’à la synchronisation. Vérifiez quelle copie contient les changements attendus avant de les propager.

L’historique Git n’est ni une politique de sauvegarde ni un journal d’accès. Il consigne les modifications validées des fichiers chiffrés, pas les lectures ou déchiffrements. Les noms de fichiers et répertoires peuvent révéler des informations sur les comptes même lorsque le contenu est chiffré.

La restauration du stockage et la récupération cryptographique sont distinctes. Plusieurs copies du coffre protègent contre la perte de stockage. Elles ne récupèrent pas une clé privée perdue ou une phrase de passe LUKS oubliée. La procédure doit couvrir les tokens perdus, les clés privées autorisées, le déverrouillage des volumes et l’accès aux sauvegardes indépendantes.

Testez avec le token quotidien indisponible. Vérifiez que vous pouvez déverrouiller un volume de secours et déchiffrer une entrée de test non sensible par la méthode documentée.

Compromis opérationnels

Cette configuration exige la gestion des destinataires, tokens, volumes chiffrés, synchronisation et récupération. Elle offre des propriétés que j’apprécie :

• Contrôle des données : les fichiers restent sous mon contrôle.
• Portabilité : le système utilise des outils établis et des formats documentés.
• Protection sélective : les exigences d’accès suivent la sensibilité des identifiants.
• Récupération : des copies indépendantes et une récupération des clés testée réduisent la dépendance à un appareil.
• Isolation hors ligne : les identifiants critiques sont physiquement déconnectés lorsqu’ils ne sont pas utilisés.
• Indépendance du service : le déchiffrement local ne nécessite pas que la forge Git ou un fournisseur de gestion de mots de passe soit disponible.

L’objectif est une protection proportionnée. Les identifiants courants restent accessibles. Les identifiants sensibles nécessitent le token. Les identifiants critiques nécessitent aussi la connexion et le déverrouillage du coffre hors ligne.

Maintenez les politiques de destinataires, synchronisez délibérément et répétez les tests après tout changement de clés, d’appareils ou d’identifiants de volume.