Désormais, vous pouvez indiquer votre clé publique Ḡ1 via le profile de votre compte sur ce forum : Forum Monnaie Libre
De cette manière, cette dernière sera visible de tous sur votre carte de profile
@Moul, peut être que ce serait une fonctionnalités intéressante pour @DeathReaper, il pourrait checker d’abords ce champ custom pour identifier les utilisateurs à coup sûr, et si pas rempli tente avec le pseudo comme actuellement ?
J’ai aussi pensé à un champ « Pseudo Ḡ1 (si différent) » , mais je pense que ça peut être confus/redondant je sais pas ce que vous en pensez.
On crée une blockchain pour sécuriser via la décentralisation, puisqu’un serveur central est bien plus aisément piratable, et qui plus est stopperait tout par simple arrêt (alors que la blockchain court toujours même si on arrête 99% des serveurs).
Et là, tout comme Cesium+, c’est encore une fois « retour à Central Point » !
Il suffit alors à un pirate, qui saute sur l’occasion de cette très mauvaise compréhension de l’intérêt d’une blockchain, non plus de pirater la blockchain, mais ce serveur unique, en mettant une de ses clés à la place de cette pseudo information, pour qu’automatiquement des paiements s’y dirigent via ceux qui n’y font pas attention.
Pour peut qu’il ait fait tourner ses machines pour changer par une clé dont le début et la fin ressemblent à la clé de base, il embarquera un nombre de faux encore plus grand.
Peut-être faudrait-il que tu revois les notions de base d’un client/serveur. Ici c’est très confus, tu confonds Duniter qui joue le rôle de serveur décentralisé, Cesium+ qui ajoute au client Cesium (lui même décentralisé) des données personnelles qu’il serait idiot de placer en blockchain.
Ce forum n’est ni l’un ni l’autre. C’est un simple outil d’échange et de communication indépendant comme il peut y en avoir des centaines d’autres.
Si un pirate arrive à accéder à l’administration de ce forum, ce serait un exploit (pas impossible) qui sera très vite repéré par les propriétaires de ce forum dont je fais partie, qui sera aussitôt expulsé, ses méfaits corrigés et alors le retrait de ce champs custom pourrait être discuté et envisagé.
Grâce à Cesium+, une personne voulant effectuer un virement vers une mauvaise clé à de forte chance de s’en rendre compte. Cela serait beaucoup plus difficile sans Cesium+ (qui je le rappel, est décentralisé grâce à ElasticSearch, même si quasiment aucun développeur ni toi même n’aient visiblement trouvé utile de monter votre propre nœud Cesium+ pour décentraliser ce réseau, en suivant la documentation de @kimamila sur gitlab).
Bref.
Mais dites moi ce que vous en pensez, si vraiment vous jugez ce champ comme étant une faille de sécurité je le retirerai, évidemment.
Il n’y a rien de confus à clamer clairement que toute donnée hors blockchain n’a pas de lien avec la blockchain, et que la blockchain est un principe de décentralisation, dans laquelle les données Duniter/Ğ1 sont inscrites, et qui ne comporte pas de lien ni logique, ni technique avec des données qui lui sont extérieures.
Ce qui constitue avant tout une faille de sécurité c’est de ne pas alerter les êtres humains qu’on les trompe quant à la nature des outils qu’on leur propose.
Exactement comme « un billet gagé sur l’or » n’est pas de l’or, et que le « risque au porteur » a maintes fois démontré sa fatalité en plusieurs siècles.
Et ce n’est pas parce que la faille ne se révèle qu’au bout de 40 ou 80 ans qu’elle perd sa nature de faille.
@poka SUPER!! Bonne idée. @Galuel, je ne comprends pas les craintes exprimées…
Diffuser une clef publique n’est en aucune façon un problème de sécurité?
Non, mais faire aveuglément confiance à une source d’information regroupant de nombreuses clefs publiques fait de cette source un point d’attaque facile, comme ça a été le cas (erreur) sur Cesium+.
Il convient avant chaque paiement vers un compte qu’on ne connaît pas, de vérifier la clef publique auprès du destinataire.
Logique. Avant de faire un virement (quelle que soit la monnaie), ou d’envoyer un courrier, je vérifie que j’utilise les bonnes coordonnées avec le destinataire.
Effectivement, dans le cas d’une blockchain, une simple mauvaise frappe peut entraîner un virement vers un compte (vu que tous existent à priori), rendant cette vérification doublement importante, vu qu’il est impossible au système de me signifier cette erreur. Enfin on va pas en faire tout un plat
J’ai une solution à proposer pour renforcer la sécurité de ce champ, mais ça va demander quelques semaines que j’implémente ça en plugin Discourse, en ruby.
Pour le moment je reste sur ma position que ce champ est très pratique, et qu’il n’y a pas de faille de sécurité intrinsec à cette fonction.
Je suis d’accord avec Galuel. Une bonne façon de régler ce problème serait un client avec un système de facturation. Par exemple :
Si Alice vend un bien à Bob, Alice envoie d’abord une facture signé par elle à Bob, crypté avec la clé publique de Bob. Bob est donc normalement le seul à pouvoir l’ouvrir, si il l’ouvre c’est que c’est bien lui le destinataire. Il doit ensuite vérifier que la facture est bien signé d’Alice, et cette facture contient le montant mais surtout la clé publique du compte qui doit recevoir la transaction. Il réalise donc le virement, en étant sûr de ne pas se tromper de destinataire.
On peut imaginer ensuite que le virement possède une condition, tel que si la monnaie n’est pas réclamé dans les 24h (ou plus), le virement est annulé. On peut aussi rajouter une condition que pour qu’Alice débloque le montant, elle doit d’abord envoyer une confirmation de réception signée par elle pour éviter les litiges (elle a donc 24h (ou plus) pour le faire).
Ainsi, Alice peut s’assurer de recevoir la monnaie sur le bon compte avant de donner le bien, et Bob peut s’assurer de recevoir une confirmation d’achat avant de renoncer au montant envoyé et afin d’éviter de se faire traiter de voleur.
Pareil pour les dons : le bouton « faire un don » envoie une facture signée par le destinataire du don.
Ainsi, on réduit les vols, pertes, litiges … et divers problèmes. Et ya peut-être plus simple comme procédé
Avec un champ G1 publique (sur ce forum ou ailleurs), rien n’empêche un modérateur/administrateur du service, un hacker du service, l’hébergeur du service, un script malveillant du navigateur… de modifier subtilement cette clé, trompant l’expéditeur au détriment du destinataire
Le cas de Pierre Meunier est dû à une déficience dans l’UX sur Cesium, en ce qui concerne l’annuaire de Cesium+, qui se traite en tant que telle, comme cela a été expliqué ici
Encore une fois c’est confus, on mélange tout.
Tu déconseillerai aussi aux gens de ne pas mettre leur clé publique sur leur propre site ?
Pourtant c’est bien ce que tu fais sur le tien ?
A quel moment avons-nous informé les êtes humains que les données de ce forum étaient inscrites en blockchain ?
Rien n’empêche un hacker du service, l’hébergeur du service, un script malveillant du navigateur… de modifier subtilement cette clé sur le site https://www.creationmonetaire.info/
Personnellement, je demande simplement toujours par mail confirmation de la clé de mon vendeur, ainsi ça limite les risques de se planter. Mais le vendeur peut toujours me donner une mauvaise clé, ou je peux me tromper en la recopiant, ou mon clavier peut choisir ce moment pour qu’une touche ne marche plus. Il est impossible d’éliminer totalement l’erreur humaine, à moins de supprimer l’humain du processus.
), une des seules façons de s’assurer que l’on envoie bien à la bonne personne