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?

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 Like

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:

2 Likes

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 Like

@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 Likes

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 Like

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 - #16 by elois

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é.