C’est la partie la plus sensible de Server Manager sur le plan de la sécurité. Voici exactement ce qui arrive à tes identifiants SSH à chaque étape.
Quand tu connectes un serveur (sans l’enregistrer)
Le parcours par défaut : saisis l’adresse IP de ton serveur, ton nom d’utilisateur et ton mot de passe ou ta clé privée dans la fenêtre de connexion, puis clique sur Connexion.
- Tes identifiants sont envoyés à Server Manager via HTTPS
- Ils sont conservés dans la mémoire de processus de la session côté serveur qui communique avec ton serveur
- Rien n’est écrit sur disque. Pas de base de données, pas de fichier journal, pas de cache.
- Quand tu te déconnectes, que tu fermes l’onglet de ton navigateur ou que la session expire, les identifiants sont supprimés de la mémoire
Si notre serveur redémarre, tes identifiants disparaissent — tu devras te reconnecter manuellement la prochaine fois. C’est volontaire.
Quand tu enregistres un profil de serveur (facultatif)
Si tu coches « Enregistrer ce serveur » pendant la connexion, nous chiffrons tes identifiants avec une phrase secrète que toi seul connais.
Ce qui est chiffré
Le bloc chiffré contient ton mot de passe SSH OU ta clé privée + la phrase secrète optionnelle de la clé. Il contient aussi un petit en-tête de métadonnées qui nous indique quel type d’identifiant utiliser.
Fonctionnement du chiffrement
- Tu fournis une phrase secrète au moment de l’enregistrement (nous te recommandons d’en choisir une que tu n’utilises nulle part ailleurs)
- La phrase secrète passe par scrypt — une fonction de dérivation de clé basée sur mot de passe, volontairement lente — avec un sel aléatoire de 16 octets propre à chaque serveur, afin de produire une clé AES de 256 bits
- Tes identifiants sont chiffrés avec AES-256-GCM (chiffrement authentifié — un texte chiffré modifié ne peut pas être déchiffré, et il n’y a pas d’attaque par oracle de remplissage)
- Nous stockons dans la base de données le texte chiffré, le sel, le nonce GCM et le tag d’authentification GCM
- Ta phrase secrète n’est jamais stockée. Ni hachée, ni dérivée, ni présente d’une quelconque manière de notre côté.
Comment nous distinguons une « mauvaise phrase secrète » de « données modifiées »
Les deux échouent de la même façon : la vérification du tag d’authentification AES-GCM échoue. Nous n’avons aucun vérificateur stocké auquel comparer ta phrase secrète, ni aucun hachage susceptible de fuiter. Mauvaise phrase secrète = erreur de déchiffrement = tu la ressaisis et tu réessaies.
Quand tu te reconnectes à un serveur enregistré
Tu colles ta phrase secrète. Nous redérivons la clé avec scrypt + le sel stocké, déchiffrons le bloc d’identifiants, utilisons les identifiants déchiffrés pour ouvrir la session SSH, puis supprimons immédiatement les identifiants déchiffrés de la mémoire une fois la session établie.
Les identifiants SSH déchiffrés n’existent que dans le code qui gère la session, pendant la durée de la connexion SSH elle-même. Comme pour le parcours sans enregistrement ci-dessus — uniquement en mémoire, jamais sur disque.
Ce qui se passe si notre serveur est compromis
C’est la menace contre laquelle nous avons conçu ce système. Concrètement :
- L’attaquant obtient un accès en lecture à la base de données : il récupère du texte chiffré. Pour utiliser un identifiant enregistré, il doit casser la phrase secrète par force brute, serveur par serveur. - scrypt est volontairement lent — chaque tentative de phrase secrète prend environ 100 ms ou plus de temps CPU sur du matériel moderne. Casser par force brute une phrase secrète aléatoire de seulement 6 caractères prendrait des années sur une seule machine, et des décennies sur des GPU grand public.
- L’attaquant obtient une compromission complète du serveur (RCE — exécution de code à distance — pendant une session active) : il pourrait lire les identifiants déchiffrés des utilisateurs actuellement en ligne. Mais il n’obtient pas l’accès aux identifiants des utilisateurs enregistrés mais hors ligne.
- L’attaquant obtient une sauvegarde de la base de données datant de la semaine dernière : même situation qu’un accès en lecture — il n’a que du texte chiffré.
Ce que cela signifie concrètement pour toi
Les trois scénarios ci-dessus correspondent à des niveaux d’exposition très différents dans la réalité :
- Lecture de la base de données ou sauvegarde volée (le type de faille le plus courant) : l’attaquant obtient des blocs chiffrés, et rien d’autre. Pour utiliser réellement un identifiant enregistré, il devrait casser ta phrase secrète par force brute, ce que scrypt rend irréaliste si elle est robuste. Tes serveurs restent protégés.
- Compromission complète du serveur pendant que tu es activement connecté (rare et grave) : comme une session SSH ouverte a besoin de tes vrais identifiants en mémoire, un attaquant qui contrôlerait notre processus en cours d’exécution pendant cette fenêtre pourrait extraire les identifiants déchiffrés des utilisateurs connectés à ce moment-là et s’en servir pour se connecter à leurs vrais serveurs. Si tu es hors ligne à ce moment-là, tes identifiants enregistrés ne sont toujours pour lui que du texte chiffré — tu n’es pas affecté.
La propriété essentielle : même dans le scénario catastrophe d’une compromission complète, l’impact se limite aux « personnes qui se trouvent en ligne pendant l’attaque », et non à « toutes les personnes qui ont déjà utilisé Server Manager ». La plupart des failles catastrophiques exposent les secrets de tous les utilisateurs d’un coup ; cette conception évite délibérément cela.
| Type de faille | Ce que l’attaquant obtient |
|---|---|
| Lecture de la base de données (le plus courant) | Uniquement du texte chiffré — aucun identifiant utilisable |
| Sauvegarde de base de données volée | Uniquement du texte chiffré |
| RCE sur session active complète (rare, grave) | Les identifiants déchiffrés des seuls utilisateurs connectés pendant cette fenêtre |
C’est une protection importante contre le scénario de faille le plus courant (l’exfiltration de données), et cela reconnaît volontairement qu’un attaquant capable de compromettre complètement un serveur en fonctionnement représente une menace différente et plus difficile, que nous ne prétendons pas éliminer totalement — tout en limitant même ce pire cas aux utilisateurs actuellement en ligne.
Conseils pour une phrase secrète robuste
Tout le système de chiffrement ne vaut que par la solidité de ta phrase secrète. Recommandations :
- Au moins 20 caractères aléatoires, ou
- Cinq mots français aléatoires (dans l’esprit de « correct horse battery staple ») — faciles à retenir, difficiles à casser par force brute
- Ne réutilise jamais la phrase secrète que tu utilises pour te connecter à ton ordinateur, ton gestionnaire de mots de passe ou ta messagerie
- Ne la partage pas. Server Manager lui-même n’en a pas besoin — elle ne sert qu’entre toi et le bloc chiffré.
Si tu perds la phrase secrète, les identifiants enregistrés sont irrécupérables. Tu devras supprimer le profil de serveur enregistré et le recréer depuis zéro.
Pourquoi nous ne proposons pas d’accès par clé « sans mot de passe » ou « plus pratique »
Certains produits stockent les clés SSH sans chiffrement (« faites-nous confiance, nous les gardons en sécurité ») ou les protègent uniquement par le mot de passe du compte utilisateur. Server Manager ne le fait pas. Le mécanisme de phrase secrète fait la différence entre « toute personne ayant notre base de données peut se connecter en SSH à tes serveurs » et « toute personne ayant notre base de données doit d’abord casser ta phrase secrète par force brute ». Nous pensons que cela vaut bien le petit effort ponctuel de choisir une phrase secrète.
Ce qui n’est JAMAIS envoyé ni stocké
- Les clés privées SSH en clair dans notre base de données
- Les mots de passe SSH en clair dans notre base de données
- Ta phrase secrète de chiffrement — nulle part, sous aucune forme
- Les identifiants déchiffrés dans un stockage persistant — disque, journaux, sauvegardes, cache
Le seul endroit où des identifiants déchiffrés existent est la mémoire de processus de la session active, et uniquement pendant la durée de cette session.
Questions ou préoccupations ?
Si quelque chose dans cet article n’est pas clair, ou si tu as une question de sécurité précise sur la manière dont tes identifiants sont traités, contacte-nous via Contact — nous serons ravis de t’expliquer plus en détail.