Securiser vos wallets

  • -

    @anubis901 tu te souviens de ma longue phrase quelques posts plus haut ? ->

    “Par contre, le diable est dans les détails : il n’est pas rare qu’un développeur se plante dans l’implémentation qu’il fait d’un mécanisme de cryptographie (néglige un paramètre, se trompe sur son usage, fait l’impasse sur une partie de la documentation, etc.) aboutissant alors à une application qui utilise une très bonne fonction cryptographique mais avec des paramètres mal choisis qui en annulent tout ou partie du bénéfice.”

    Ton petit défi m’a titillé, alors je suis allé voir le code de ton appli. En gros tu coches toutes les cases. Ton implémentation d’AES n’est pas sûre. Tu as négligé des paramètres, tu n’as pas compris comment utiliser correctement AES. Bref, voilà, la sécurité de ton application est sous-optimale. Ça ne veut pas dire qu’il suffit de claquer des doigts pour casser ton mot de passe, mais tu donnes toutes les cartes à l’attaquant pour lui faciliter la tâche.

    Tu ne devrais pas utiliser le mot de passe fourni par l’utilisateur comme clé privée, tu devrais passer par une fonction de dérivation avant, type PBKDF2. Sans cela, ta clé de chiffrement est bien trop faible et “devinable”.

    Ton code utilise un initialisation vector nul : 16 fois le chiffre 0, alors que l’IV devrait être aléatoire et changer à chaque utilisation. Là ton IV ne sert à rien, tu perds une protection importante.

  • -

    Quel silence assourdissant 🙂

    On aurait pu croire que quelqu’un d’aussi intéressé par la sécurisation de ses clés privées aurait quelque chose à répondre aux défauts d’implémentation de son code… Dommage.

    On en revient aux prémices initiales : un bon gestionnaire de mot de passe à la sécurité éprouvée fera le travail avec de meilleures garanties.

    Herc 1 Reply
  • -

    @patpro
    Le gestionnaire de mots de passe où l’utilisation de dés.
    Y’a que ça de vrai !!
    Dice

    Mais c’est un peu plus chiant avec les dés !!
    🤟

    P 1 Reply
  • -

    @Herc je vois ce que tu veux dire mais pour le coup c’est hors sujet : tu ne peux pas stocker tes clés privées (de crypto-actifs ou autre) en utilisant des dés 🙂
    Dans le contexte de ce fil de discussion, le gestionnaire de mot de passe te permet de stocker de manière sûre une clé privée de la même manière qu’elle le fait habituellement pour un mot de passe.

    Herc 1 Reply
  • -

    Pareil, j’utilise des générateurs de mots de passe et c’est hyper simple 😊

  • -

    @patpro les dés servent juste à créer le password. J’étais sur le côté entropie.
    Pour le stockage c’est une autre histoire !

    P 1 Reply
  • -

    @Herc oh je sais parfaitement tout ça, mais c’est bien du stockage dont il est question ici (l’appli dont l’OP fait la promotion), même si avec @Raniva on s’est aventuré du côté de l’aléa dans les mots de passe.

    Les dés pour générer des mots de passe c’est gentil, ça apprend le concept, mais sincèrement c’est pas trop praticable pour obtenir des mots de passe vraiment très variés car en général l’utilisateur va se baser sur une liste de mots trop courtes (ie. gérable avec quelques dés).
    En dessous d’un dictionnaire de 200000 ou 300000 mots c’est compliqué d’avoir une “phrase de passe” pas trop longue ET en même temps appartenant à un “keyspace” très large.
    Pour résumer, plus ton dictionnaire de départ est court, plus ta phrase de passe doit être longue et les dés ne permettent pas facilement d’adresser un dictionnaire très long.

  • -

    rahhh ptain 🙂

    https://github.com/Anubis901/SafeCrypto/commit/ff0eb465782fa8a28ecbbf0d4a886fc244d26ceb

    Il aurait été bien inspiré de passer par ici avant de faire semblant de corriger son code. La modif dans la gestion du mot de passe n’apporte rien.
    Et cette modif fait perdre la compatibilité avec les vaults créées sur l’ancienne version, si bien qu’elles ne sont plus lisibles avec la nouvelle version de l’appli.
    Aussi, c’est length, pas lenght. Bref.

Log in to reply