La sécurité chez Termalin

Termalin est un client SSH : il détient les identifiants les plus sensibles que vous possédez. Cette page explique — simplement — ce que nos serveurs stockent, ce qu’ils ne peuvent jamais lire, et pourquoi vous n’avez pas à leur faire beaucoup confiance.

Le chiffrement de bout en bout, concrètement

Tout ce qui compte est chiffré sur votre appareil avant d’être envoyé où que ce soit, avec une clé dérivée de votre mot de passe maître (PBKDF2-HMAC-SHA256, 600 000 itérations → AES-256-GCM). Le mot de passe maître ne quitte jamais votre appareil. Nous ne pouvons pas lire vos données, et nous ne pouvons pas les réinitialiser à votre place — c’est le choix de conception, pas un bug. Votre filet de sécurité est le vôtre à conserver : définissez un code de récupération facultatif et vous pourrez revenir si vous oubliez un jour le mot de passe ; sautez cette étape, et un mot de passe oublié signifie que les données sont perdues. Dans les deux cas, le pouvoir de récupérer reste chez vous, jamais chez nous.

Ce que voient nos serveurs

Donnée	Le serveur peut-il lire ?
Vos hôtes, clés SSH, mots de passe, snippets (synchro)	Non — uniquement un blob chiffré
Enregistrements de sessions de terminal (contenu)	Non — uniquement un blob chiffré
Votre mot de passe maître	Jamais envoyé
E-mail du compte + mot de passe	E-mail oui ; mot de passe stocké sous forme de hachage Argon2
Titre de l’enregistrement et libellé de l’hôte	Non — chiffrés avec votre mot de passe maître, comme l’enregistrement
Métadonnées de l’enregistrement (durée, taille, intervention d’un agent IA ou non)	Oui — utilisées pour les listes et les quotas
Forfait, noms d’appareils, horodatages	Oui
Sessions du terminal web (l’espace web)	Transitent par notre serveur pendant qu’elles sont actives ; non stockées. L’hôte, le port et le nom d’utilisateur sont journalisés
Commandes que les applications d’IA exécutent via l’endpoint MCP hébergé	Oui — le texte de la commande figure dans votre journal d’activité ; sa sortie n’est conservée que si vous l’activez, chiffrée avec une clé que vous seul détenez
Métriques des serveurs et alertes des serveurs avec Connector	Oui — nécessaires pour tracer les graphiques et déclencher les alertes (voir la politique de confidentialité, en anglais)
Sel de dérivation de clé	Oui — un sel n’est pas un secret ; il permet à l’espace web de dériver votre clé dans votre navigateur

Les mises à jour ne peuvent pas être falsifiées

Les mises à jour automatiques sont signées avec une clé Ed25519 hors ligne ; la clé publique correspondante est embarquée dans l’app. Avant d’installer quoi que ce soit, l’app vérifie la signature du manifeste de version et le SHA-256 de l’installeur par rapport à celle-ci. Notre propre serveur n’est pas une partie de confiance ici : même un serveur de mise à jour entièrement compromis (ou une redirection DNS/hosts) peut retenir des mises à jour — il ne peut pas en injecter une.

L’app authentifie le serveur, pas seulement TLS

Avant d’envoyer vos identifiants de compte où que ce soit, l’app met le serveur au défi avec un nonce aléatoire ; le serveur doit le signer avec sa clé d’identité, vérifiée par rapport à une clé publique embarquée dans l’app. Un faux backend — atteint via un fichier hosts ou une redirection DNS, ou une machine configurée pour faire confiance à un certificat TLS supplémentaire — ne peut pas produire cette signature, donc il ne voit jamais votre mot de passe.

Aucun secret dans le binaire

L’application de bureau n’embarque que des clés publiques. Inspecter les fichiers de l’app ne donne rien d’exploitable. Tout ce qui est payant est appliqué côté serveur.

L’espace web, en toute honnêteté

L’espace web déchiffre les enregistrements dans votre navigateur avec votre mot de passe maître — le mot de passe ne quitte jamais la page. La mise en garde honnête que partage tout produit de chiffrement E2E dans le navigateur : le serveur fournit le code de cette page, donc un serveur compromis pourrait servir une page modifiée. L’application de bureau, avec ses mises à jour signées, reste la voie la plus sûre ; l’espace web est là pour la commodité.

Sur votre machine

Les clés d’hôte SSH sont épinglées à la première utilisation (TOFU) dans ~/.termalin/known_hosts.
Votre compte termal.in prend en charge l’authentification à deux facteurs (TOTP avec codes de secours) et les passkeys — l’app de bureau peut se connecter via le navigateur, si bien que le mot de passe ne touche jamais l’app.
Les enregistrements stockent la sortie du terminal et des repères d’événements — jamais les frappes brutes. Un mot de passe saisi à une invite masquée (sudo et consorts) n’est jamais renvoyé à l’écran, donc il n’arrive jamais dans un enregistrement ; tout ce que le terminal affiche fait partie de la bande.
« Se souvenir du mot de passe maître » (facultatif, désactivé par défaut) est protégé par le trousseau de votre système — Windows DPAPI, le Keychain macOS ou le Secret Service Linux — lié à votre utilisateur du système.

Infrastructure

Le backend tourne dans Docker derrière Cloudflare, avec TLS 1.2+ (certificats Let’s Encrypt). La base de données n’est joignable que depuis le localhost de la machine — jamais exposée à l’internet — et les sauvegardes sont chiffrées. Nous collectons le moins possible : aucun SDK d’analytique, aucun traqueur publicitaire, et nous ne vendons pas vos données.

Conformité & feuille de route

Nous préférons vous dire exactement où nous en sommes plutôt que de laisser entendre plus que ce que nous avons fait :

Domaine	État
Coffres AES-256-GCM, PBKDF2-HMAC-SHA256, mises à jour signées Ed25519	Livré
Minimisation des données + suppression complète du compte et des données sur demande (posture RGPD)	Livré
Test d’intrusion indépendant par un tiers	Prévu avant la disponibilité générale (GA)
SOC 2	Sur la feuille de route — demandez-nous où ça en est

Signaler une vulnérabilité

Écrivez à security@termal.in (voir notre security.txt) en indiquant ce que vous avez trouvé, comment le reproduire et quel impact vous lui prêtez. Nous accusons réception sous 3 jours ouvrés et vous disons ce que nous avons décidé — y compris quand nous estimons que ce n’est pas un problème, et pourquoi.

Veuillez tester uniquement sur votre propre compte, vous arrêter une fois le problème démontré (pas d’exfiltration de données, pas de persistance, pas de déni de service, aucune donnée de tiers ni d’utilisateur), et nous laisser un délai raisonnable avant toute publication. Restez dans ces limites et nous ne vous poursuivrons pas pour autant.

Nous ne payons pas de primes de bug (bug bounties). Termalin est un petit projet sans revenus et il n’y a pas de budget de récompense ; nous préférons le dire d’emblée plutôt que de laisser quelqu’un y passer un week-end pour rien. Ce que nous offrons : un crédit dans les remerciements de notre security.txt sous le nom et le lien de votre choix, une référence écrite décrivant votre rapport, et une licence Pro pour quelques mois. Si la découverte est sérieuse, nous vous dirons aussi quand le correctif est déployé.

Remerciements

Merci aux chercheurs qui ont signalé des problèmes de façon responsable et nous ont aidés à rendre Termalin plus sûr :

MD Rabbi Hossain — durcissement de l’enregistrement des clients OAuth dans le flux d’autorisation MCP (sept. 2026).