Aller au contenu

Ce qui est chiffré

Il existe deux clés dans Badlen et elles font des travaux sans rapport. L’une scelle deux colonnes de la base de données ; l’autre scelle un fichier que vous avez téléchargé. Aucune ne peut tenir la place de l’autre.

SECRET_ENCRYPTION_KEY vit dans votre .env et nulle part ailleurs. Elle fait 32 octets, en base64, et l’instance refuse de démarrer sans elle. Tout ce qu’elle chiffre l’est en AES-256-GCM, au repos, dans la base de données.

Elle scelle exactement deux choses :

  • Votre secret de double authentification, écrit quand vous enrôlez une application d’authentification et rouvert à chaque vérification de code.
  • Vos clés de fournisseur, aujourd’hui la clé Moralis, qui sert à trouver les tokens détenus à une adresse de portefeuille.

Cette liste est exhaustive, et c’est aussi la réponse à ce qu’une clé fuitée exposerait.

Tout le reste est stocké en clair : vos comptes, vos soldes, vos opérations, vos lignes, vos lots, les cours, les points quotidiens de patrimoine net, les catégories, les règles, les préférences et les succès. Vos adresses de portefeuille aussi, qui voyagent avec le compte auquel elles appartiennent : une adresse est publique par construction et la synchronisation du portefeuille la lit à chaque passage. Votre mot de passe n’est ni en clair ni chiffré : il est haché avec argon2id, qui va dans un seul sens et n’a pas de clé.

La phrase de passe que vous tapez au moment d’exporter scelle le fichier téléchargé lui-même, et ne sert à rien d’autre. La clé en est dérivée avec argon2id, sur 64 Mio de mémoire, trois passes et un sel neuf par fichier. Le sel et ces paramètres voyagent à l’intérieur du fichier, de sorte qu’il s’ouvre sur n’importe quel Badlen sans que vous ayez rien à noter.

Elle ne touche jamais à SECRET_ENCRYPTION_KEY. C’est bien là l’intention : une sauvegarde dont la lisibilité dépendrait d’une clé posée dans un .env cesserait de s’ouvrir le jour où cette clé serait régénérée. Un export scellé s’ouvre sur une machine qui n’a jamais vu l’instance d’origine, et les secrets qu’il porte sont rechiffrés sous la clé de l’instance qui restaure.

Exporter vos données est l’endroit où vous choisissez entre un fichier scellé et un fichier clair, et ce que chacun emporte.

Un pg_dump emporte le chiffré de ces deux colonnes et rien de la clé, de sorte qu’une restauration dans une instance qui en porte une autre rend tous les chiffres et aucune des deux choses scellées. Restaurer sous une autre clé couvre ce cas en entier et la façon d’en sortir. C’est pourquoi SECRET_ENCRYPTION_KEY a sa place à côté du dump, dans un autre endroit, et pourquoi un export JSON scellé par une phrase de passe n’a rien de ce problème.

Confidentialité