Mettez-vous vos identifiants membre dans une instance hébergée de Césium ?

cesium

#22

Non non ce n’est pas de même nature du tout. La tu parle de moyens pour proteger sa la vie privée ou/et protection d’activité sensible tel que lanceurs d’alertes, sources des journalistes, etc

Le problème soulevé ici n’a absolument rien a voir, on parle de sécurité de notre monnaie commune, si beaucoup de membres se font volés leur clé privée et ne le voient pas alors le voleur peut prendre le controle totale de la monnaie en utilisant ses clés pour calculer tout les blocs sans etre soumis a la difficulté personnalisée. Pour cela il lui suffit de dérober plus de clés que la moitié des membres calculant et de ne s’ent servir que pour le calcul des blocs de sorte que les membres dérobés ne se rendent compte de rien et ne révoques donc pas leurs comptes !!

C’est sans commune mesure, en fait la situation est déjà catastrophique mais comme nous ne sommes encore la cible d’aucune attaque donc on ne se rend compte de rien. Si l’une des instances actuellement hébergée utilisée par plus de 40 membres différents se fait pirater là maintenant, la Ğ1 peut très bien s’arrêter demain !

Alors certes on pourrait modifier le protocole de manière a limiter le droit au calcul a certains membres, et nous allons le faire, mais ça ne suffira pas, sauf a limiter si fortement ce droit que la monnaie deviendrais de fait centralisée, il faut vraiment empêcher a minima les comptes membres de se connecter sur une instance hébergée (les simples portefeuilles ne posent pas de problème).


#23

Je comprends mieux. Césium devient un “single point of failure”… Le fait qu’il y en ai plusieurs ne change pas le problème si une faille est découverte (ou introduite dans le code par un contributeur malveillant).

Je persiste cependant à penser qu’il faut pas négliger le fait que beaucoup de membres ne sont pas technophiles… Il faut trouver des solutions pour garantir la sécurité du système mais sans mettre une barrière technique trop complexe.


#24

@Greg : Oui, on parle ici des installations de Césium sur des serveurs, accessibles à tous. ( https://g1.duniter.fr , https://g1.duniter.be , etc… )

Il reste possible d’installer Césium en local, sur son ordinateur. Les risques sont alors grandement limités. :slight_smile:


#25

Bonjour,

Beaucoup de gens qui utilisent un ordinateur ont dû, à un moment ou un autre, installer des logiciels dessus. Ne serait-ce qu’un traitement de texte. Celleux qui ne savent pas le faire en autonomie se sont fait.e.s aider.

Cesium, une fois installé, c’est aussi simple à utiliser que Cesium-web. Donc une interdiction de se connecter à un compte membre sur Cesium-web avec un lien pointant vers le téléchargement de Cesium-desktop me paraît une bonne solution.

Je ne sais pas réparer ma voiture. Quand elle a un petit souci, je demande à un.e ami.e. Quand elle a un gros souci, je vais dans un garage. C’est une question de sécurité pour moi et les autres personnes. Là, c’est pareil : c’est une question de sécurité pour le réseau Ğ1 et pour l’utilisateurice, donc celleux qui ne savent pas faire doivent demander ou se former.

Tout restant dépendant du bon vouloir du developpeur de Cesium et/ou des contributeurices en code, dont je ne peux faire partie.


#26

Un compte porte-feuille pourrait devenir un compte membre un jour ou l’autre, non…?

Ceci dit, la sécurité du logiciel installé en local par des personnes qui ne savent pas le mettre à jour n’est pas forcément idéale non plus, pour poser un poids de l’autre côté de la balance…


#27

Je suis peut-être mal au fait de sécurité informatique, mais il me semble que s’il y a risque de sécurité sur un client césium local non mis à jour, il ne concerne que l’utilisateurice de ce client, et pas toute la blockchain ? Ou bien je me plante ?


#28

Le risque concerne tous les utilisateurs qui se seraient connectés à ce Cesium ; ceci dit, s’il y en a, disons, au hasard, cinq, ben ça crée un risque d’attaque Sybil ; les cinq peuvent même être répartis sur plusieurs Cesiums locaux. Et une attaque Sybil, c’est un risque pour toute la monnaie… Mais c’est certain que la concentration peut poser plus de soucis.


#29

@elois en parle aussi, vous pourriez préciser? Vous êtes en train de dire qu’il éxiste une possibilité de rerouter un site avec un vrai domaine bien écrit, vers une version autre (phishing) ? Ou bien on parles de DNS squating? ( comme le petit malin qui a acheter le domaine lpfs.io, noter le L à la place du I , pour servir de gateway ipfs qui sert de fausses apps de gen de pairs de clé ETH pour les enregistrer :sweat_smile: )

Aprés le bonhomme in the middle (Malcolm?) il va pas chopper plus que ce qui est publié en blockchaîne, Cesium est une webapp, il n’y pas de backend à qui envoyer des données, et encore moins la clé priv. Une fois tout chargé, ce qui rentre et sort ne concerne que les appels au noeud DUniter choisi, donc BMA (ou WSP2 ? ) et DB Cesium+ Les clés sont stockés en RAM côté navigateur et/ou dans le localStorage sandboxé si l’utilisatriceur l’à choisi.

Aprés oui il reste le XSS dans les données Cesium+ (mais je crois que Ionic gère bien ceci à confirmer @kimamila ? ) , ou si l’app est corrompue là elle peut faire n’importe quoi comme aller piocher ds le localStorage et envoyer les clé…

Est-ce que partager/lister quelque part de façon officiel des IP publiques plutôt que des DNS, et les faire s’y connecter par l’IP directement protège d’une attaque DNS ?


Une solution peut-être serait de dev une extension pour les nav. gérant les clés et les fonctions de cryptographies, à la manière de Metamask pour ethereum. Les clés ne sortent pas de l’extensions, et les web apps font appel à elle pour encrypter, signer, hasher, etc … De cette maniére, même une app corrompue ne peux accéder aux clés…

Un peu complèxe !


Je suis plutôt de l’avis de @Artanux il ne faut pas discreminer trop les neophytes, et je préfère l’éducation à la répression … Ceci dis, il est vrai aussi qu’une plus grande majorité de gens savent installer un truc en 3 click, sans lire, donc faire une suite ultra simple préconfigurée à installer en 3 click sur tous les OS avec mise à jour auto. ça contente les 2 partis (facilité / sécurié).


Je trouve aussi la proposition de @1000i100 très “consensus” dans le sens où elle conviendrait bien comme choix entre les 2. Ca regroupe même la notion d’éducation, car expliciter la fonction de blocage à une certain %age des membres/noeud permet de bien comprendre les risques, ca permet de garder des versions en lignes, pousse à la décentralisation …
Il reste les données de Cesium+ à synchroniser régulièrement aussi


#30

@dig oui c’est se qu’on appelle une attaque par DNS menteur. L’idée c’est que l’attaquant déploie plein de faux serveurs dns qui donnent leur zone dns modifiés a l’utilisateur. Ainsi lorsqu’un utilisateur demande a résoudre g1.duniter.org, un serveur menteur peu lui donner une autre IP pointant vers une instance cesium modifiée. La seule protection existante contre ça c’est le DNSSec : ça consiste a signer sa zone dns ET a faire signer sa clé publique par son registrar qui la fait lui même signé par l’organisme responsable de la zone, qui la fait lui même signer par l’un des 13 gardiens de DNSSec dans le monde. C’est ultra centralisé comme système mais c’est mieux que rien. L’idéal serait un système décentralisé a la IPFS mais faudra encore du temps :confused:

Bref, une fois l’attaque DNS menteur réussi, tu crois etre sur g1.duniter.org mais tu est en réalité sur une autre instance, qui te fournie un cesium modifié qui logge ta clé privée.

Oui ça protège d’une attaque DNS, mais une IP c’est impossible a retenir, dans la pratique ce ne sera pas utilisé donc inefficace. Et puis certains utilisateurs ne savent pas ce qu’est une IP. C’est beaucoup plus simple de leur dire “il faut installer cesium sur ton ordi et voila” que de les embrouiller avec une notion d’IP qui est pour certains du chinois. De plus, si le site web qui fourni la liste des ip n’a pas DNSSec lui même on est confronté au même problème.

Exactement c’est dans ce sens qu’il faut concentrer les efforts !


#31

Ha ha c’est bien quand tu fait une faute de frappe alors!!? dunite.org ca existe pas :stuck_out_tongue:

ta ta ta, c’est de la mauvaise volonté ça, n’importe quel lien pointant vers l’IP et non le DNS sur un wiki dans un navigateur peut être glissé déposé dans les favoris, et c’est réglé !! comme par exemple ce lien:

Cesium de g1.duniter.fr

Au pire to pire si c’est utilisateur mobile un QRcode et l’affaire est réglé! Il ne s’agit pas de se souvenir de l’IP à taper… Les utilisateurs lambas ils érivent même pas d’adresse, la barre est caché même souvent, ils passent pas des favoris…

EDIT : En fait ca ne va pas, il reste un gros warning de certificat https du coup, l’utilisateur ca il sais pas quoi en faire, aprés si le geek pote qui lui partage le lien lui fait ca peut passer… mais j’avour c’est pas top

EDIT2: Enfin si il est choisi d’accéder à l’instance que par IP, alors le certificat peut être changé pour plus avoir le warning non ?


#32

Houla des favoris, c’est quoi ça ? Je me suis rendu compte avec le temps que la plupart des gens non technophiles non aucune idée de ce que c’est donc c’est déjà plus compliqué pour l’utilisateur que d’installer cesium en local.


#33

Les utilisateurs lambda ils passent surtout par du moteur de recherche evil :slight_smile:

Pour l’attaque MitM TLS : en attaque par virus peut tout à fait injecter une fausse CA dans le navigateur de l’utilisateur. Le virus peut ensuite intercepter les trames TLS vers son certificat émis par sa CA et les rechiffrer à la volée, en injectant au passage du code pour extraire la clé privée de l’utilisateur Cesium.

Bon ceci dit, un virus peut tout aussi bien modifier une instance Cesium installée localement, donc un tel virus, si il se propageait fortement, ferait beaucoup de mal à la monnaie.

La seule solution serait de packager Cesium en un gros binaire signé. Je en sais pas ce qui existe de ce coté là comme solution mais il doit bien y avoir quelquechose…


#34

Le processus qui consiste à signer un code source ou un build binaire est la https://fr.m.wikipedia.org/wiki/Signature_de_code.

Ce serait vraiment bien de pouvoir le faire sur nos applications.

Saviez vous qu’on peut signer des commits git ? Bon je vais un peu loin là. :laughing:


#35

On peut utiliser la norme debsigs pour les paquets debian que l’on livre :


#36

C’est parfait ça, comme ça on pourra faire la promo des systèmes linux ^^ “Ta du windaub, on ne peut pas te garantir l’authenticité de ce que tu installes” ^^


#37

Plus généralement : on ne peut de toute façon rien garantir sur quoi que ce soit sous windows puisque l’on a pas accès au code source, windows peut très bien envoyer sur des serveurs distants toutes les saisies de l’utilisateur, et ça ne m’étonnerai pas qu’il le fasse, donc de toute façon MS a déjà les clés privés d’une partie des membres de Ğ1.


#38

Pourquoi ne pas déployer une version de Cesium sur IPFS ? :wink: Je veux bien m’y coller, ça fait un moment que j’ai envie de tester un déploiement.


#39

Ho oui ho oui, moi aussi moi aussi! ^^

Il faudrait aussi (et surtout) une version des données de Cesium+ dans l’ipfs…
(Ca fait un bout de temps que j’y pense…)

Bon j’ai pas énormément de temps libre, mais je veux bien en être!!


Après je vois pas ce que ça change, accéder à Cesium via son multi-hash ipfs ne résoud pas le problème de passer par un nom de domaine (une gateway ipfs doit bien être accessible quelque part) ou bien de faire installer un noeud ipfs juste pour ca reviens à installer un Cesium local donc same same but different


#40

Par le hash on pourrait vérifier que c’est une version non modifiée. De plus, pas besoin de serveur pour l’héberger, car chaque utilisateur peut le partager sur le réseau. Si on utilise un IPNS (clé signant un hash IPFS pouvait être modifié), on pourrait avoir un accès simple à la dernière version de Cesium.


#41

La ğ1 et le mouvement des colibris