Proposition d’identités forgerons − solution user-friendly au problème de sécurité des instances cesium web

Ce thread propose une solution au problème de sécurité évoqué ici : Mettez-vous vos identifiants membre dans une instance hébergée de Césium ? - Communication - Forum Monnaie Libre

La présente proposition implique une modification du protocole DUP, c’est pourquoi je la poste ici.

L’idée est de préserver une simplicité d’usage pour les utilisateurs finaux tout en garantissant la sécurité : les utilisateurs finaux pourront toujours se connecter directement avec leur compte membre sur une instance Cesium hébergée, mais cela ne posera plus aucun problème de sécurité pour la monnaie.

Rappel important :

Ce n’est pas à la commune de vous prémunir d’un cambriolage chez vous, mais la commune va vous garantir le fonctionnement des réseaux d’eau, le nettoyage de la voirie, etc… De la même façon, nous cherchons ici à garantir collectivement le bon fonctionnement de notre monnaie et du réseau informatique qui la porte, et c’est tout !

→ L’utilisateur final se connectant a son compte membre sur une instance Cesium hébergée s’exposera donc toujours au mêmes risques pour lui-même (mais cela n’exposera plus la monnaie).

Changements dans la user story de création d’un compte membre

Dans la dernière étape de la phase de création du compte membre (juste avant la validation finale), ajout d’une case a cocher (décochée par défaut), avec le texte suivant : “Compte membre calculant. (Compte restreint, ne cliquez que si vous savez ce que vous faites !)”.

les mots “membre calculant” seraient un lien qui ouvre une popup (ou pointe sur une page web) qui aura pour titre “Qu’est que qu’un membre calculant ?” et qui expliquerai les restrictions d’usages que cela inclus (la restriction : impossible de se connecter a un compte membre calculant sur Cesium web).

L’objectif de cette user story est que le néophyte soit incité a ne pas cocher cette case.
Généralement un membre ne vas pas se mettre a calculer des blocks alors qu’il rentre a peine dans la toile (a l’exception des informaticiens), donc c’est pertinent.
Si le membre en question souhaite au bout d’un certain temps, devenir membre calculant, il devra révoquer son compte membre et en créer un nouveau et cochant la case “membre calculant”, cela créer une barrière a l’entrée qui permet de s’assurer que :

  1. Le membre est capable de révoquer un compte (il saura donc révoquer son compte membre si celui ci est compromis un jour).
  2. Le membre a pris le temps de se renseigner avant de faire ça (on n’a pas envie de perdre toutes ses certif, le fait que ça ai un coût fait qu’on ne vas le faire que si on estime que ça en vaut la peine). Ça va éviter les membres qui installent Duniter comme ça et laissent tourner s’en sent soucier et qui ne savent pas le configurer (des fois ça marche sans aucune config sous windows). Ce qui sécurisera davantage le réseau car ce type de membres calculants “inconscients” ne suivent pas les mises a jours de sécurité.

Enfin l’identité de membre calculant ainsi créer devra recevoir au moins sigPowQty certifications provenant de membres eux-mêmes calculants pour devenir membre (sigPowQty a déterminer entre 1 et 5 compris).

Changements dans le protocole DUBP

  1. Ajout d’un champ dans le document identité indiquant si l’identité est “calculante” ou pas (un booléen).
  2. Ajout d’un paramètre sigPowQty (ou autre nom) indiquant le nombre minimal de certifications provenant d’identité calculante qu’il faut avoir a tout moment (comprendre “a tout block”) → comportement identique a sigQty.

Et c’est tout. Il ne sera pas possible de modifier le caractère calculant ou non d’un compte. Ça réduit les changements de protocole a faire tout en fournissant plus de sécurité.

Pourquoi sigPowQty ?

Parce que sans ça, la monnaie est toujours exposée a un risque conséquent si de nombreuses clés privés sont dérobés suite a un piratage d’une instance Cesium hébergée. Certes ses clés privés correspondront exclusivement a des membres non-calculants, mais avec ces nombreuses clés les pirates pourront créer des faux comptes calculant et prendre le contrôle total de la blockchain s’ils dépassent les deux tiers des membres calculants.

Avec sigPowQty, les faux comptes ainsi créer ne peuvent pas devenir calculants, or la proportion de membres calculants a vocation a être faible en cas de passage a l’échelle (moins de 1%), donc la quantité de faux compte créer sera la plupart du temps importante fasse au nombre de membres calculants mais négligeable face au nombres total de membres N.

Un exemple :
Supposons qu’on ai 100 membres calculant pour 10_000 membres. Il suffit de créer 70 faux comptes pour prendre le contrôle de la blockchain, par contre pour fausser le DU il faudrait créer beaucoup plus de faux comptes, l’impact de ses 70 faux comptes étant de moins de 1% sur N, le DU serait impacté de moins de 1 centime, donc c’est négligeable.

Tout ça pour dire que la prise de contrôle de la blockchain par majorité de faux compte calculant est une attaque infiniment plus dangereuse que de fausser le DU ou/et diminuer la confiance de la toile par des attaques sybil. Donc nous devons concentrer nos efforts en premier lieu sur cette 1ère attaque, d’où ma proposition.

NB: les informaticiens qui rejoignent le projet et qui sont bien sensibiliser aux problématiques de sécurité avant de devenir membre de la Ğ1 peuvent très bien créer une identité calculante dés la 1ère fois, il ne pourront juste jamais ce connecter sur leur compte membre via Cesium hébergé, m’enfin les informaticiens sont aussi ceux qui ont le plus de facilité a installer Cesium en local ou utiliser un client lourd comme Sakia ou Silkaj.

L’idée est de ne pas complexifier l’usage de la Ğ1 pour les simples utilisateurs, il y aura toujours des gens pour qui installer Cesium en local restera une barrière d’accès trop complexe, ce type de personne ne doivent de toute façon pas être en mesure de devenir membre calculant, j’estime que cela nécessite un minimum d’aisance sur un ordinateur. En revanche, ce types de personnes doivent avoir le droit d’utiliser la Ğ1, et il y en a plus qu’on ne pourrais le penser, j’ai encore eu le cas au dernier apéro de Montpellier mercredi, une dame qui ne savais pas installer un programme, ça lui a déjà demander des efforts importants pour réussir a utiliser Cesium sur le web pour créer son compte, elle n’aura jamais de Cesium local, en ça sert a rien de lui installer a sa place si elle n’est pas capable de le mettre a jours elle même.


Vos avis ?

6 Likes

Transition en deux étapes pour la Ğ1

Étape 1 (temps t1) : Nouveau format de block (v11) acceptant les nouveaux formats d’identités ET les anciens. Les identités créer sous l’ancien format sont notées comme non-calculantes.
Les blocs peuvent toujours êtres calculés par tout les membres.

Étape 2 (temps t2) : Encore nouveau format de block (v12) qui n’accepte cette fois que les identités sous le nouveau format. Toutes les identités sous l’ancien format n’ont plus le droit de calculer des blocks.

Il faudrait un délai suffisant entre t1 et t2 (au moins 3 mois), car sur cette période tout les membres calculant actuels devrons révoquer leur compte membre pour un créer un nouveau sous le nouveau format.

Notez bien que les membres qui ne calculaient pas de blocs (donc la plupart des utilisateurs finaux), n’auront rien a faire.

Concernant la synchronisation, les implémentations du protocole DUPB doivent avoir en dur les timestamp t1 et t2 pour vérifier que :

Si medianTime < t1 alors block.version = 10
Si t1 < medianTime < t2 alors block.version = 11
Si medianTime > t2 alors block.version = 12

Puis il suffit d’appliquer en fonction du numéro de version, les règles correspondantes.

Pour des raisons de testabilité, je préférerai qu’on puisse appliquer cette transition d’abord sur une monnaie de test avec des temps t1’ et t2’ tel que t1’ < t2’ < t1 < t2
Je dit « une monnaie de test » car ça peut être g1-test ou une autre si on décidais de rebooter g1-test.

A noter que tout les logiciels clients doivent être prêt avant t2’.

2 Likes

Je trouve pertinent et sécurisant de protéger la blockchain du web mais Penses tu qu’il soit indispensable de faire révoquer les comptes membres d’aujourd’hui qui peuvent aller sur cesium web et certes calculer dans la blockchain aussi?
Leur poids dans l’equipe calculante n’est il pas mécaniquement décroissant vers zéro au fur et à mesure’ des nouveaux calculants restreints au cesium local?

En fait la question n’est pas là, c’est une question de simplicité des changements de protocole : le protocole est la partie la plus critique de Duniter, chaque augmentation de complexité est un coût énorme car outre le temps de dev pur il y a tout les temps de tests et stabilisation → et vue que l’on est très peu de dev sur le coeur avec très peu de temps dispo pour développer je propose l’implémentation la plus simple.

Dans l’absolu, gérer différemment les anciennes identités selon qu’elles avaient déjà écrit des blocs ou pas est possible, mais ça complique beaucoup le code de synchronisation notamment, qui doit vérifier la validité de tout l’historique.
Et en terme de performance, il faut vérifier tout l’historique de la blockchain pour déterminer une ancienne identité a le droit au calcul, c’est lourd. Et même pour le dev de cesium ça compliquerai les choses.

La on vas au plus simple et performant : après t2 toutes les anciennes identités ne peuvent plus calculer, point. Par contre ces anciennes identités pourront toujours ce connecter sur cesium web.

Tu ne sera pas obligé de révoquer ton compte membre. Tu peut le garder, il ne pourra juste plus calculer (dans l’hypothèse ou cette proposition était appliquée).

1 Like

Cette proposition me paraît très intéressante.

Remarques :

  • Appellation “Membre calculant” (“Computing member”) - ou “Membre participant”, ou “Membre contributeur” : ok pour moi.
  • Appellation "Membre utilisateur" (“User member”) ou "Membre standard" préférable à “Membre restreint”, car personne n’a envie d’être “restreint” en quoi que ce soit, même s’il ne sait pas ce que cela veut dire.
  • Les responsabilités des “membres calculant” sont clairement définies et leurs contraintes de sécurité ne polluent pas le confort d’utilisation des “membres utilisateurs”. Ok pour moi.

[EDIT]
Le paragraphe suivant a été écrit au saut du lit et son auteur n’a pas bien compris la proposition.
Voir plus loin
Ne pas lire à partir d’ici…:flushed:

Problème potentiel de sigPowQty < sigQty

Réfléchir au fait que cela crée deux toiles de confiance dont le nombre réduit des calculants implique d’avoir sigPowQty avec un montant plus faible pour éviter un effondrement. Mais si sigPowQty < sigQty alors on peut crier à l’injustice car un “membre calculant” peut acquérir le droit de créer de la monnaie plus facilement qu’un “membre utilisateur”.

Du coup cela peut inciter à cliquer sur “membre calculant” juste pour créer son DU avec moins de certifications.

Si on part du principe que pour des raisons d’égalité en nombre de certifications pour créer son DU sigPowQty = sigQty. Alors on peut se passer de sigPowQty.

Le protocole doit alors gérer les certifications ainsi :

  • Membre calculant -> Membre calculant : AUTORISE.
  • Membre utilisateur -> Membre utilisateur : AUTORISE.
  • Membre utilisateur -> Membre calculant : REFUSE.
  • Membre calculant -> Membre utilisateur : AUTORISE ?.

Lire à partir de là… :wink:

Réflexion sur sigPowQty < sigQty

Réfléchir au fait que cela crée deux toiles de confiance dont le nombre réduit des calculants implique d’avoir sigPowQty avec un montant plus faible pour éviter un effondrement.

Le protocole doit alors gérer les certifications ainsi :

  • Membre calculant -> Membre calculant : AUTORISE.
  • Membre utilisateur -> Membre utilisateur : AUTORISE.
  • Membre utilisateur -> Membre calculant : AUTORISE.
  • Membre calculant -> Membre utilisateur : AUTORISE.

Si je me créé un nouveau compte “Membre calculant”
Je deviens membre créateur de DU (“utilisateur”) avec des certifications de Membres utilisateurs.
Je deviens membre calculant avec des certifications d’autres membres calculant.
Cela signifie que je dois d’abord devenir “membre utilisateur”, avant de pouvoir certifier en tant que calculant. Je peux le devenir avec des certifications d’autres membres utilisateurs.
Bon je cherche une faille potentielle, mais là tout de suite à chaud je ne vois pas, je m’embrouille… Faudrait simuler…

En fait non, on a toujours une seule toile de confiance et un seul type de certification, une seule règle de distance appliquée a tout les noeuds, etc.

On rajoute juste une 2ème propriété aux nœuds du graphe, il avaient déjà la propriété “référent” ou non, ils ont désormais la propriété “calculant” ou “non-calculant”( on peut changer le nom par “membre standard”, “membre classqiue”, “membre utilisateur”, etc).

Arf, tu n’a pas compris ma proposition :sweat_smile:

Non ce ne sera pas possible car toutes les règles existantes de la toile s’appliqueront toujours aux membres calculants, ainsi une identité calculante devra quand même recevoir sigQty certifications.
Le paramètre sigPowQty ne remplace pas sigQty, il se rajoute, c’est une règle de plus, que seules les identités calculantes doivent satisfaire.

Non non, il n’y a pas de DU “utilisateur”, il y a un seul et même DU pour tout les membres, qu’ils soient calculants ou non.
De plus il n’y a pas de transition : Si tu créer une identité calculante elle passera directement en membre calculant ou ne deviendra jamais membre, point. Il n’y a pas de statut intermédiaire.
Tu infère un paquet de règles qui n’existent pas, cantonne toi aux règles que j’ai explicitement énoncé, il n’y en a pas d’autres :slight_smile:

1 Like

Si ces informaticiens veulent quand même se connecter depuis LEUR instance cesium web, rien ne les empêche de modifier césium web pour y ajouter une liste blanche de comptes calculant autorisés, qui ne devrait en général pas dépasser un compte : le leur.

Une chose me dérange avec la révocation comme méthode de transition : les uid ne sont pas transférable à une nouvelle identité (ni libéré par la révocation).

Pour la conversion auto, je présume que le problème est l’imutabilité des documents d’identité une fois inscrit en blockchain ?
Quid d’autoriser :
Du bloc X au bloc Y (entre T1 et T2) les identités existante à publier un nouveau document d’identité sous le même uid et même clef publique/privée mais au nouveau format, pour pouvoir préciser “membre calculant” sans y perdre son uid ni avoir à se faire re-certifier. Passé T2, ce n’est plus possible.

ça me semble faciliter la transition.

PS : Un Membre calculant, qui finalement de fait pas tourner de noeud, ça me fait bizarre terminologiquement, il est considéré comme entrain de calculer (calculant) qu’il le face ou non, alors que cela signifie en réalité en capacité de calculer. Membre calculateur me semble anxiogène, propice à nourrir la paranoïa des complotistes, Membre forgeron me semble pas mal : Un forgeron à la capacité de forger, mais n’est pas forcément entrain de s’affairer à sa forge en permanence.

ça me perturbe beaucoup moins, mais Membre utilisateur j’ai l’impression de lire Membre qui est membre Je préfère Membre standard ou Membre classique ou simplement Membre.

2 Likes

Ce serait possible de créer une exception pour l’uid, mais ça complique le code de vérification pour qqch qui n’est franchement pas indispensable, les uid étant sensible a la casse tu peut reprendre le même en changeant juste la casse :wink:

En revanche pour les clef publique/privée il ne sera pas possible de reprendre les mêmes pour 2 raisons :

  1. La sécurité : certains membres calculants actuels se sont déà connecté sur un cesium web hébergé et leur compte, peut être compromis un jour dans l’avenir.

  2. Le code : tout est basé sur les clés publiques, devoir supporter la réutilisation d’une même clé publique pourrait causer de nombreuses régressions et obliger a refondre une bonne part du code du cœur, avec tout ce que ça implique derrière en temps de temps supplémentaire de stabilisation.

  3. Ce rituel de reboot me semble souhaitable et bénéfique, c’est une opportunité de passer a de meilleurs pratiques pour tout les membres calculants actuels dont les pratiques ne serait pas assez secure (et je suis sur qu’il y en a).
    Alors certes c’est des procédures pour rien pour les membres calculants dont les pratiques sont déjà très safe, mais l’effort que ça demande est bien inférieur a l’effort que demanderai en terme de code le fait d’éviter ça. De plus on y perdrais le bénéfice du reboot qui permet de repartir sur des bases saines et terme de sécurité.

Si l’on appliquais cette proposition, il y aurait 2 licences. La licence actuelle pour les comptes membres classiques, et une licence supplémentaire pour les comptes membres forgeron. Cette dernière expliciterai toutes les précautions de sécurités qui incombent a un membre forgeron. Ainsi les membres calculant actuels dont les pratiques ne sont pas assez safe et qui n’en avait peut être même pas conscience auront occasion de repartir sur des base saines, avec de nouveaux identifiants plus solides (ce qu’on perd si l’on oblige pas a changer de trousseau de clés).


Tes remarques sur les nom sont tout a fait pertinentes, mais des noms ça ce change facilement, l’important dans un premier temps c’est de se prononcer sur les choix techniques :slight_smile:

1 Like

du coup, j’aurais tendance à ne pas faire d’exception mais à, au choix :

  • libérer les uid des comptes révoqué plutôt que les garder réservé pour l’éternité
  • supprimer la notion d’uid si tout est rattaché à la clef publique (et rajouter plus tard une surcouche de nameService qui n’a pas besoin d’être dans le protocol monétaire)
  • coder le changement de mot de passe pour un compte membre (donc rattacher à l’uid les certif et émettre un document signé avec les anciens code indiquant la nouvelle clef publique à associer à l’uid/compte membre, ce document pourrait inclure le nouveau champ).

PS : si on veut une sécurité au top, voici les mesure que l’on pourrait demander aux membres forgerons :

  • générer ses nouveaux secret sur un hardware-wallet dont il est possible de faire des duplicata à la création mais plus ulterieurement. (et laisser le hardware wallet effectuer toutes les opérations de signature pour pouvoir l’implémenter de manière à ce que la clef privé ne puisse jamais en sortir) (mais cela introduit un frein UNL à l’entrée tant qu’il n’est pas possible d’achetter des hardware-wallet en Ǧ1
  • faire contre-signer une certification de membre forgeron destiné à un membre forgeron par un des membre forgeron ayant certifié le certifieur (ou au moins par un des certifieurs du forgeron signeur), l’idée étant de renforcer le contrôle/la vigilance sur le fait qu’il n’y ai pas de certification à la légère de membre forgeron.

Je serai pour en profiter pour faire du ménage dans la licence actuelle pour en faire une licence qui explicite les engagements de qui l’accepte et non un cours (même court) sur ce qu’est une monnaie libre.

Et je serai aussi pour qu’au lieu d’un accepter, il y ai pour chaque engagement une case à cocher pour s’assurer que tout ai été lu et accepté.

Et idem pour la licence forgeron mais avec plus d’engagements et donc de case à cocher.

C’est entre autre l’objet de cette conf :
https://rml12.duniter.io/session_licence_TdC_grandir.html

3 Likes

Sauf pour le changement d’uid, je suis pour les changements technique que tu propose. ça me semble aussi être le plus urgent pour augmenter la sécurité du système autour de la Ǧ1. (et ça me semble être un pas dans une direction similaire à la proposition de cgeek vu que concrètement, cela distingue 2 type de compte (forgeron ou non) et 2 types de certifications (entre forgerons ou non), mais avec une approche plus sécuritaire (puisqu’un compte ne peux pas devenir forgeron en cours de route, soit il est créé pour l’être soit non). ça n’adresse en revanche pas la problématique d’extension de la communauté plus aisée, mais les changement coté code à faire sont moindre.

J’ai tout bien compris ?

Cela empêcherait de pouvoir faire tourner un Duniter membre sur une machine à laquelle on n’a pas accès physiquement… Alors que j’espère pouvoir le faire un jour avec un conteneur qui garde secret les credentials.

Je plussoie ! Il y a les membres forgerons, les membres villageois (et les membres loup-garous qui sont de fausses identités…) :wink:

Sinon la proposition @elois me semble bonne.

8 Likes

Franchement j’adorerais qu’on utilise ces termes ! Ludiques et clairs !

La proposition d’@elois me semble très intéressante en tout cas. Le seul truc embêtant c’est la perte de quelques DU lorsqu’on veut passer de villageois à forgeron… Mais ça impact peu de personnes, donc ça me semble acceptable (et si c’est bien fait, on peut même éviter ça)

Autre point d’attention : en général, les membres forgerons sont des noeuds importants de la toile actuelle. Il faut faire gaffe, car lorsqu’ils révoqueront leurs comptes, on a beaucoup de liens qui vont disparaitre avec eux (et qui mettront plusieurs mois pour revenir).

4 Likes

Je sais que ce n’est peut-être pas très propre, mais ce serait pour la bonne cause :
Ne pourrait-on pas écrire à la main la liste des membres “forgerons de départ” ?
C’est encore possible vu la taille de la toile, en prenant bien la peine de communiquer en amont auprès de tous ceux qui ont déjà calculé au moins 1 bloc.
Processus transparent, on accepte tous ceux qui demandent (et on voit, encore une fois “à la main”, s’il y a 200 nouveaux forgerons dont personne n’a entendu parler sur le forum qui s’inscrivent). Si la démarche est clairement expliquée ici ça ne devrait pas être trop critiquable si ?

Pour le problème des comptes potentiellement compromis, il faut se demander quel % de comptes ça représente, car le nombre de comptes :

  1. Qui demandent à pouvoir calculer,
  2. Qui se sont déjà connectés à CesiumWeb,
  3. Sur une instance qui soit au choix :
    a) déjà compromise
    b) tenue par quelqu’un qui refusera une MaJ qui “nettoiera” les connexions de la liste.

me semble faible (mais je me trompe peut-être).

Tout ceci me paraît bien compliqué pour un problème de piratage de DNS qui peut être résolu en ne passant pas par un DNS !
Si chaque hébergeur de CesiumWeb communique une adresse IP fixe et non plus un nom de domaine usurpable, le problème est résolu !
Ceci s’accompagne d’une petite explication pour l’utilisateur final des risques liés au DNS et qu’il est 100% en sécurité seulement en passant par un liens commençant par une IP.
Il pourrait être maintenu par la dev team une whiteliste d’IP indiquant qui est l’hébergeur, clé de membre éventuellement (l’ajout/vérification de ces informations est faite en dehors du système par d’autres moyens de confiance), et invite les utilisateurs à “cliquez droit sur le lien et ajouter aux favoris”.

Changements dans la user story de création d’un compte membre

Aucun

Changements dans le protocole DUBP

Aucun

[edit] Changements pour les hébergeurs de CesiumWeb

  • Corriger le certificat HTTPS pour qu’il soit valide avec l’IP ( ?heu je maitrise pas, est-ce faisable? ou bien le certificat ne vautque pour des noms de domaines? )

Transition en deux étapes pour la Ğ1

  1. Créer une page de liste blanche avec message éducatif avec des liens et/ou QRCode
    exemple: g1.duniter.fr << glissez ce lien dans vos favoris
  2. Effacer toute traces de lien avec DNS dans les docs te sites parlant d’instances de CesiumWeb

Changements pour l’utilisateur

  • Mettre à jour son-ses favori-s

(post écrit par un utilisateur averti, pas dev ni sysadmin)

Ca n’est pas qu’un problème de DNS. En règle générale, sur les Blockchain, avoir accès à une clef privée permet d’avoir accès à la monnaie sur le compte. En plus, sur la June, une clef privée membre permet de calculer des blocs. Le problème est la centralisation d’un certain nombre de clefs privées potentiellement calculantes sur des serveurs Césium (qui pour le moment n’enregistrent pas ces clefs, à ma connaissance).

Ces serveurs sont des points d’attaque faibles de la monnaie pour mener des attaques 67%.

On peut avoir comme attaques :

  • par DNS menteur
  • par prise de contrôle d’un serveur (faille ou erreur humaine)
  • par corruption d’un admin
  • et sans doute d’autres.

Donc la question n’est pas simplement du DNS, c’est “comment éviter que des identités calculantes ne soient exposées sur des serveurs”. Par précaution.

Si tu lis TOUS les tutos concernant la gestion de portefeuilles d’autres cryptomonnaies, ils insistent bien : ne communiquez pas vos clefs privées sur internet ni à personne alors même que ces clefs sont bien moins critiques car sans rapport avec la sécurité du réseau de calcul. Et sur la June, on a une situation inverse : des clefs privées critiques pour le calcul, potentiellement exposées sur des serveurs.

5 Likes

La solution d’Eloïs renforce la sécurité bien au dela d’un piratage DNS d’instance cesium-web.

Plus le nombre de membre forgeron est proche du nombre de membre dans la fenêtre de calcul courante, plus il sera difficile pour un attaquant d’avoir suffisement de clef membre forgeron pour effectuer une attaque significative.
Le fait que les clef membre forgeron ne puisse pas se connecter sur un cesium-web est selon moi un bonus accessoire d’un point de vu sécurité par rapport à l’ampleur du problème actuel : De nombreux membres prosélyte son prêt à certifier qui que ce soit qu’ils ont vu 1 ou 2 fois et semble intéressé, donc il est facile pour quelqu’un de nomade de se faire certifier plusieurs compte, comptes pouvant écrire en blockchain, donc il est relativement simple d’effectuer une attaque pouvant prendre la main sur la blockchain aujourd’hui.

Restreindre l’écriture blockchain aux seuls membres forgerons, créé pour cela, et avoir une licence spécifique, renforcée sur les principes de sécurité pour ces membres me semble certes ajouter une contrainte non négligeable pour ces derniers, mais améliorer considérablement la sécurité de l’ensemble, cesium-web ou non.

5 Likes

Heu… pardon ? Qui a dit que c’était pour “résoudre un problème de DNS” ??

Je ne l’ai effectivement pas rappelé dans mon premier post, mais le fait que tout les membres est le droit au calcul est un problème de sécurité a de nombreux égards et tout les dev sont déjà d’accord sur le fait qu’il est nécessaire de restreindre ce droit d’accès au calcul. On n’avais simplement pas de proposition claire et arrêtée sur comment procéder exactement, ou alors des solutions bien trop complexes, la proposition que je fais ici est au contraire la plus simple à implémenter parmi toutes les propositions qui ont été faites jusque la :wink:

L’app Cesium n’a pas de logique serveur, tout se passe dans le navigateur de l’hote, en tout cas sur une version non modifiée/piratée…

Ha ça! Effectivement, c’est une réflexion que je me suis déjà faite, et j’ai même penser à le réaliser, et puis manque de temps pour jouer à ce petit jeu…
C’est un réel problème je suis d’accord… Et je dirais même que c’est du ressort de la conception de la TdC, le fait de ne pas avoir de “finesse” dans l’acte de certifier, ni d’outils supplémentaires d’aide à la confiance qu’une licence qu’on suppose respectée…
Alors effectivement il y’a peut être des choses à faire niveau protocol !

Bah c’est que le méchant CesiumWeb reviens souvent sur le tapis comme un risque MAJEUR, alors que je vois des solutions pour ce problème-ci…
Maiiiiis j’entends je lis vos réponses et je comprends le problème plus profond pas de soucis !!

3 Likes

La solution de @cgeek n’est pas réalisable pour éviter que tous le monde puissent calculer des blocs ? :thinking: