J’ai mis 10 DU sur ce compte :
3rp7ahDGeXqffBQTnENiXEFXYS7BRjYmS33NbgfCuDc8
Qui sera le 1er à les récupérer ?
C’est possible sans connaissance technique 
PS : Suivez ce topic car il va être long…
Haha, j’étais tombé sur ce compte pendant des tests 
On peut observer qu’il a d’ailleurs été déjà bien utilisé.
Allez, je rebalance 5DU dessus pour que le jeu continue.
Teaser Silkaj
silkaj -af tx --recipients CvrMiUhAJpNyX5sdAyZqPE6yEFfSsf6j9EpMmeKvMCWW:EUt3FqkmpUg8UdyrB2dGXtZoTo7GRXadEkHagL2q2AKb --amountUD 7.5:2.5
╒════════════════════════════════════════════╤══════════════════════════════════════════════╕
│ pubkey's balance before tx (unit|relative) │ 101.1 Ğ1 | 10.0 UD Ğ1 │
├────────────────────────────────────────────┼──────────────────────────────────────────────┤
│ total transaction amount (unit|relative) │ 101.1 Ğ1 | 10.0 UD Ğ1 │
├────────────────────────────────────────────┼──────────────────────────────────────────────┤
│ pubkey's balance after tx (unit|relative) │ 0.0 Ğ1 | 0.0 UD Ğ1 │
├────────────────────────────────────────────┼──────────────────────────────────────────────┤
│ from (pubkey) │ 3rp7ahDGeXqffBQTnENiXEFXYS7BRjYmS33NbgfCuDc8 │
├────────────────────────────────────────────┼──────────────────────────────────────────────┤
│ to (pubkey) │ CvrMiUhAJpNyX5sdAyZqPE6yEFfSsf6j9EpMmeKvMCWW │
├────────────────────────────────────────────┼──────────────────────────────────────────────┤
│ amount (unit|relative) │ 75.82 Ğ1 | 7.4995 UD Ğ1 │
├────────────────────────────────────────────┼──────────────────────────────────────────────┤
│ to (pubkey) │ EUt3FqkmpUg8UdyrB2dGXtZoTo7GRXadEkHagL2q2AKb │
├────────────────────────────────────────────┼──────────────────────────────────────────────┤
│ amount (unit|relative) │ 25.28 Ğ1 | 2.5005 UD Ğ1 │
├────────────────────────────────────────────┼──────────────────────────────────────────────┤
│ comment │ │
╘════════════════════════════════════════════╧══════════════════════════════════════════════╛
Do you confirm sending this transaction? [yes/no]: yes
Generate Transaction:
- From: 3rp7ahDGeXqffBQTnENiXEFXYS7BRjYmS33NbgfCuDc8
- To: CvrMiUhAJpNyX5sdAyZqPE6yEFfSsf6j9EpMmeKvMCWW
- Amount: 75.82
- To: EUt3FqkmpUg8UdyrB2dGXtZoTo7GRXadEkHagL2q2AKb
- Amount: 25.28
- Total: 101.1
Transaction successfully sent.
1 Like
Vainqueur @matograine !
Généreux et joueur en plus 
En effet, on ne peut faire cette transaction qu’avec Silkaj, pas avec Césium.
Oui ! Du coup il me semble qu’il y a 2 remarques à faire:
- C’est pour moi un bug Duniter : un outil doit identifier toute erreur humaine et alerter en conséquence. Il en va d’une bonne qualité UX… @cgeek Je pense que tu n’avais pas prévu ce cas d’usage ?
- La conséquence de ce bug : un vol de 470 DU ! Le 1er vol de june ?
Des gens (Julie befezzi, Lombard Benjamin…) ont crédité ce compte à mon avis par erreur et il y a un an un petit malin pas très sympa a tout transféré sur ce portefeuille : 7qAyAP4DwAkS9N55uY3aJgJGrZz1hJyc7h9zp8Reuu7w
En général, on crédite pas un compte dont on a trouvé l’adresse au hasard. Je doute fort que :
- quelqu’un.e aie demandé à recevoir de la monnaie sur ce compte, vu sa sécurité toute… relative
- ceusses qui aient versé de la monnaie dessus n’aient pas su ce qu’ils faisaient. On peut observer que læ propriétaire de
4DXV...a fait des virements de 1Ğ1 depuis3rp7...ce qui implique l’utilisation de Silkaj… A mon avis, le choix de laisser cette monnaie disponible était délibéré, ou un oubli. Sinon on en aurait entendu parler, 450DU c’est une petite somme.
edit - en y réfléchissant, je trouve que si on possède plusieurs comptes portefeuilles pseudonymes, utiliser ce compte pour regrouper les fonds en les “anonymisant” serait très bien vu, vu que n’importe qui peut avoir dépensé la monnaie présente sur ce compte.
Quant à ce que Duniter gère le fait d’interdire les comptes “de ce type”, c’est (man)utopique, il y en a beaucoup trop. Il suffirait de changer les paramètres de scrypt, et on trouve un autre trousseau avec les mêmes identifiants (si je ne me trompe pas).
2 Likes
La seule possibilité que je vois c’est qu’il s’agit d’un compte aux credentials trop simples, voir d’un compte aux credentials vides ?
Ce doit être un compte aux credentials vides c’est la seule explication qui me semble compatible avec le fait que ce compte ne serait utilisable qu’avec silkaj et pas avec cesium.
Non @ManUtopiK ce n’est pas un bug de Duniter.
Duniter est agnostique de la manière dont est généré un trousseau de clé, il ne gère que des clés publiques et des signatures. Je ne vois aucun bug ici.
C’est a chaque client d’interdire l’utilisation de credentials trop simples, et les clients qui le permettent devrait être considérés comme non sécurisés. Sur le coup la, pour une fois Cesium est mieux sécurisé que silkaj @Moul.
Je vous laisse ouvrir une issue sur le dépot de silkaj du coup
Exactement, ce qui montre bien que Duniter ne peut pas gérer ces cas, en aucune façon, seuls les clients le peuvent.
Comment julie befezzi (A89DCfrmJ7HGrg9BoVXq4eib3KSqdmMoKXxSvupggzeL) a-t-elle pu créditer ce compte 9 fois +400 Ğ1 en 3 min ? Et une fois de plus 2 mois plus tard ? Pour tout se faire voler 10 jours après. J’aimerais bien savoir si elle savait ce qu’elle faisait ?
D’ailleurs @SebasC a dû se rendre compte de l’arnaque il y a 2 mois en envoyant 1Ğ1 avec commentaire “t qui ?” à 7qAyAP...
Oui, il s’est viré 2 fois 1Ğ1. Est-ce que c’est lui qui s’est viré les 470DU ? Ça m’étonnerait. Mais il a lui aussi découvert l’astuce.
Je viens de voir la réponse d’@elois en même temps. Je pensais que c’était LE seul compte aux crédentials vides…
OK, je comprend. Oui, les clients devraient gérer ce problème, c’est pas sécu…
Les commentaires sont “change operation”, soit les commentaires générés par Silkaj en cas de transaction intermédiaire (quand on regroupe des sources pour faire un gros virement). Elle a donc dû utiliser :
- soit une version de Silkaj modifiée
- soit une version buguée de Silkaj (je vais regarder un peu ça)
- soit le faire délibérément.
1 Like
Je ne suis pas d’accord. Ne pas pouvoir utiliser les sources de monnaie sur ce type de clé publique est une anti-fonctionnalité et un bug. Pourquoi verrouiller les Ğusages de certaines clés publiques pour les transactions ?
Qu’est-ce qu’il y a de non sécurisé à utiliser les sources de monnaie d’une clé publique à identifiants vides ? Si un utilisateur envoie ses unités sur une clé publique à identifiants vides, est-ce de la responsabilité du logiciel client ou de l’utilisateur ? Le logiciel client devrait empêcher l’utilisateur de récupérer les sources de cette clé publiques à identifiants vides ?
Pour clarifier, bien que ça ne soit pas le sujet. Pour la création d’une identité, c’est une bonne pratique de sécurité que de forcer l’utilisateur à avoir des identifiants forts. Je rappelle que Silkaj ne gère pas encore l’envoie d’identité, dont découlent les trois autres documents de la toile de confiance : adhésion, certifications et révocation.
3 Likes
Pour les Ğusages il y a déjà plein d’autres possiblités de comptes sans credentials. Comme les comptes aux conditions XHX seules sans signature.
Si aucun client ne le permet ce n’est pas un bug, il n’y a juste pas de sources de monnaie sur ce genre de clés
Un utilisateur non averti pourrait alors créer un simple portefeuille sans crédentials, c’est très dangereux. Si cela pouvais être rendu interdit dans le protocole, je proposerai qu’on l’interdise. Hélas ce n’est pas possible, sauf a définir une manière standard de générer ou trousseau (ce que j’aimerais proposer mais pour une passphrase, par un couple de credentials puisse j’ai toujours dit que ça ne me semblais pas pertinent).
De mon point de vue oui. C’est d’ailleurs ce que @kimamila a fait pour Cesium, et a sa place j’aurais fait pareil (c’est a marquer d’une pierre blanche pour une fois que je vais dans le sens de @kimamila \o/).
Les clients de l’écosystème Ğ1 permettent l’envoie de transactions à ce genre de clé. Mais ne permettraient pas de récupérer les sources sur cette clé. Désolé, mais je sais pas comment appeler ça autrement qu’une anti-fonctionnalité et un bug.
Dangereux pour quoi pour qui ? Tu peux développer ?
1 Like
Dangereux pour l’utilisateur final a qui ont a permis de créer ce simple portefeuille sans credentials. Il se fera voler les G1 qu’il aura déposé dessus.
Après tu pourrais me répondre que l’utilisateur non-averti n’utilise pas silkaj, et que donc ce n’est pas choquant que silkaj soit plus permissif, et tu aurait raison.
Bien encadrer un utilisateur reviens forcément à le limiter un peu, pour le protéger de ses potentielles mauvaises pratiques. Et ça me semble désirable de faire cela pour monsieur tout le monde, donc essentiel pour un client destiné au grand public. Mais en effet ce n’est pas le but de silkaj, donc ça me va de ne rien changer
Je rappelle qu’on ne crée pas de compte sur la Ğ1. À partir d’identifiants, on contrôle des clés publiques dans la multitude de combinaisons des caractères possibles.
L’utilisateur peut soit envoyer ses unités d’autres portefeuilles soit demander à quelqu’un d’autre d’en envoyer sur cette clé.
Au préalable, l’utilisateur aura pris la responsabilité d’utiliser des identifiants vides pour le « contrôle » de cette clé afin d’y accueillir des unités de monnaie. La suite de l’histoire est de sa responsabilité.
Morale de l’histoire, 7qAyAP4, matograine et le futur acquéreur de ces 5 DU (jardin) n’auraient pas pu débloquer ces sources sans Silkaj 
C’est totalement impossible de garantir cela, et ce serait du coup plutôt une faille exploitable qu’autre chose. De mon point de vue, les clients devraient émettre des messages d’avertissement, mais certainement pas interdire ce genre d’utilisation.
Par ailleurs, dans ce cas, on devrait également interdire 123456/0000, etc. Qui définit ce qui est autorisé et ce qui est interdit ? Je ne vois pas par ailleurs comment on pourrait garantir quoi que ce soit au niveau du cœur puisqu’on n’a pas accès aux credentials.
3 Likes
Oui ça je l’ai déjà précisé plus haut.
1 Like
J’étais en train d’y penser. Cet avertissement n’est intéressant qu’au moment d’envoyer des unités à une clé publique de ce type. Pour ce faire il faut avoir une liste de ces clés et les générer préalablement avec toutes les combinaisons simples… Pas sûr que ça soit désirable.
Ce n’est pas ce à quoi je pensais, car tu ne peux pas savoir quelles sont les clés « fragiles » sans, comme tu le dis, compiler une grosse base de données d’adresses. Je pensais à celui qui se connecte à un compte avec des identifiants « faibles ». Au moment de se connecter à ce compte « faible », il me semble intéressant de mettre un avertissement. De ce point de vue, les indicateurs indiquant l’entropie d’un mot de passe sont assez sympas. Bon, évidemment, en ligne de commande, c’est plus compliqué, mais on peut toujours faire un prompt d’avertissement (qui doit pouvoir être bypassé en cas d’automatisation).
1 Like
Il n’y a pas de notion de connexion à un compte dans Silkaj. Du coup, il devient pas possible de prévenir de la « connexion à un compte ». Il y a uniquement la signature de documents DUBP.
Concernant Césium, il est surement possible que ça n’ait pas été volontairement fait d’interdire les identifiants vides.
Ça devrait être le comportement par défaut des frameworks d’interface utilisateur. Il devrait surement exister une possibilité de configurer ces champs pour permettre des champs vides.
Quid de Sakia ?
J’augmente la difficulté :
- AoxVA41dGL2s4ogMNdbCw3FFYjFo5FPK36LuiW1tjGbG (2 DU)
- 2P77A5K4VTgGEhHMhEpKpnxNRV3NUwDNp6D3iV16foD3 (5 DU)
- 4zvwRjXUKGfvwnParsHAS3HuSVzV5cA4McphgmoCtajS (10 DU) (celle-là n’est pas trouvable avec les credentials)
1 Like
En l’occurrence sur Cesium, si la “création de compte” requiert effectivement 8 caractères au moins, la “connection” en requiert au moins un.
J’ai récupéré 40% de la mise, envoyé 20% aux devs, laissé 20%.
2DU sont sur la nouvelle clef publique DLfZtZTgn6miyPdSHa5aiC3GTpYzibtTBLsf3oyPzoSK