Sur un coffre exposé depuis moins d'une semaine, le journal d'accès ressemble à ceci :
185.x.x.x - POST /identity/connect/token 400 - "grant_type=password&username=admin@..."
185.x.x.x - POST /identity/connect/token 400 - "grant_type=password&username=contact@..."
92.x.x.x - GET /admin 302
92.x.x.x - POST /admin 400
Deux comportements distincts. Le premier essaie des couples identifiant et mot de passe sur l'authentification normale. Le second cherche la console d'administration, qui n'est pas la même porte et ne se protège pas de la même façon.
Ce trafic est le bruit de fond d'Internet, il arrive à tout le monde, et il n'a rien d'inquiétant en soi. Ce qui compte est de savoir ce qu'il obtiendrait s'il finissait par passer. Autrement dit : que voit exactement quelqu'un qui prend la main sur le serveur ?
Ce qu'il ne voit pas
Vaultwarden est une réimplémentation en Rust du serveur Bitwarden, sous licence AGPL version 3, compatible avec les applications clientes officielles. Il en hérite le point le plus important : le chiffrement se fait sur le poste de l'utilisateur.
Le serveur ne reçoit jamais le mot de passe maître. Il reçoit une valeur dérivée, qui sert à l'authentification, et des blocs chiffrés qu'il se contente de stocker. La clé qui déchiffre ces blocs est calculée sur le poste client à partir du mot de passe maître et n'est jamais transmise.
Conséquence directe : un attaquant qui copie la base de données repart avec des blocs inexploitables. Il devra attaquer chaque mot de passe maître hors ligne, un par un, et la robustesse de ce mot de passe décide alors de tout. Un mot de passe maître long et unique tient. Un mot de passe maître réutilisé depuis une ancienne fuite tombe en quelques minutes.
C'est une bonne architecture, et c'est exactement pour cette raison qu'un attaquant sérieux ne s'y attaque pas de front. Il prend les quatre autres chemins.
Premier chemin : la console d'administration
Vaultwarden expose une interface d'administration à l'adresse /admin, protégée par un jeton unique défini dans la configuration. Ce n'est pas un compte utilisateur, il n'y a pas de second facteur, et il n'y a pas de notion de rôle : quiconque a ce jeton administre le serveur.
Depuis cette console, on crée des utilisateurs, on en supprime, on modifie la configuration, on désactive des protections. On ne lit pas les coffres, le chiffrement l'en empêche, mais on peut préparer le terrain.
Trois mesures ferment ce chemin. La première est de ne pas l'exposer du tout : un filtrage au niveau du proxy inverse restreint /admin à une plage d'adresses internes ou au réseau d'administration. La deuxième est un jeton long, généré aléatoirement et stocké dans un coffre à secrets, jamais dans un fichier de composition versionné. La troisième, la plus simple, consiste à laisser la variable vide en fonctionnement normal, ce qui désactive entièrement la console, et à ne la réactiver que le temps d'une opération.
# Jeton d'administration, à stocker hors du dépôt
openssl rand -base64 48
Deuxième chemin : les inscriptions ouvertes
Par défaut, l'inscription est possible. Sur un serveur accessible depuis Internet, cela signifie que n'importe qui peut se créer un compte sur votre infrastructure et y stocker ce qu'il veut.
Le risque n'est pas que ce compte lise les coffres des autres, il ne le peut pas. Le risque est double : un hébergement gratuit de contenu arbitraire sur votre machine, et une surface d'attaque supplémentaire côté application.
Deux variables règlent la question : interdire les inscriptions libres et n'autoriser que les invitations, ou restreindre les inscriptions à un domaine de courriel donné. Sur un déploiement d'entreprise, la première option est la bonne. Le rattachement à un annuaire existant par authentification unique, désormais disponible, évite en prime la gestion manuelle des arrivées et des départs.
Troisième chemin : le poste de l'utilisateur
C'est le chemin le plus court et le seul qui donne accès au contenu en clair.
Le chiffrement côté client protège le transport et le stockage. Il ne protège pas contre un poste compromis, où le coffre est déverrouillé et la clé en mémoire. Un logiciel espion sur une machine de travail lit ce que lit l'utilisateur, coffre compris.
Trois réglages limitent la fenêtre d'exposition. Le verrouillage automatique après quelques minutes d'inactivité, qui purge la clé de la mémoire. Le verrouillage au démarrage du navigateur plutôt que la conservation de la session. Et le second facteur, qui empêche qu'un mot de passe maître volé suffise à ouvrir le coffre depuis une autre machine.
Le second facteur ne relève pas du confort. Sur un coffre d'équipe, il devrait être obligatoire pour tout le monde, et une clé matérielle du type FIDO2 vaut mieux qu'un code par application, lui-même infiniment préférable à un code par message.
Quatrième chemin : la sauvegarde
Le coffre chiffré a une propriété inconfortable : il est parfaitement inutile sans sa clé de chiffrement d'attachements et ses paramètres. Et il est parfaitement exploitable par un attaquant patient si la sauvegarde traîne au mauvais endroit.
Une sauvegarde de coffre se traite comme le coffre lui-même : chiffrée au repos, stockée hors du serveur, et avec un accès distinct de celui du serveur. Un compte de sauvegarde qui peut aussi lire les sauvegardes est un compte qui offre les deux moitiés du problème à qui le compromet. Le principe de l'immuabilité du dépôt prend ici tout son sens : une sauvegarde qu'un attaquant peut effacer après s'être servi ne prouve rien et ne restaure rien.
Et comme partout, la restauration se teste. Sur un coffre, l'exercice est rapide : restaurer sur une instance isolée, ouvrir un compte de test, vérifier qu'un secret connu sort en clair.
Ce qu'on regarde en premier
Sur une installation neuve, quatre points précèdent tout le reste : la console d'administration filtrée ou désactivée, les inscriptions fermées, le second facteur imposé, et la sauvegarde chiffrée hors machine. Le reste des réglages peut attendre la semaine suivante ; ces quatre-là, non.
Vient ensuite ce qui fait la différence dans la durée. La version doit rester récente : la 1.37.3, publiée le 13 septembre 2026, apporte par exemple la révocation des jetons de second facteur mémorisés lors d'un changement d'identifiants et une limitation de débit sur les points d'authentification, deux corrections qui portent précisément sur les chemins décrits plus haut. Un serveur laissé sur une version d'il y a deux ans accumule ce genre de manques sans que rien ne le signale.
La supervision, enfin, doit remonter deux choses : les échecs d'authentification répétés, et les accès à la console d'administration. Le reste du trafic est du bruit ; ces deux signaux-là ne le sont pas. Un outil comme CrowdSec ou une règle de bannissement classique traite le premier, et le second se journalise au niveau du proxy inverse.
Le point aveugle
Il reste un risque qu'aucun réglage ne couvre : le départ d'un salarié qui connaissait les mots de passe partagés de l'équipe. Le coffre ne change rien à cette situation. Il la rend seulement visible, puisqu'il sait dire quels secrets étaient partagés avec qui.
La procédure de départ doit donc inclure la rotation des secrets auxquels la personne avait accès, et cette rotation est un travail réel, pas une case à cocher. Un coffre bien tenu la rend possible en une demi-journée. Sans coffre, personne ne sait par où commencer, et c'est le vrai argument en faveur de l'outil, bien avant le confort du remplissage automatique des formulaires.
Sources
- Dépôt GitHub dani-garcia/vaultwarden, licence AGPL v3, serveur compatible Bitwarden écrit en Rust, 67 961 étoiles au 21 septembre 2026
- Notes de version 1.37.3, publiée le 13 septembre 2026, révocation des jetons de second facteur et limitation de débit sur l'authentification
- Wiki Vaultwarden, configuration, console d'administration, contrôle des inscriptions et variables d'environnement
- ANSSI, recommandations relatives à l'authentification multifacteur et aux mots de passe, exigences sur le mot de passe maître et le second facteur
