Ce qui est chiffré

Badlen utilise deux clés, qui servent à des choses sans rapport entre elles. L’une chiffre trois colonnes de la base de données ; l’autre chiffre un fichier que vous avez téléchargé. Aucune ne peut remplacer l’autre.

La clé de l’instance

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

Elle chiffre exactement trois choses :

• Votre secret de double authentification, enregistré quand vous associez une application d’authentification, et déchiffré à chaque vérification de code.
• Vos clés de fournisseur, pour l’instant la clé Moralis, qui sert à retrouver les tokens détenus à une adresse de portefeuille.
• Le code d’ouverture de votre relais, si vous en avez choisi un. Le relais scelle la lettre sans vous : l’instance doit donc pouvoir le lire. Cela n’affaiblit rien : qui détient la base et le .env lit déjà vos comptes en clair.

Elle ne chiffre rien d’autre : si cette clé fuitait, seules ces trois informations seraient exposées.

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, enregistrées avec le compte auquel elles appartiennent : une adresse est publique par nature, 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, une opération à sens unique qui n’utilise pas de clé.

La phrase de passe d’export

La phrase de passe que vous saisissez au moment d’exporter chiffre le fichier téléchargé, et rien d’autre. La clé de chiffrement en est dérivée avec argon2id, avec 64 Mio de mémoire, trois passes et un sel nouveau pour chaque fichier. Le sel et ces paramètres sont enregistrés dans le fichier : il s’ouvre donc sur n’importe quelle instance Badlen, sans que vous ayez rien à noter.

Elle ne fait jamais intervenir SECRET_ENCRYPTION_KEY, et c’est voulu : une sauvegarde qui dépendrait d’une clé stockée dans un .env deviendrait illisible le jour où cette clé serait régénérée. Un export chiffré s’ouvre sur une machine qui n’a jamais connu l’instance d’origine, et les secrets qu’il contient sont rechiffrés avec la clé de l’instance qui le restaure.

C’est dans Exporter vos données que vous choisissez entre un fichier chiffré et un fichier en clair, et que vous voyez ce que contient chacun.

Danger

Si vous perdez la phrase de passe d’export, vous perdez ce fichier. Il n’existe aucun recours, et il ne peut pas en exister : pas de réinitialisation, pas de code de récupération, et l’instance qui a créé le fichier ne peut pas l’ouvrir non plus. Enregistrez la phrase dans votre gestionnaire de mots de passe dès que vous la saisissez.

Restaurer sous une autre clé

Un pg_dump contient la version chiffrée de ces trois colonnes, mais pas la clé : si vous le restaurez dans une instance qui utilise une autre clé, vous récupérez tous vos chiffres, mais aucune des trois informations chiffrées. Restaurer sous une autre clé traite ce cas en détail et explique comment s’en sortir. C’est pour cela qu’il faut conserver SECRET_ENCRYPTION_KEY avec le dump, mais à un autre endroit, et c’est pour cela qu’un export JSON chiffré par une phrase de passe n’a pas ce problème.