• # dommage

    Posté par  (site web personnel) . Évalué à 5.

    dommage que la page date de début 2004... les premières classes sont basées sur la puissance d'un... Pentium 100 ! Un peu dépassé.

    • [^] # Re: dommage

      Posté par  (Mastodon) . Évalué à 4.

      C'est l'ordre de grandeur qui est important. Ce qui prendrait 200 ans à casser sur un pentium 100 prendra un peu moins de temps sur un bi-Athlon, mais reste raisonnablement sûr. Et puis si tu veux être sûr, il suffit de considérer que la meilleure classe d'attaques est celle courrament utilisée.

      • [^] # Re: dommage

        Posté par  . Évalué à 3.

        Toujours dans les ordres de gandeurs (oui, je sais, la vitesse du proc ne fait pas tout), environ 20 ans avec un proc 1GHz ou 10 avec un proc 2 Ghz, quoi. Le temps de changer de mot de passe ^^

        • [^] # Re: dommage

          Posté par  (site web personnel, Mastodon) . Évalué à 10.

          Avec un dual core, tu tombes à 5 ans. Début 2007 on aura des quadri core, ce qui nous fera deux ans et demi. Puis comme une machine ça ne vaut plus grand chose, suffit d'en avoir deux ou trois pour casser ton pass en quelques mois. Si ce n'est moins. Puis si t'es vraiment méchant, suffit de récupérer quelques Windows zombifiés et casser ton pass en deux heures. C'est beau le progrès :)

          • [^] # Re: dommage

            Posté par  . Évalué à 10.

            M'en fous, je retiendrais des mots de passes de 142 caractères complètement aléatoire pour plomber le budget des gros méchants qui veulent me pirater en les obligeant à acheter un nombre exponentiel de machine pour tester toutes les combinaisons jusqu'à 142 !!! Niark Niark, je suis diabolique.

  • # standblok?

    Posté par  . Évalué à -8.

    Note: standblog, c'est bon, mangez-en !

    C'est sympa ton message car ici personne connait.
    Tu devrais aller faire un tour dans tes options de linuxfr et activer la boite à nitot, ensuite tu peux aller te couvrir de honte.

    • [^] # Re: standblok?

      Posté par  . Évalué à 6.

      t'es désagréable toi !

      J'ai mis la note car j'ai trouvé l'info sur le standblog.

      Et ce n'est pas parce que je peux avoir le RSS du standblog sur ma page linuxfr que je ne peux pas donner cette info, sinon autant aller sur un portail RSS !

      • [^] # Re: standblok?

        Posté par  (site web personnel) . Évalué à 3.

        Je me demande vraiment ce qui est le plus désagréable. Moi perso, j'en ai _ras le bol_ de voir les posts du standblog repris de partout.

        Merci, si je veux aller lire la prose (lourde) de Nitot, j'irais la lire moi même.

        • [^] # Re: standblok?

          Posté par  . Évalué à 0.

          "et c'est bien"

          Je trolle dès quand ça parle business, sécurité et sciences sociales

        • [^] # Re: standblok?

          Posté par  . Évalué à -1.

          si les posts du standblog sont repris de partout, c'est qu'il y a des choses intéressante.

          De plus, tu n'es pas obligé de lire ces posts. Alors, si sur linuxfr, tu vois un post qui reprend un post du standblog, et qui le dis explicitement, ne le lis pas et ne rales pas.

          Dire dans un journal que l'info vient d'un autre site permet d'un de faire connaître le site à ceux qui ne connaissent pas (et oui, ça arrive, on est pas censé tout connaître!), mais c'est aussi une forme de respect pour l'auteur original, ce n'est pas du pompage sauvage.

  • # Méthodologie ?

    Posté par  (Mastodon) . Évalué à 2.

    Je suis un peu surpris par les chiffres qu'ils donnent. En voilant voir à quelle vitesse un PC un peu récent peut faire ça, j'ai fait un programme tout simple:

    - Je suis parti du principe que j'avais un mot de passe haché par MD5, et que je voulais à partir du hash retrouver le mot
    - J'ai énuméré des chaînes de 10 caractères dans un alphabet de 62
    - J'ai calculé le hash MD5 de ces chaînes (avec OpenSSL)
    - J'ai comparé ce hash avec un autre hash, à chaque fois

    Sur un Athlon MP à 663 MHz, je peux tester environ 400 000 mots de passe par seconde. En passant le même processeur à 1.66 GHz, je peux en calculer environ 1 100 000. Un million de clés par seconde, c'est ce qu'ils donnent pour un Pentium 100, donc j'ai eu quelques doutes.

    Je me suis dit que ma méthode d'énumération était assez bête, mais en fait le truc qui prend du temps, c'est de calculer les hash. Si je ne calcule plus les hash, l'Athlon à 663 MHz "teste" environ 67 millions de mots par seconde. Du coup, j'ai un peu l'impression que dans leurs tests, ils ne font que générer des mots de passe, mais sans les tester (ou alors la fonction de transformation qu'ils utilisent est beaucoup plus rapide à calculer que MD5, ou alors l'implémentation d'OpenSSL est lente).

    J'ai bricolé ça rapidement, donc je ne garantis rien, mais si l'ordre de grandeur est bon, on peut raisonnablement considérer que la "classe D" de l'article correspond à ce qu'on peut faire avec un bi-core moderne.

    • [^] # Re: Méthodologie ?

      Posté par  . Évalué à 2.

      ou alors l'implémentation d'OpenSSL est lente

      Ça me paraît assez plausible, parce que c'est vraiment pas prévu pour enchaîner des millions de hash, et on doit perdre un temps fou entre l'appel de openssl et le démarrage réel du calcul.

      • [^] # Re: Méthodologie ?

        Posté par  (Mastodon) . Évalué à 2.

        Je n'avais rien d'urgent à faire, alors j'ai essayé la même chose sans faire appel à openssl. La différence avec avant, c'est:
        - On ne crée plus la structure MD5_CTX à chaque appel
        - J'ai inliné une partie des fonctions en espérant que gcc inline les autres
        - Je ne remet plus à zéro la structure inutilement "pour des raisons de sécurité".

        Toujours à 663 MHz:
        Avant: 420 000 mots par seconde
        Après: 550 000 mots par seconde

        C'est mieux, mais ça reste loin du million de mots par seconde pour le Pentium 100.

        • [^] # Re: Méthodologie ?

          Posté par  (Mastodon) . Évalué à 2.

          Je précise, bien sûr, qu'ils ne parlent certainement pas de cracker des mots de passe hashés par MD5, puisqu'ils parlent d'Office ou de disques Zip. Mais c'est plus intéressant de regarder combien de temps il faut pour cracker un mot de passe hashé, puisque c'est ce qui est le plus largement utilisé.

          • [^] # Re: Méthodologie ?

            Posté par  (site web personnel) . Évalué à 3.

            C'est exactement ce que je me suis dit. Les seuls logiciels cités sont Office en bas de l'echelle mais quand ça monte, rien n'est précisé.

            Avec des mot de passes hachés en MD5 voire en SHA1 les chiffres avancés sont plus du domaine du farfelu qu'autre chose.

      • [^] # Re: Méthodologie ?

        Posté par  (site web personnel) . Évalué à 1.

        > Ça me paraît assez plausible, parce que c'est vraiment pas
        > prévu pour enchaîner des millions de hash, et on doit perdre un
        > temps fou entre l'appel de openssl et le démarrage réel du
        > calcul.

        Oui et non. Avec OpenSSL, tu peux accèder aux algos via leur engine mais tu peux aussi accèder aux algos de bas niveaux. Par contre ce qui est sûr c'est qu'OpenSSL n'est certainement pas l'implémentation la plus rapide de MD5 pour un processeur donné.

    • [^] # Re: Méthodologie ?

      Posté par  . Évalué à 1.

      C'est un peu la façon de faire de RainbowCrack, tu génères des tables de hash précalculés pour gagner énormément en temps.

      • [^] # Re: Méthodologie ?

        Posté par  (Mastodon) . Évalué à 1.

        En dehors des cas les plus simples, il n'est pas tellement envisageable de précalculer une table de hashes. Prenons par exemple un mot de passe alphanumérique (alphabet de 62 caractères) de 8 lettres de long. Il y a 62^8 mots de passes différents. Stocker un élément prend 8 octets pour la chaîne et 16 octets pour le hash. Ce qui nous fait en gros, si je ne me trompe pas dans mes calculs, 4 880 281 Go d'espace pour stocker la table.

        Bien sûr, il faut aussi stocker la table pour les mots de passe de 7, 6, 5... caractères.

        Si on se limite à un alphabet de 26 caractères, toujours pour des mots de passe d'exactement 8 lettres, il faut 4 668 Go. Ça devient raisonnablement envisageable, mais utiliser un mot de passe sur un alphabet de 26 lettres, c'est chercher les ennuis.

        • [^] # Re: Méthodologie ?

          Posté par  (Mastodon) . Évalué à 4.

          On dirait que j'ai encore parlé un peu trop vite, apparemment RainbowCrack ne génère pas de tables complètes, mais une forme condensée qui ne garantit pas de trouver le pass, mais qui le permet avec une bonne probabilité. Sur un alphabet de 36 lettres ils s'en sortent avec 36 GB, c'est impressionant.

          • [^] # Re: Méthodologie ?

            Posté par  (site web personnel) . Évalué à 3.

            Sauf que ça marche pas avec les mots de passes de /etc/shadow ;)

            Parce que sous unix on fait pas comme windows on utilise un grain de sel :)

            bon en tout cas, en mettant john the ripper sur mon fichier shadow il a lamentablement échoué sur les deux premières étapes en quelques minutes ;)

        • [^] # Re: Méthodologie ?

          Posté par  (site web personnel) . Évalué à 1.

          > En dehors des cas les plus simples, il n'est pas tellement
          > envisageable de précalculer une table de hashes

          avec les Rainbow tables, ils utilisent un compromis temps-mémoire, ils ne précalculent pas tous les hashs.

    • [^] # Re: Méthodologie ?

      Posté par  (site web personnel) . Évalué à 3.

      Tu n'es pas le seul à être supris.
      http://teh-win.blogspot.com/2006/04/combien-de-temps-pour-ca(...)

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: Méthodologie ?

      Posté par  . Évalué à 2.

      Regarde du coté de crack par exemple, mais les algo pour calculer les hashs sont assez optimisés pour l'utilisation en brute force.

    • [^] # Re: Méthodologie ?

      Posté par  (site web personnel) . Évalué à 2.

      - Je suis parti du principe que j'avais un mot de passe haché par MD5, et que je voulais à partir du hash retrouver le mot

      T'as de l'espoir...
      Tu sais que la fonction de hachage est une surjection, et donc que l'espace d'arrivée (de cardinal 16^32) est plus petit que l'espace de départ, de taille infinie si tu regardes la norme du MD5 (des chaines de longeur infinie en entrée).
      Donc au mieux, tu peux trouver un élément de la même classe que ton mot de passe. Mais pas le mot de passe d'origine.
      Comme il y a une infinité de mots de passes avec le même haché (en supposant que la distribution soit équiprobable), la chance que tu tombes sur le bon est nulle tant qu'on a pas plus d'informations (j'entends par "informations" des connaissances poussées sur l'algo de md5 lui même qui monteraient des propriétés remarquables)....

      Bref, tu risquais pas de retrouver le mot.
      En plus, rien en prouve qu'un mot de longeur inférieure (ou égale) à 10 donne ce mot de passe.

      Mais bon, je chipote (lata)

      • [^] # Re: Méthodologie ?

        Posté par  (site web personnel) . Évalué à 3.

        > l'espace de départ, de taille infinie si tu regardes la norme du MD5 (des chaines de longeur infinie en entrée).

        Oui, mais là, on parle de mot de passe, qui sont de longueur limitée en général. Bien sûr, si le mec a utilisé un mot de passe de longueur 52, t'es pas prêt de le trouver, mais avec un mot de passe de taille raisonable, l'espace de départ n'est pas plus grand que celui d'arrivée. En fait, pour ce genre d'utilisation, c'est même indispensable que l'espace d'arrivée soit plus grand que l'espace de départ pour les mots de passe de taille raisonables, parce que c'est l'espace d'arrivée qui est limitant. Par exemple, avec un mot de passe de taille 372 et une fonction de hashage sur 1 bit, t'as pas une sécurité d'enfer ...

        > Bref, tu risquais pas de retrouver le mot.

        As-tu déjà utilisé John the Ripper ?

        • [^] # Re: Méthodologie ?

          Posté par  (Mastodon) . Évalué à 3.

          J'ajoute aussi que lorsque le mot de passe est hashé par MD5, je me fiche royalement de trouver le vrai mot de passe, si je trouve un autre mot de passe qui a le même hash, c'est aussi bien. Du point de vue du processus d'identification c'est la même chose, puisqu'il ne connaît que le hash.

          Mais de toutes façons, j'ai bien précisé que je cherchais un mot de dix lettres dans un alphabet de 62, et 62^10 est très inférieur aux nombres de hashes possibles de MD5 (2^128), donc la probabilité de trouver deux chaînes valides qui ont le même hash est faible.

          • [^] # Re: Méthodologie ?

            Posté par  (site web personnel) . Évalué à 3.

            ... mais c'est quand même con si le vrai mot de passe c'était toto00 et que toi, tu trouve x{%8vC;!azQ ou quelque chose comme ça qui a le même MD5 ;-)

            • [^] # Re: Méthodologie ?

              Posté par  . Évalué à 2.

              Un truc vraiment bête, ce serait qu'un utilisateur choisisse consciencieusement un mot de passe avec plein de caractères exotiques, et qu'il tombe par accident sur la somme MD5 de "toto" ! :-)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.