10 DU à gagner ! Qui sera le 1er? Clés publiques à identifiants Scrypt simples. Les clients doivent-ils laisser passer les identifiants simples pour le déverrouillage de monnaie?

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 :stuck_out_tongue:

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 J'aimes

Oui ça je l’ai déjà précisé plus haut.

1 J'aime

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 J'aime

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 J'aime

En l’occurrence sur Cesium, si la « création de compte » requiert effectivement 8 caractères au moins, la « connection » :wink: 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

Pas sûr que julie befezzi soit aussi enthousiaste !

Il y a apparement déjà eu un topic sur ce problème, mais je n’y ai pas accès :
https://forum.duniter.org/t/qui-est-donc-3rp7ahdg-videur-de-compte-dune-lodevoise/5481

Sans aller jusque là, il n’est pas possible de checker si le salt et le password sont vide ?
Tu y as bien accès dans auth_by_script ici. Il suffirait d’ajouter un avertissement à ce moment là, non ?

1 J'aime

haha celle la je l’ai dans mes TU Dunitrust, c’est la clé générée par la seed contenant 32 octets a zéro :rofl:

1 J'aime

Du coup, à ce que je pense comprendre. La personne controlant la clé publique « A89DCfrmJ7HGrg9BoVXq4eib3KSqdmMoKXxSvupggzeL » (julie befezzi) a utilisé Silkaj v0.6.0 avant le correctif en v0.6.1 qui corrige le bug majeur sur les transactions dont Galuel a également pu expérimenter les méfaits et le remonter.

Transactions history from:  A89DCfrmJ7HGrg9BoVXq4eib3KSqdmMoKXxSvupggzeL
[…]
+---------------------+--------------------------+------------+--------------+---------------------------------------------------------------------------+      
| 2019-03-19 16:38:00 |                          |            |              |                                                                           |      
+---------------------+--------------------------+------------+--------------+---------------------------------------------------------------------------+      
| 2019-03-19 16:38:00 | SebasC - CPEaW4BGNaBdx   | -600       | -59.350      | Cadeau                                                                    |      
+---------------------+--------------------------+------------+--------------+---------------------------------------------------------------------------+      
| 2019-01-19 21:25:41 | 3rp7ahDGeXqffBQTnE       | -600       | -59.350      |                                                                           |      
+---------------------+--------------------------+------------+--------------+---------------------------------------------------------------------------+      
| 2018-12-18 17:08:06 | CWKZojYu8GWrbaaL7P       | -240       | -23.740      |                                                                           |      
+---------------------+--------------------------+------------+--------------+---------------------------------------------------------------------------+      
| 2018-12-18 16:52:26 | SebasC - CPEaW4BGNaBdx   | 300        | 29.674       | yop                                                                       |      
+---------------------+--------------------------+------------+--------------+---------------------------------------------------------------------------+      
| 2018-11-25 23:32:44 | 3rp7ahDGeXqffBQTnE       | -400.800   | -39.640      | Change operation                                                          |      
+---------------------+--------------------------+------------+--------------+---------------------------------------------------------------------------+      
| 2018-11-25 23:32:44 | 3rp7ahDGeXqffBQTnE       | -400.800   | -39.640      | Change operation                                                          |      
+---------------------+--------------------------+------------+--------------+---------------------------------------------------------------------------+      
| 2018-11-25 23:32:44 | 3rp7ahDGeXqffBQTnE       | -400.800   | -39.640      | Change operation                                                          |      
+---------------------+--------------------------+------------+--------------+---------------------------------------------------------------------------+      
| 2018-11-25 23:32:44 | 3rp7ahDGeXqffBQTnE       | -401.600   | -39.720      | Change operation                                                          |      
+---------------------+--------------------------+------------+--------------+---------------------------------------------------------------------------+      
| 2018-11-25 23:32:44 | 3rp7ahDGeXqffBQTnE       | -951.080   | -94.070      | Change operation                                                          |      
+---------------------+--------------------------+------------+--------------+---------------------------------------------------------------------------+      
| 2018-11-25 23:29:01 | 3rp7ahDGeXqffBQTnE       | -400.400   | -39.600      | Change operation                                                          |      
+---------------------+--------------------------+------------+--------------+---------------------------------------------------------------------------+      
| 2018-11-25 23:29:01 | 3rp7ahDGeXqffBQTnE       | -400.400   | -39.600      | Change operation                                                          |      
+---------------------+--------------------------+------------+--------------+---------------------------------------------------------------------------+      
| 2018-11-25 23:29:01 | 3rp7ahDGeXqffBQTnE       | -400.620   | -39.630      | Change operation                                                          |      
+---------------------+--------------------------+------------+--------------+---------------------------------------------------------------------------+      
| 2018-11-25 23:29:01 | 3rp7ahDGeXqffBQTnE       | -400.800   | -39.640      | Change operation                                                          |      
+---------------------+--------------------------+------------+--------------+---------------------------------------------------------------------------+      
[…]

Du coup, en envoyant des unités à SebasC, ça a envoyé à cette fameuse clé 3rp7ah. Je comprends pas, le comportement est différent de celui rencontré par Galuel. Pourquoi cette clé est en destinataire pour les opérations de change en plus de celle de SebasC ?

  • Les transactions du 25 novembre 2018 sont uniquement vers 3rp7ah (opération de change).
  • Le 18 décembre 2018, deux tx correctes (pas de tx intermediares où il y a bug).
  • Le 19 janvier 2018, tx vers 3rp7ah
  • Le 19 mars 2019, tx vers SebasC avec un problème d’affichage au dessus je suppose.

Silkaj a bien accès aux identifiants entrés par l’utilisateur. Un avertissement à quoi ? Que l’utilisateur est en train de déverrouiller des sources sur une clé publique à identifiants vides ? Ça sert à quoi ? Ça prévient quoi ?

Récupérer la monnaie sur une clé à identifiants vides est du vol ? Alors, matograine et jardin seraient également considérés comme voleurs pour ce qui au début du post été considéré pour un jeu ? Je suppose que tu veux plutôt faire référence au possible vol de la clé A89DCf vers la clé 3rp7ah. J’ai l’impression que l’émotionnel ne te permet pas de voir clairement les choses.

La question à se poser est comment les sources sont allées sur 3rp7ah ?
Je pense plutôt que la faute est à mettre du côté du bug de Silkaj et également aussi d’une erreur de l’émetteur. Je vois pas comment Silkaj a pu volontairement envoyer des sources vers une clé publique à identifiants vides, étant donné qu’il ne génère pas la clé du destinataire à partir de Scrypt, uniquement en la récupérant tel quelle de la CLI. Ça ne peut être que la personne qui contrôle la clé publique (julie ou quelqu’un d’autre) qui a volontairement envoyé des sources sur 3rp7ah en générant préalablement et délibérément la clé du destinataire.

Sakia, n’autorise pas de gérer des salts/passwords trop courts (encore moins vides !).

1 J'aime

@Moul ne fais pas preuve de mauvaise foi stp, je t’ai invité dans la discutions privée ou SebasC nous avait bine remonté un cas de disparition inexpliqué des G1 de l’utilisatrice concernée (julie befezzi) impliquant la clé 3rp7ahDG. Et je pense que la cause ne viens pas de silkaj car vu le profil je suis convaincu que cette personne ne maitrise pas la ligne de commande, je connais plusieurs de ces certifiés et certificateurs et tous m’indique qu’il s’agit de quelqu’un qui n’est pas tech du tout.

La cause de ce vol reste pour moi un mystère, peut-être que ce n’est pas l’autorisation d’utiliser des credentials vide qui est en cause, mais si on veut trouver l’explication de cet événement c’est plutôt du coté de Cesium qu’il faut regarder.
M’enfin 1 an et demi après les fait pour une utilisatrice qui a quittée la monnaie, perso je n’ai pas bien envie de consacrer du temps a essayer de retrouver la cause.

Je soulevais juste un point qui est selon moi une évidence sur ce qu’un client devrait permettre ou non, j’ai déjà exposé mes arguments je ne vais pas me répéter ça ne sert a rien, on est pas d’accord et on ne se mettra pas d’accord, ce n’est pas grave, c’est la vie, passons a autre chose :slight_smile:

Pour info, Sakia, en mode expert, permettra de faire tout ce qu’un expert en sécurité doit pouvoir faire pour intervenir via les API sur la blockchain. Donc aussi tout ce qu’un pirate doit pouvoir faire pour pirater des comptes.

Comme la distribution gnu/linux Kali un outil qui sert finalement aux deux camps.

Je dois pouvoir accéder aux Junes du compte à identifiants vides aussi bien qu’un pirate. Actuellement je suis frustrer, Sakia ne peut pas, et je suis obligé d’utiliser DuniterPy avec lequel je peux intervenir sur ce compte. Silkaj aussi, comme outil expert, semble le permettre et c’est une bonne chose.

Alors laissons les différents bridages et garde-fou aux outils destinés au grand public et faisons en sorte que les outils experts soient aussi puissants que possible.

Sakia a pour objectif d’être le client GUI technique expert de référence.

7 J'aimes

J’:heart: c’est le Cluedo :wink: Mais qui a tué l’identifiant vide :policeman:

On vient de trouver la tombe du soldat inconnu… et cherchez à savoir qui a mis des fleurs et qui en a piqué…

Je suis pour augmenter la responsabilité, mais surtout laisser le jeu s’infiltrer quand on pourrait voir une erreur ou un défaut. Chacun ne joue pas au même jeu au même moment… Ni vol, ni malveillance, juste une suite d’événements qui font le sort de ceux qui y participent…

Gloire au « SOLDAT INCONNU » 3rp7ahDGeXqffBQTnENiXEFXYS7BRjYmS33NbgfCuDc8 on a sa photo et accès à sa caméra de surveillance :wink:

1 J'aime

Une petite aide pour trouver les credentials d’une longueur connue d’une pubkey donnée. (programmé rapidement par un ami, très lent mais fonctionnel)

python3 bruteforce.py <credentials_length> <pubkey>

Ah cool, on va avoir de quoi organiser quelques sessions de PWONing :wink:
Ca me fait penser à ce conseil de @elois « le salt doit faire a minima 128bits (16 octets) »
[dup-mnemonic] cli mnemotic passphrase generator

Je pense que pas mal de credentials ne respectent pas cela…

Oui, c’était une demande de @cgeek : de laisser les gens libres de choisir leur difficulté de salt/pwd.
De même pour les paramètres de scrypt, avec le mode avancé.