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.
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.
@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.
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.
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
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).
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).
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.
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.
@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.
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.
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.
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.
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.
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.
