J’ai regardé la spec, et les exemples d’implémentation que vous avez fait avec @Poka avec flutter (cool !).
Même s’il s’agit d’un format standard, j’ai essayé de répondre aux questions suivantes (dites moi si je me trompe) :
Pour quel type d’utilisateur ? Tous les niveaux à priori.
Pour quel type de support ? Également tous les types ? du téléphone au PC
Pour quel compte ? Tous les types de comptes.
Or la question (bête sans doute) est de savoir s’il faut une seule et même stratégie « standard », quelque soit le cas d’utilisation.
Typiquement, si je suis dans ce cas de figure :
Cas n°1 : paiement mobile rapide
Utilisateurs : usagers non geek;
Support: téléphone;
Comptes : compte secondaire (juste pour les paiements rapide auprès de commerces, par exemple)
Si le besoin de l’utilisateur est de payer rapidement (par exemple, une baguette de pain), pensez vous que l’affichage d’un clavier alphanumérique (beaucoup de touches !) pour un code PIN à 6 caractères soit pratique ? facilement mémorisable ?
Dans ce cas, si on veut une bonne sécurité malgré tout, n’est pas plus simple un schéma de validation ?
Cas n°2 : opération délicate (certification et administration de noeud)
Utilisateurs : geek;
Support: PC;
Comptes : compte membre
L’utilisateur a t’il besoin d’un code PIN ? Quel son les cas d’usage connus qui s’y rapprochent ?
Ne faut il pas favoriser l’usage de sa passphrase directement ? ou bien d’un salt+password comme actuellement.
Mes questions ont simplement pour but de bien rester les pieds sur terre, et de ne pas faire des outils mal adaptés aux besoins réels, par exemple avec une sur-protection.
Oui c’est facilement mémorisable car l’alphabet ne fait que 35 caractères (insensible à la casse et pas de zéro). De toute façon on peut pas faire mieux après ça deviens trop facile à brute-forcer.
Qu’entent tu pars «schéma de validation» ?
L’utilisateur peut tout à fait utiliser son mnemonic directement. Le (code pin + fichier DEWIF) n’est là que pour le confort de l’usagé.
Pour un compte membre, le code pin doit être plus long (au moins 10 caractères au lieu de 6). Il reste en tous les cas possible d’utiliser son mnemonic directement.
C’est une pratique dangereuse en termes de sécurité, le salt en entrée de scrypt ne doit pas être une saisie de l’utilisateur, quel que soit le cas d’usage.
Et pour un geek, saisir une seule passphrase (le mnemnonic) reste plus simple et plus efficient que de devoir saisir un couple de 2 données.
Aucune crypto-monnaie ne propose de saisir un couple (salt+password ) comme vous le faites, ça ne sert à rien, c’est plus chiant pour l’utilisateur et moins sécurisé. Svp abandonnez cette pratique qui nr’a aucun sens, merci.
Justement le but de ses spec est de revenir les pieds sur terre en s’appuyant sur les nombreuses années d’expériences concrètes des crypto-monnaies massivement utilisées par des millions de gens tous les jours.
Ces autres cryptos ont dèjà été confrontées aux mêmes problèmes que nous et des milliers d’ingénieurs compétents ont réfléchi pendant des années à comment rendre ces monnaies simples d’usages ET fiables.
Il serait grand temps de sortir de notre otarcisme et de nous baser sur leur expérience, permettant de rendre l’usage d’une crypto accessible à tous (même Nabilla arrive à utiliser le BTC), tout en gardant une sécurité élevée (essentiel pour la confiance en la monnaie).
Je ne sais pas comment tu gères tes connexions ssh mais personnellement j’ai abandonné l’identification par mot de passe depuis un moment et je passe par une clé générée pour chaque machine et protégé par une passphrase. Cela me permet de retirer facilement l’accès à mon serveur pour une clé donnée si je pense que la machine a été corrompue et même si quelqu’un a accès a ma machine dans un moment d’inattention, il ne peut pas l’utiliser immédiatement sans passphrase.
J’avais publié un petit article de blog en avril :
@kimamila suite à notre discussion vocale d’hier :
Je suis d’accord que taper un code alphanumérique n’est pas le plus pratique. Le code pin peut tout à fait être remplacé par un schéma à dessiner, un hash d’une empreinte digitale, ou n’importe-quoi d’autres qui est une entropie suffisante pour que le trousseau ne soit pas trop simple à bruteforcer en cas de vol ou piratage de l’appareil de l’utilisateur.
J’ai proposé un code pin parce que @poka a parlé de code pin pour ğecko. Mais en vrai je m’en fous du code pin, ça peut être remplacé par autre chose.
Mais cette question de code pin ou autre ne concerne que la manière de générer le «mot de passe» de chiffrement du trousseau, ce qui n’est qu’une sous-partie périphérique de ma proposition, aisément interchangeable, se concentrer là-dessus c’est passer complètement à côté de l’essence de ma proposition, ce qui me donne le sentiment désagréable de ne pas avoir été compris du tout
L’essence de cette proposition c’est :
Que la seed du trousseau ne soit pas générée par des inputs utilisateurs.
Que l’utilisateur ne saisisse pas directement de quoi générer la seed mais de quoi déchiffrer son trousseau local.
Il y a deux cas d’attaque très différents à dissocier :
L’attaque en possédant uniquement la clé publique : le monde entier peut le faire, donc ça doit être extrêmement difficile.
L’ attaque en possédant la clé publique + le fichier trousseau chiffré : pour cela il faut dérober où pirater l’appareil de l’utilisateur, c’est déjà bien plus compliqué, et surtout ça rend impossible les attaques de masse non-ciblées (possibles dans le cas 1).
Donc l’avantage d’avoir un fichier trousseau chiffré c’est de pouvoir abaisser le niveau de sécurité nécessaire (=l’entropie) de ce que doit saisir l’utilisateur pour réaliser une opération.
Mais comme le fichier trousseau peut être perdu où détruit (panne de l’appareil, changement d’appareil et oubli de sauvegarder le fichier trousseau), il est nécessaire de fournir à l’utilisateur un moyen de recréer son fichier trousseau à partir de rien: c’est à cela que sert le mnemonic aléatoire. Ça peut être présenté comme une «phrase de sécurité» à noter sur papier lors de la création de son compte en précisant bien qu’elle ne servira qu’en cas de changement d’appareil.
Cette idée n’est pas de moi, je n’ai rien inventé, c’est déjà ce que font télégram et matrix par exemple
J’espère que maintenant tu comprends un peu mieux le pourquoi de ma proposition, et que tu comprends du coup que le code pin n’est pas la question, c’est un élément périphérique interchangeable par n’importe quoi d’autre.
Alors oui j’ai pensé aux schémas sur smartphone aussi. Mais en faite un schéma ce n’est qu’un code numérique derrière, en plus avec moins d’entropie q’un code numérique de même taille, car on ne peut générer que des chiffres voisin sur le quadrillage, et pas 2 fois les mêmes chiffres qui se suivent.
Je ne sais pas comment calculer l’entropie d’un schéma comme ça.
Après je parle des schéma présents nativement sur Android depuis quelques années, je ne sais pas si on peut imaginer d’autre forme de schéma avec plus d’entropie, tout en restant facilement utilisable pour l’utilisateur.
Pour l’empreinte digital, oui je pense que pour les appareils qui le permettent, dans la mesure ou on peut générer un hash unique par empreinte, ça me semble une super idée.
Pour tout le reste, sur le fond de cette proposition, je trouve ça super.
Si on ne prend en compte que la contrainte que chaque point ne peut être utilisé qu’une fois, on arrive vers 400 000 possibilités (9!+8!+7!..) (pour un schéma à 9 points). En ajoutant la contrainte des voisins ça fera beaucoup moins…
C’est de l’ordre d’un code à 4 ou 5 chiffres décimaux je dirais.
Il y a également un moyen d’abaisser le niveau d’entropie nécessaire de l’input servant à déchiffrer le fichier trousseau :
Augmenter fortement la valeur des paramètres de scrypt dans la convention DEWIF.
Inconvénient: cela nécessite plus de mémoire pour dériver la seed DEWIF, donc ça peut exclure des vieux téléphones.
la mémoire vive à allouer pour scrypt vaut : (N+1) * r * 128
Donc avec les paramètres actuels (N=4096, r= 16) il faut environ 8Mo de mémoire. Jusqu’à quelle valeur peut t’on monter pour que cela n’exclue pas les vieux téléphones ? 64 Mo ? 256 Mo ? plus encore ?
Par exemple avec des paramètres de scrypt induisant un temps de dérivation 100 fois plus long, on pourrait se contenter d’un code pin à 7 chiffres.
Mais cela aurait 2 inconvénients:
Le temps d’exécution de scrypt passerait de 20ms à 2 secondes, une latence acceptable mais que l’utilisateur sentira.
L’appareil de l’utilisateur devrait avoir beaucoup de mémoire vive disponible.
EDIT:
après quelque test j’arrive à rallonger 60 fois le temps d’exécution de scrypt en passant N de 2^12 à 2^18 (soit de 4096 à 262144).
ce qui nécessite 538Mo de mémoire vive disponible (dans un segment continu) au lieu de 8 Mo, j’ai peur que ce soit trop demander pour des vieux téléphones.
Nous en avons parlé lors de la visio, mais j’écris ici mes réponses pour les lecteurs :
Mon avis est qu’il ne faut pas seulement regarder les usages des autres crypto, qui généralement (sauf à ce qu’on me montre le contraire) ont des usages de spéculations, loin du cas d’usage n°1, dans l’économie réelle, avec des petits achats de tous les jours.
Pourquoi vouloir utiliser les même outils, lorsqu’on achète une voiture ou que l’on effectue un gros placement, c’est à dire une opération importante, que lorsqu’on achète du cagot de pommes ou une baguette ? A chaque usage, ses outils. Vouloir imposer une sécurité maximale pour tous les usages n’a pas de sens pour moi. En fonction du cas, il faut voir les contraintes et les avantages. Faire la balance, entre pratique (rapide, etc) et sécurité.
Si on regarde du côté des App de crypto pour smartphone, 90% passe par un tiers de confiance : on crée un compte quelque part (eToro, Coimama, etc) et ont trade ensuite la monnaie : aucune clef de chiffrement n’est en locale.
Les quelques App de crypto qui créent une keypair sont une horreur en terme d’usage : difficile à mettre en toute les mains, et souvent même la récupération de la keypair (par QRcode, etc) ne fonctionne pas bien sur une autre terminal. Mais j’avoue que ma recherche date de 2 ans : ca a du évolué un peu (mais pas sûr). Même sur le bitcoin, ce n’etait pas du tout au point !
En revanche, notre cas d’usage est proche des paiements bancaires par carte ou téléphone (par NFC, etc.) : le vendeur et l’acheteur sont l’un en face de l’autre.
Dans ce genre d’application (qui passe évidemment par un tiers de confiance, et sans clefs) l’utilisateur à l’habitude d’avoir, soit un code pin, un schéma ou une empreinte. Dans tous les cas, l’opération doit être rapide à valider. C’est le critère essentiel d’adoption, à mon avis. C’est ce qu’il nous manque aujourd’hui : un outil de paiement rapide et fiable pour le vendeur. La sécurité du compte acheteur peut être protégé simplement par un compte secondaire, remplit régulièrement, comme on recharge un compte chèque UNL, un compte joint, un compte épargne, etc.
Du parles donc du cas n°1 “paiement mobile rapide” ?
On n’est donc d’accord.
A savoir que les OS de smartphones intègrent tous des mécanismes d’authentification, avec possibilité de reset de la BDD d’une App si trop d’erreur. A savoir aussi qu’une BDD d’App peut-être elle même chiffrée par le système.
Une App peut aussi détecter un écran de verrouillage existe sur le téléphone, et décider de s’appuyer dessus pour à tout moment redemander une authentification. J’ai notamment testé (via apache Cordova) cela avec l’empreinte digitale (comme le font les App bancaire) et ca fonctionne bien.
Pas de soucis, dans ce cas il faut juste retirer cette partie, ou plus simplement renommer le post.
A l’heure actuelle, on pourrait comprendre que tous les clients doivent appliquer cela, sinon gare à eux !
De mon côté, je dis et redis qu’il faut travailler en cas d’utilisation, et ne pas chercher à être 100% secure suivant les cas. il faut vraiment, je penses, distinguer les usages sur smartphone.
Et c’est ce que je fais. Les «phrase de sécurité» / «mnemonic» sons utilisés aussi par des applications qui n’ont rien à voir avec les crypto-monnaies. Je t’ai cité les messageries Télégram et Matrix.
Il y a des milliers de crypto-monnaies différentes, il ne faut pas généraliser. Et même pour les plus connus comme Bitcoin où Ether, il y a des millions d’utilisateurs différents tous avec des motivations et des usages différents.
Voir que les spéculateurs est une vision réductrice fausse, il y a des gens sincères qui souhaitent utiliser le bitcoin pour des achats du quotidien dans l’économie réelle :
Bon à titre perso ça ne m’intéresse pas car il n’y a pas d’égalité fasse à la création monétaire, quand je rencontre des gens comme ça je leur recommande d’utiliser plutôt la Ğ1
Et les spéculateurs ne sont pas inutiles, je dirai même qu’il en manque dans l’économie Ğ1, et que leur présence permettrait d’homogénéiser le marché :
Parce que nous somme une crypto-monnaie aussi, et que beaucoup de problématiques techniques nous sont communes. Le protocole DUBP en particulier, et Duniter en général, s’inspire fortement du bitcoin sur beaucoup d’aspect.
Je ne dis pas de faire comme eux, mais de prendre ce qu’il y a de bon à prendre, et les mnemonic me semble faire partie de ce qu’il y a de bon à prendre.
En fait on ne parle pas de la même chose. Toi tu parles du moyen de paiement, qui doit évidemment être adapté à la nature de la transaction.
Moi je parle de la méthode de génération d’un portefeuille, portefeuille qui peut servir pour tout type d’opérations.
Je suis totalement d’accord. Et ce que je propose va déjà dans le sens d’une sécurité minimale pour chaque usage justement.
Si je voulais imposer une sécurité maximale, ce serait hardware wallet obligatoire pour tout
Justement le fichier trousseau chiffré permet d’abaisser le niveau de sécurité nécessaire, ça va dans ton sens. Alors stp arrête de prétendre que je voudrais une sécurité maximale, où que je cherche la sur-sécurité, c’est totalement faux
Je pense que non, car nous somme dans un système décentralisé, alors que les paiements bancaires sont des systèmes centralisés. On peut bien sur s’inspirer de leur UX, pour rendre nos interfaces plus intuitives, mais pas de leur manière de sécuriser les transactions, qui nécessite un tiers de confiance.
D’accord, alors réfléchissons sereinement à la question : « Est-il possible de proposer une interface similaire avec une sécurité satisfaisante dans notre cas (décentralisé) ? ».
Je suis contre le principe selon lequel il faudrait compromettre la sécurité pour faciliter l’usage, je pense même que ce serait un tord d’opposer les deux.
Je pense qu’il est possible de concilier sécurité satisfaisante ET facilité d’usage, il nous faut juste y réfléchir sereinement et à fond, en jugeant les différents process pour ce qu’ils sont techniquement, et pas en fonction des sources d’inspiration.
Ce que le sous-entend par la, c’est qu’il n’y a pas a débattre de s’il faut de s’inspirer des autres crypto où non, des applis bancaires ou non. Pour moi c’est hors-sujet, ça nous fait perdre du temps et de l’énergie pour rien.
On peut s’inspirer de tout, ce qui compte ce n’est pas la source d’inspiration, mais la proposition en elle-même.
Il me semble également important de bien dissocier les sujets, qui posent des problèmes différents et qui doivent être traités différemment:
La génération du portefeuille.
L’utilisation du portefeuille dans le cadre d’un cas d’usage ou d’un autre.
Pour moi ce sont 2 sujets différents, et ma proposition sur ce post adresse le premier: comment générer un portefeuille de manière interopérable et sans faille de sécurité potentielle.
Tout à fait, mais beaucoup de gens désactivent ces mécanismes, et font en sorte que leur téléphone soit accessible sans authent.
Dans ce cas-là, l’app de paiement doit intégrer son propre mécanisme d’authentification.
Si le fichier trousseau peut être chiffré par le système directement, alors tant mieux ça me va.
Mais en cas de vol ou perte du téléphone, sans sauvegarde du trousseau, il faut que l’utilisateur est un moyen de recréer son trousseau (au moins pour récupérer sa monnaie). C’est à ça que sert le mnemonic aléatoire.
La partie à laquelle je tiens de plus c’est la partie Dupb-Mnemonic.
C’est la seule partie nécessaire pour l’interopérabilité.
Ensuite, pour la manière de stoker le trousseau sur l’appareil, j’ai proposé DEWIF pour proposer quelque-chose. Ça peut sans problème être autre chose, un chiffrement directement pas le système du téléphone, pourquoi pas.
Quelqu’un qui voudrait utiliser un même compte sur plusieurs clients, aurait alors à saisir une seule fois sur mnemonic sur chaque client, puis chaque client stockerait le trousseau ainsi généré comme bon lui semble.
Cela je l’ai déjà précisé dès le début il y a 1 mois:
Mais je ne comprends pas, le système peut très bien chiffrer un fichier oui, mais avec l’aide d’une phrase de chiffrement quoi, qu’il faudra rentrer pour déchiffrer ce fichier quoi. Je ne comprends pas la différence avec DEWIF + PIN ?
Avec ce package par exemple je peux chiffrer un trousseau PubSec avec une clé de chiffrement, qui peut être définit par le user et qui devra être retappé par le user à chaque fois qu’il veux utiliser son wallet …
Comment le système pourrait-il chiffrer/déchiffrer sans stocker de clé de chiffrement en claire ni demander de clé de chiffrement au user pour le déchiffrement ?
Concernant le format DEWIF en particulier, je pense modifier les paramètres de scrypt pour multiplier par 10 le temps d’exécution, ce qui multiplie par 8 la RAM nécessaire.
Soit 64Mo au lieu de 8Mo, je pense que ce n’est pas trop excluant, même pour des vieux téléphones.
Le changement se ferait sur le paramètre N que je propose de passer de 2^12 à 2^15 (soit 32768 au lieu de 4096).
Cela permettrait de diviser par 10 l’entropie du code pin (de 10^9 à 10^8) en gardant le même niveau de sécurité.
On pourrait alors remplacer le code pin alphanumérique à 6 caractères par 2 codes pin numériques à 4 chiffres. Comme 2 codes secret de CB.
Ainsi on aurait besoin uniquement d’un clavier avec les 10 chiffres, c’est donc plus simple et plus rapide à saisir.
Qu’en pensez-vous ?
Qu’avoir 2 code PIN c’est trop bizarre, je pense qu’un code alphanumérique 6 caractères est plus simple mémoriser que de codes PIN numériques à 4 chiffres chacun.
Pourquoi ne pas dire un code PIN numérique de 8 caractères ?
Le top serait un seul code PIN numérique à 6 chiffres
Ce qui ferait une entropie de 10^6, c’est trop faible.
Même avec un scrypt renforcé il ne faut que 10 000 secondes pour bruteforcer toutes les combinaisons sur un pc récent, sois seulement 27h47m, c’est trop peu.
Avec pour scrypt les param suivant : (N=32768, r=16, p=1). Soit 64 Mo de mémoire nécessaire.
Si on part du principe qu’un brute force ne doit pas pouvoir se faire en moins de 10 jours* de temps de calcul sur pc récent, alors l’entropie doit être au minimum de 10^7
Voici alors la longueur minimale nécessaire pour un code pin :
7 chiffres si code pin purement numérique
5 caractères si code pin alphanumérique avec alphabet de 35 caractères (insensible à la casse et retrait du zéro pour ne pas le confondre avec le O).
*10 jours n’étant un délai acceptable que pour un simple portefeuille avec montant modéré dessus. Pour un compte membre il faut bien plus.
Dans Gecko je peux mettre par defaut full numérique 7 chiffres, et dans les paramètres le user pourrait choisir de générer plutot des wallets 5 alphanumériques, voir d’autres possibilités.
Enfin dans la mesure où tu adaptes le binding dubp en amont pour générer différents types de PIN bien sûr lol
J’avais fait une erreur de calcul. J’ai ensuite refait les calculs plusieurs fois pour être sûr que je tombais toujours sur le même résultat, cette fois c’est bon
