# Différents niveaux de sécurité pour différentes dérivations
**URL:** https://forum.duniter.org/t/differents-niveaux-de-securite-pour-differentes-derivations/14031
**Category:** R&D
**Tags:** sécurité
**Created:** [17 September 2026 11:14 UTC](https://forum.duniter.org/t/differents-niveaux-de-securite-pour-differentes-derivations/14031 "2026-09-17T11:14:14Z")
**Posts on this page:** 13
**Page:** 1
### Author:  [@vit](https://forum.duniter.org/u/vit)
#### Post date: [17 September 2026 11:14 UTC](https://forum.duniter.org/t/differents-niveaux-de-securite-pour-differentes-derivations/14031/1 "2026-09-17T11:14:14Z")
> [@Proposition : un document qui spécifie les prérequis minimaux que doit remplir toute application qui permet de gérer un compte Ğ1](https://forum.duniter.org/t/proposition-un-document-qui-specifie-les-prerequis-minimaux-que-doit-remplir-toute-application-qui-permet-de-gerer-un-compte-g1/14013/1):
>
> - Le logiciel doit permettre d’exporter la phrase de récupération dans un format texte brut importable dans d’autres logiciels : les 12 mots à la suite, dans une chaîne UTF-8 normalisée, chacun séparé par un espace. Aucun numéro ni saut de ligne.
Stocker le mnémonique augmente la surface d’attaque. Si le PIN est compromis on accède au mnémonique et donc au compte racine et tous les comptes dérivés connus !
Dans Tikka j’ai fait le choix de ne pas stocker le mnémonique, mais la clef privée de chaque compte. Avec l’inconvénient de ne pas pouvoir fournir à l’utilisateur son mnémonique en cas de perte.
Et chaque compte avait son PIN au départ, ce qui était un enfer quand on gèrait plusieurs comptes dérivés. J’ai donc appliqué un seul PIN par compte racine (et le même PIN pour les dérivés d’un compte).
Cette facilité me fait revenir à la même surface d’attaque que si je stockais le mnémonique finalement.
Donc oui, je pourrais stocker le mnémonique comme ce que tu préconises.
Voilà, je partage mes réflexions tout haut. 😉
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [17 September 2026 13:34 UTC](https://forum.duniter.org/t/differents-niveaux-de-securite-pour-differentes-derivations/14031/2 "2026-09-17T13:34:26Z")
> [@vit](#):
>
> Stocker le mnémonique augmente la surface d’attaque. Si le PIN est compromis on accède au mnémonique et donc au compte racine et tous les comptes dérivés connus !
>
> Dans Tikka j’ai fait le choix de ne pas stocker le mnémonique, mais la clef privée de chaque compte. Avec l’inconvénient de ne pas pouvoir fournir à l’utilisateur son mnémonique en cas de perte.
Je n’avais pas remarqué ça sur Tikka jusqu’à ce que tu le mentionne.
Et j’avoue, que à la réflexion, c’est plutôt malin.
Et j’ai l’impression que ça résous les préoccupations de @1000i100 qui commence à nous proposer que chaque user utilise [3 mnemonics différents en fonctions des usages](https://forum.duniter.org/t/proposition-un-document-qui-specifie-les-prerequis-minimaux-que-doit-remplir-toute-application-qui-permet-de-gerer-un-compte-g1/14013/17) …
Ton approche me semble plus sécurisé que celle de ~~Gecko~~ durt2, tout en laissant entrevoir, de loins pour le moment, une UX qui pourrait peut être, éventuellement, réconcilier séparation des stockages wallets par sécurité (ne pas déverouiller ce qui donne accès à ton wallet membre pour faire un virement de 10G1 pour ton soin chamanique hebdomadaire), mais en même temps me même mnemonique pour tout tes wallets et ne pas avoir à gérer 3 mnémoniques différents (enfer, warning, no way).
Dans ce cas là il faudrait alors séparer la responsabilisation de stockage/notage de mnemonic par le user en dehors de l’app wallet, soit dans un trousseau, soit un gestionnaire de mot de passe, soit un papier écris ou imprimé, proposé toujours au moment de la création du coffre, et vérifié lors de la confirmation d’identité.
On accepte alors que l’app ne permet plus d’afficher le mnemonic au user.
Mais je reste encore sceptique sur le côté pratique de la chose, comparé aux faibles gain en sécurité que ça apporterait.
Sujet à creuser, mais c’est intéressant.
* * *
Par contre en terme d’UX les gens veulent leur compte membre sur leur mobile pour pouvoir certifier et gérer leur adhésion, il faut voir ce qu’on peut imaginer pour garder un truc simple, fiable, et réellement pertinent si on remplace les coffres actuelles.
Sinon ça demande un wallet local qui détiens des autorisations spéciales de ton wallet membres, pour réduire les responsaibilités, mais là franchement, la gymnastique me semble un peu poussé pour le peu de gain sécuritaire que ça permet, donc vraiment il faut bien bien étaler les avantages et inconvénients de tout ça et surtout bien bien réfléchir aux UX possibles de bout en bout.
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [17 September 2026 14:24 UTC](https://forum.duniter.org/t/differents-niveaux-de-securite-pour-differentes-derivations/14031/3 "2026-09-17T14:24:45Z")
> [@Proposition : un document qui spécifie les prérequis minimaux que doit remplir toute application qui permet de gérer un compte Ğ1](https://forum.duniter.org/t/proposition-un-document-qui-specifie-les-prerequis-minimaux-que-doit-remplir-toute-application-qui-permet-de-gerer-un-compte-g1/14013/1):
>
> - Le logiciel doit permettre d’exporter la phrase de récupération dans un format texte brut importable dans d’autres logiciels : les 12 mots à la suite, dans une chaîne UTF-8 normalisée, chacun séparé par un espace. Aucun numéro ni saut de ligne.
> [@vit](#):
>
> Stocker le mnémonique augmente la surface d’attaque. Dans Tikka j’ai fait le choix de ne pas stocker le mnémonique, mais la clef privée de chaque compte.
@vit Stocker le mnémonique ou la clé privée d’un compte racine a exactement les mêmes implications en matière de sécurité. Dans les deux cas, cette donnée doit être chiffrée à l’aide d’un algorithme de chiffrement récent et robuste.
Dans tous les cas, l’application doit stocker des données secrètes donnant accès au compte. Autant donc stocker le mnémonique : je ne vois pas en quoi cela serait moins sécurisé que de stocker la clé privée du compte racine.
Le seul cas où cela fait une différence, c’est lorsque la donnée secrète stockée ne permet pas d’effectuer les dérivations. Dans ce cas, l’utilisateur doit ressaisir son mnémonique pour chaque nouvelle dérivation qu’il crée, ce qui me semble beaucoup trop contraignant pour rien.
Une application peut décider de fonctionner ainsi, mais cela n’a pas sa place dans la liste des prérequis minimaux que ce topic cherche à définir.
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [17 September 2026 15:56 UTC](https://forum.duniter.org/t/differents-niveaux-de-securite-pour-differentes-derivations/14031/4 "2026-09-17T15:56:59Z")
> [@elois](#):
>
> Stocker le mnémonique ou la clé privée d’un compte racine a exactement les mêmes implications en matière de sécurité.
Pas exactement, pour les raisons que vit a évoqué.
Si tu n’a qu’une clé privé d’une dérivation d’un de tes wallets de ton coffre, si ça leak, ça ne donne pas accès à toutes tes autres dérivations dérivés à partir d’un même mnemonic (coffre).
Ca change les perspective de sécurité étant donné que demander aux gens de noter/stocker quelque part 3 mnemonic pour des usages différents comme le propose 1000i100 pose d’autres soucis bien plus préoccupant pour moi.
Donc ça permet de garder un coffre (mnemonic) unique pour tout ses wallets, sans pour autant exposer toutes les clés privée sur chacun de ses appareils, et donc commencer à réfléchir à la répartition de tout ça, éventuellement.
---
### Author:  [@italpaola](https://forum.duniter.org/u/italpaola)
#### Post date: [17 September 2026 16:11 UTC](https://forum.duniter.org/t/differents-niveaux-de-securite-pour-differentes-derivations/14031/5 "2026-09-17T16:11:59Z")
> [@poka](#):
>
> demander aux gens de noter/stocker quelque part 3 mnemonic pour des usages différents comme le propose 1000i100 pose d’autres soucis bien plus préoccupant pour moi.
Je te rejoins : à mon humble avis trop compliqué pour l’utilisateur/trice lambda. Je pense que chaque utilisateurs/trice peut/doit être responsable de sa phrase de restauration (ne pas la divulguer n’importe comment) et pas _obligé_ d’en avoir 3
> [@Proposition : un document qui spécifie les prérequis minimaux que doit remplir toute application qui permet de gérer un compte Ğ1](https://forum.duniter.org/t/proposition-un-document-qui-specifie-les-prerequis-minimaux-que-doit-remplir-toute-application-qui-permet-de-gerer-un-compte-g1/14013/17):
>
> Une bonne manière de faire selon moi serait d’avoir :
>
> - un compte maitre / compte de haute sécurité (compte membre, compte principal d’une asso…) qui sert à recevoir des Ğ1, à certifier (pour un compte membre), et à déléguer des droits à des comptes moins privilégiés. Ce compte, on ne le dévérouille que rarement, et peu de logiciels ont besoin de pouvoir agir depuis se compte.
> - un/des compte courant approvisionné automatiquement jusqu’à un plafond par le compte de haute sécurité pour permettre les opérations courante sans avoir besoin de dévérouiller les secrets du compte maitre/compte de haute sécurité.
> - des comptes sociaux/spécialisé capable de prouver leur appartenance au proriétaire d’un compte de haute sécurité donné, mais dont le lien peut être révoqué sans révoquer l’identité maitre. Ainsi je peux laisser un avis vérifié sur un produit sur un site dont la confiance n’a pas besoin d’être maximale, car je n’ai jamais à saisir de phrase de récupération ni même de code de dévérouillage au quotidien. Les seul cas où je dois dévérouiller le compte maitre, c’est depuis l’app qui le gère, et seulement pour accorder des droits à un compte secondaire dont je dispose ou au compte d’une tierse personne (en le certifiant par exemple)
@1000i100 tout ca c’est pour un juniste lambda ?
---
### Author:  [@1000i100](https://forum.duniter.org/u/1000i100)
#### Post date: [17 September 2026 16:15 UTC](https://forum.duniter.org/t/differents-niveaux-de-securite-pour-differentes-derivations/14031/6 "2026-09-17T16:15:26Z")
> [@poka](#):
>
> Et j’ai l’impression que ça résous les préoccupations de @1000i100 qui commence à nous proposer que chaque user utilise [3 mnemonics différents en fonctions des usages](https://forum.duniter.org/t/proposition-un-document-qui-specifie-les-prerequis-minimaux-que-doit-remplir-toute-application-qui-permet-de-gerer-un-compte-g1/14013/17) …
> [@poka](#):
>
> ne pas avoir à gérer 3 mnémoniques différents (enfer, warning, no way).
Je ne commence pas, j’en avais déjà parlé avant la V2 et déjà au rml12 je parlais de compte avec plafond de paiement.
En revanche, ce que je préconise n’implique pas que le user gère 3 mnémonic, il peu rester sur 1 seul. ce que ça implique c’est que l’app ne dévérouille pas tout systématiquement.
En gros, quand tu ouvre l’app tu as certains porte feuille directement dévérouillé (qui peuvent être des dérivation dont l’app stock la seed hors coffre) d’autres qui sont à dévérouiller par empreinte/pin (là aussi l’app le stock chiffré mais sans besoin de dévérouiller le mnemonic/le compte maitre), et enfin le compte maitre qui ne se dévérouille pas à la biométrie mais seulement avec un pin (idélement pin légèrement plus long pour le distinguer clairement du pin/biométrie d’usage courant, genre 5 ou 6 pour le pin maitre, et 4 pour le courant).
De cette manière, avec le mnémonic on restaure tout d’un coup, mais à l’usage, on ne dévérouille qu’en fonction des enjeux (afficher les notif, c’est cool de pouvoir le faire sans effort, certifier, c’est important que ça reste un geste au quel on réfléchi, surtout quand on certifie quelqu’un pour la première fois).
> [@Proposition : un document qui spécifie les prérequis minimaux que doit remplir toute application qui permet de gérer un compte Ğ1](https://forum.duniter.org/t/proposition-un-document-qui-specifie-les-prerequis-minimaux-que-doit-remplir-toute-application-qui-permet-de-gerer-un-compte-g1/14013/24):
>
> @1000i100 tout ca c’est pour un juniste lambda ?
Oui, la complexité est à absorber par l’app, pas par l’utilisateur.
L’utilisateur n’a toujours qu’un mnemonic, qu’une adresse ou il reçois DU et virements (sauf s’il veux un compte séparé pour une activité pro ou associative), ce qui change c’est qu’il peut déléguer certaines choses à des comptes (qu’il n’a pas besoin de retenir, c’est le taf de l’app) qui pourront agir sans friction de dévérouillage, mais sans nécessité les plein pouvoir pour autant.
Un peu comme sur un pc, normalement on ne se connecte en root que quand il y en a besoin, pas en permanence, mais la plus part des utilisateur ne savent pas ce qu’est un compte root, juste certaines actions nécessite un mot de passe alors que lancer leur navigateur ou traitement ne texte ne nécessite pas une authentification à double facteur (heureusement).
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [17 September 2026 16:43 UTC](https://forum.duniter.org/t/differents-niveaux-de-securite-pour-differentes-derivations/14031/7 "2026-09-17T16:43:08Z")
> [@1000i100](#):
>
> En gros, quand tu ouvre l’app tu as certains porte feuille directement dévérouillé (qui peuvent être des dérivation dont l’app stock la seed hors coffre
D’accords, donc ça rejoins bien ce que j’explique vis à vis de ma réponse à TikkaVit.
Avec une nuance importante que tu apportes, le fais qu’en plus de stocker des private keys par wallets, garder le mnemonique aussi pour les comptes les plus sensibles (membre).
Le gain sécuritaire est donc déporté, amoindri aux simples attaques/écoutes intrusives pendant les quelques millisecondes où la privatekey/mnemonic passe en clair en RAM pendant la phase de signature.
RAM qui est protégé par le système.
Et concernant la biométrie, ce système est bien plus secure que n’importe quel code PIN.
Un autre avantage à ton approche est de permettre d’avoir plusieurs code/empreinte de chiffrement pour ses différents wallets d’un même coffre.
Hors, on passe alors dans une augmentation de la complexité UX pour l’utilisateur qu’il faut mesurer, donc l’app n’absorbe pas la complexité ici.
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [17 September 2026 17:13 UTC](https://forum.duniter.org/t/differents-niveaux-de-securite-pour-differentes-derivations/14031/8 "2026-09-17T17:13:15Z")
> [@Proposition : un document qui spécifie les prérequis minimaux que doit remplir toute application qui permet de gérer un compte Ğ1](https://forum.duniter.org/t/proposition-un-document-qui-specifie-les-prerequis-minimaux-que-doit-remplir-toute-application-qui-permet-de-gerer-un-compte-g1/14013/23):
>
> Pas exactement, pour les raisons que vit a évoqué.
> Si tu n’a qu’une clé privé d’une dérivation d’un de tes wallets de ton coffre, si ça leak, ça ne donne pas accès à toutes tes autres dérivations dérivés à partir d’un même mnemonic (coffre).
C’est exactement ce que j’ai dit, relis mon post:
> [@elois](#):
>
> Le seul cas où cela fait une différence, c’est lorsque la donnée secrète stockée ne permet pas d’effectuer les dérivations.
Ce cas me semble cependant impliquer trop de complexité pour l’utilisateur lambda et s’éloigner du sujet, qui est :
**Les prérequis minimaux que doit remplir une application Ğ1**
Pouvez-vous, s’il vous plaît, déplacer dans un autre topic les discussions liées à la gestion multi-compte et à la délégation de compte pour certaines tâches ?
C’est un sujet très intéressant et j’aurais des choses à dire dessus, mais cela ne doit pas faire partie des prérequis minimaux que l’on demande aux applications.
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [17 September 2026 17:18 UTC](https://forum.duniter.org/t/differents-niveaux-de-securite-pour-differentes-derivations/14031/9 "2026-09-17T17:18:59Z")
@elois excuse moi mais si on décide de ne finalement plus stocker les mnemoniques dans les app, ça change bien les prérequis minimaux que doit remplir une application Ğ1.
> [@Proposition : un document qui spécifie les prérequis minimaux que doit remplir toute application qui permet de gérer un compte Ğ1](https://forum.duniter.org/t/proposition-un-document-qui-specifie-les-prerequis-minimaux-que-doit-remplir-toute-application-qui-permet-de-gerer-un-compte-g1/14013/1):
>
> > - Le logiciel doit permettre d’exporter la phrase de récupération dans un format texte brut importable dans d’autres logiciels : les 12 mots à la suite, dans une chaîne UTF-8 normalisée, chacun séparé par un espace. Aucun numéro ni saut de ligne.
Donc une partie de ce sujet à sa place ici, on est quand même là pour débattre, pas pour boire des pré-requis sans les discuter.
Mais oui ça mérite aussi un sujet dédié.
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [17 September 2026 17:23 UTC](https://forum.duniter.org/t/differents-niveaux-de-securite-pour-differentes-derivations/14031/10 "2026-09-17T17:23:41Z")
> [@poka](#):
>
> @elois excuse moi mais si on décide de ne finalement plus stocker les mnemoniques dans les app, ça change bien les prérequis minimaux que doit remplir une application Ğ1.
Bah non. Dans les prérequis minimaux, il n’est pas nécessaire de stocker le mnemonic:
> - Le logiciel doit permettre d’exporter la phrase de récupération dans un format texte brut importable dans d’autres logiciels : les 12 mots à la suite, dans une chaîne UTF-8 normalisée, chacun séparé par un espace. Aucun numéro ni saut de ligne.
Les règles sont à interpréter au sens strict et minimal, comme en droit pénal. Donc, si une application ne permet un export conforme du mnemonic que lors de la création du compte, alors l’application est bien conforme, à condition que cet export soit forcé avant la suppression du mnemonic, afin de s’assurer que l’utilisateur l’a bien récupéré.
Vu que ça ne semble pas clair, je vais mettre à jour le premier post pour repréciser ce point.
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [17 September 2026 17:28 UTC](https://forum.duniter.org/t/differents-niveaux-de-securite-pour-differentes-derivations/14031/11 "2026-09-17T17:28:04Z")
> [@elois](#):
>
> permet un export conforme du mnemonic que lors de la création du compte
Ah oui alors ce ne sont plus les mêmes specs, si tu corriges je veux bien.
Auquel cas on peut tout déplacer dans un nouveau topic. Ce sujet n’a plus d’incidence sur les specs.
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [17 September 2026 17:31 UTC](https://forum.duniter.org/t/differents-niveaux-de-securite-pour-differentes-derivations/14031/12 "2026-09-17T17:31:29Z")
> [@poka](#):
>
> si tu corriges je veux bien.
C’est corrigé, voici la nouvelle formulation:
> - Le logiciel doit permettre d’exporter la phrase de récupération dans un format texte brut importable dans d’autres logiciels : les 12 mots à la suite, dans une chaîne UTF-8 normalisée, chacun séparé par un espace. Aucun numéro ni saut de ligne. Si le logiciel ne conserve pas la phrase de restauration, l’export n’est obligatoire que lors de la création du compte. L’application doit alors s’assurer que l’export a bien été effectué par l’utilisateur avant de supprimer toute trace de la phrase de restauration.
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [19 September 2026 15:03 UTC](https://forum.duniter.org/t/differents-niveaux-de-securite-pour-differentes-derivations/14031/13 "2026-09-19T15:03:16Z")
Je me suis permis de déplacer cette section de la conversation parce que c’est un sujet spécifique encore en élaboration. L’idée des prérequis minimaux c’est qu’on se mette d’accord sans trop tergiverser de ce qui est **le minimum** quitte à le revoir à la hausse plus tard. Donc gardons un minimum minimal et continuons les discussions de sécurité dans des fils adaptés.