Aller au contenu

Restaurer sous une autre clé

Un pg_dump contient la version chiffrée des trois colonnes protégées, mais pas la clé : celle-ci se trouve dans votre .env, et nulle part ailleurs. Si vous restaurez le dump dans une instance dont le .env contient une autre clé, la restauration ne fonctionne donc qu’à moitié, et mieux vaut savoir à l’avance laquelle.

Tous vos chiffres reviennent intacts, puisqu’aucun n’a jamais été chiffré : comptes, soldes, opérations, lignes, cours, points d’historique, catégories, succès. Votre mot de passe aussi : vous vous connectez normalement. Ce qui ne revient pas, ce sont les trois informations chiffrées avec la clé disparue.

La ligne est bien là, avec ses quatre derniers caractères en clair, mais la valeur est illisible. Réglages → Accès signale une telle clé comme illisible au lieu de configurée, et vous invite à la coller de nouveau ; une synchronisation de portefeuille échoue avec la même phrase, sans mettre en cause le fournisseur. Supprimez la ligne, collez la clé, et le problème est réglé.

Sur un compte où la 2FA est active, l’application d’authentification ne permet plus de se connecter : le code est juste, mais le secret auquel il faut le comparer ne peut pas être déchiffré. La réponse est donc Code requis, la même que pour un champ vide.

Il ne reste qu’un moyen d’entrer : l’un des codes de récupération affichés à l’activation de la 2FA.

Chaque connexion consomme un code de récupération : une fois connecté, désactivez donc la 2FA. Réglages → Sécurité indique que le secret enregistré est illisible et vous demande votre mot de passe au lieu d’un code, puisque plus aucun code ne peut être vérifié. Confirmez, et le second facteur est désactivé ; le secret illisible et les codes de récupération restants sont supprimés avec lui. Vous vous connectez ensuite avec votre seul mot de passe, et vous pouvez réactiver la 2FA quand vous voulez : un nouveau secret est alors créé, chiffré avec la clé qu’utilise réellement cette instance.

Seul ce compte est concerné, et seulement tant que son secret reste illisible : dans tous les autres cas, il faut toujours un code pour désactiver la 2FA.

Si vous préférez garder le second facteur tel quel, générez une nouvelle série de codes de récupération depuis le même écran avant d’épuiser la vôtre. Là non plus, aucun code n’est demandé : la session ouverte suffit.

Un relais réglé avec un code d’ouverture continue de tourner, mais le code avec lequel il scellerait la lettre ne se lit plus. Réglages → Transmission le dit sur la carte du relais. Papier du code, avec votre mot de passe, en tire un nouveau ; imprimez-le et remettez-le : l’ancien papier n’ouvre plus rien. D’ici là, la nuit où la lettre doit partir, l’envoi échoue et recommence la nuit suivante, ce que montre le journal de la carte.

Perdre la clé vous coûte vos clés de fournisseur, un nouveau code pour un relais qui en avait un, et un passage par la 2FA pour les comptes qui l’avaient activée. Aucun chiffre n’est perdu.

Un export JSON protégé par une phrase de passe n’a pas ce problème. Ses secrets sont rechiffrés avec la clé de l’instance qui le restaure : c’est pourquoi une sauvegarde chiffrée s’ouvre sur une machine qui n’a jamais connu l’ancienne.