Proposition de solution user-friendly au problème de sécurité des instances cesium web


#21

Si @cgeek a envie de le faire dans Duniter je suivrais, mais perso je ne serais pas moteur pour ces 3 propositions, car nous avons bien d’autres priorités concernant l’évolution du protocole. Je préfère donc qu’on se limitent aux changements absolument nécessaires dans un premier temps, et j’estime que tes propositions permettent concernant l’uid ne sont pas une nécessité :slight_smile:

Je pense au contraire que la Licence Ğ1 doit expliciter l’ensemble des droits et devoir nécessaires et suffisants qui incombent a tout membre de la Ğ1, en ce sens la présence de la formule de calcul du DU me semble indispensable, c’est la formule officielle a laquelle se référer sans avoir besoin d’aller chercher dans la documentation du site web ou sur le forum :wink:

Oui c’est une bonne idée :slight_smile:

En fait il y aurait toujours qu’un seul et unique type de certification dans le protocole. Donc c’est énormément plus simple a implémenter et énormément plus simples pour les utilisateurs finaux, qui n’auront rien de plus a savoir s’il ne calculaient pas de blocs.

Les membres forgerons n’auront qu’un seul type de certif, c’est juste qu’il devront faire preuve de plus de vigilance lorsqu’il certifieront d’autres membres forgerons. Les clients pourrait par exemple, ré-afficher la licence forgeron avec une checklist de points a vérifier chaque fois qu’un membre forgeron est sur le point de certifier une identité forgeron.


#22

@vincentux relis bien ce que j’ai écrit :

Je me suis déjà exprimé sur le fait que la proposition de 3 types de liens qu’avait soumis cgeek était beaucoup trop complexe et allait rendre illisible pour l’utilisateur final un concept déjà fort complexe a comprendre.
Cela complexifierai également beaucoup trop le protocole a mon goût, il me semble qu’un bon protocole se doit d’être le plus simple possible pour répondre a un besoin donné, car plus il est simple plus il est maintenable, réimplémentable et optimisable.
Donc si l’on peut répondre a un même besoin avec une solution technique plus simple, j’estime qu’il nous faut opter pour la solution la plus simple, conformément au principe du Rasoir d’Ockham.


#23

ok :blush:


#24

Mouais, donc concrètement, ça reviens à dire qu’il y a 2 types de certifications pour l’utilisateur, il n’y a juste pas besoin de modifier le protocole pour le prendre en compte au niveau des document de certification (c’est le sigPowQty qui sert à vérifier qu’il y a bien suffisement de certification de type forgeron à forgeron), mais pour l’utilisateur, c’est une vigilance différente, des vérification supplémentaire… bref, un autre type de certification (mais pas techniquement, humainement seullement).


#25

C’est vrai que si les forgerons, qui sont souvent des gens impliqués, restreignent leurs certifications il faudra aviser.
Ou alors afficher dans les outils (sauf dans Cesium-web) “l’identité que vous souhaitez certifier a/n’a pas droit de forgeage” pour ne pas les limiter dans leurs certifications de villageois.


#26

Oui évidemment :slight_smile:


#27

Je repense à la solution d’@elois pour corriger le souci de sécurité actuel de la centralisation cesium-web.

La solution protège d’une prise de contrôle de l’écriture dans la blockchain, mais pas d’une création massive de faux comptes en cas de piratage réussi de g1.duniter.fr.

L’usage de hardware wallet, solution bien plus lourde à mettre en place, j’en conviens, résout ces deux enjeux de sécurité, et d’autres :

  • permet d’utiliser son compte membre pour signer des documents arbitraires sur des applications tiers sans exposer ses secrets -> exemple d’usage : vendeur identifié sur gchange ou assimilé.
  • libère les usagers de la nécessité de retenir un identifiant secret et un mot de passe sur les quels toutes la sécurité repose (trop complexe, ils l’oublient, trop simple, ils sont vulnérable aux attaque brute force un peu évoluée)
  • n’introduit pas de centralisation de pouvoir dans la capacité à écrire dans la blockchain -> conserve la pleine citoyenneté à chaque membre.

Dans les aspects moins sympa :

  • implique d’équiper les usager de hardware wallet.
  • implique de coder le nécessaire pour avoir des hardware wallet compatible avec nos besoins.
  • implique d’avoir un hardware wallet branché sur chaque noeud membre, à moins d’ajouter un mécanisme de délégation pour cet usage.

Je ne dit pas que c’est la solution à adopter dès demain, vu qu’elle est plus lourde à mettre en place, mais ça me semble une meilleur solution à terme car elle offre :

  • plus de sécurité pour tous
  • la conservation d’une gouvernance horizontale / d’une pleine citoyenneté pour tous.

Le principal aspect durablement gênant est le cout UNL non nul pour chaque nouvel entrant, tant que nous n’avons pas de fournisseur de hardware wallet en Ǧ1.

Une solution intermédiaire ou de transition serait de considérer les comptes (membre) actuel comme “compte découverte” avec les possibilité du N1 de la proposition de @cgeek (pas d’écriture blockchain ni de membre référent), et de considérer les comptes créés avec hardware wallet comme “compte (membre) citoyen”. Techniquement cela revient globalement à avoir des compte membre simple et des compte forgeron, mais en pratique, au lieu de diffuser le message à la communauté : votre compte membre fait l’affaire, laisser les choses importante au forgerons, ça ne vous concerne pas, on leur envoi le message : bienvenue, vous avez maintenant un compte découverte qui vous permet de gouter aux avantage d’une monnaie libre. Pour devenir pleinement citoyen, il reste un pas à faire, qui vous sécurise tout en vous donnant des droits supplémentaire, et sécurise toute la communauté.


#28

Merci @1000i100 pour cette proposition !

Quelque soit la solution adoptée et les efforts pour garder une gouvernance “horizontale” par le plus grand nombre, il y aura toujours la fracture de “l’expertise”.

Il y a ceux qui “savent” :

  • Contribuer au code, faire tourner un nœud, sécuriser ses comptes, installer un client, utiliser un client.
  • Faire tourner un nœud, sécuriser ses comptes, installer un client, utiliser un client.
  • Sécuriser ses comptes, installer un client, utiliser un client.
  • Installer un client, utiliser un client.
  • Utiliser un client.

On pourra toujours faire ce qu’on veut, on aura toujours cette “fracture numérique” pour parler poliment ou une “hiérarchie par l’expertise” inévitable.

On aura beau essayer de transmettre le savoir, d’éduquer aux bonnes pratiques, (et il faut le faire !) on aura malheureusement toujours des fractures.

J’aime bien le concept de hardware wallet, mais il est plus facile à voler et aussi facile à perdre (vous n’avez jamais perdu une clef usb ?). Et comment le brancher sur un serveur hébergé ?

Il faut que ce soit un choix (je préfère les mots de passes, ou bien je préfère un fichier de clef privée).

@elois a exposé une solution qui acte de fait une fracture dans l’expertise et sépare les responsabilités.
J’y suis assez favorable.

Pour alimenter le débat entre les niveaux de certifications proposés par @cgeek et les comptes forgerons, la communauté PGP a déjà expérimenté les certifications graduelles, puis est revenue en arrière en ajoutant un mode avec moins de niveaux (le mode TOFU - Trust on First Use qui sera le mode par défaut pour rendre PGP plus accessible).

https://linuxfr.org/users/gouttegd/journaux/de-la-confiance-dans-le-monde-openpgp#principe

En tout cas c’est pour moi une priorité de sécurité. Pour exagérer un peu, je dirais que pour l’instant, on a un sudo chmod 777 sur tous les comptes membres… :wink:


#29

point de vue utilisateur, ca me semble assez simple: on désactive progressivement l’authentification sur les instance cesium web (en retirant l’authent par salt & password sur les version publique )
On peut faire le test une semaine sur le g1.duniter et voir les retours obtenu. dans le pire des cas on vera d’autre instances fleurir pour combler ce manque pour les utilisateur non geek. dans le meilleur des cas une augmentation dans les installation de clients.
En parallèle, on déploies des solution d’installation facile. (plugin firefox? ),

en ce qui me concerne je penses shipper un cesium pré-configuré en local dans juniter tant que je n’aurais pas codé ces fonctionnalité dans le client lourd. Y a-t’il des install duniter incluant cesium ?

j’envisage différent mode de sync :

  • light : sync mes données & celles de mes potes & état actuel du reseau
  • keep up : stay synced, maintain indexing and forks, listen to network
  • compute blocks
    de sorte qu’on puisse l’utiliser en client ou server, avec / sans GUI

Ya un avantage stratégique a shipper un paquet Duniter+Cesium: l’utilisateur ne fait pas la différence entre le back et le front, c’est génial!! chaque fois qu’on repousse l’authent en ligne, on stimule en même temps l’installation d’un noeud.

les cesiums en ligne existeront évidement mais s’il est d’usage de n’utiliser que “celui du copain” occasionnellement c’est déjà moins grave et plus dans l’idée de la WoT. moi je suggère de retirer l’authent depuis g1.duniter.fr. même si les gens utilisent une version “MLOccitanie” ou “le sou” de Cesium, c’est toujours mieux que le serveur “officiel” montre l’exemple. les entrant, les curieux vont arrivé par là. c’est donc sur cette page là qu’il faut initier l’utilisateur aux bonnes pratiques. en parler entre nous et chercher a palier le problèmes techniquement c’est pousser le probleme ailleurs: WoT = facteur humain => éducation.

Voila pour ma proposition “not-user-friendly” .


#30

C’était le cas à une époque, dans Duniter 1.x (mais je ne sais plus quelle version).

Mais Duniter proposera bientôt ses propres écrans de gestion de wallet / identité / certifications / adhésions, avec des utilisations avancées (nouveautés !). Cesium est bien, mais pour une utilisation basique.