Rugby et cryptographie : Shabal est en demi-finale !

Posté par (page perso) . Modéré par Florent Zara.
Tags : aucun
32
26
juil.
2009
Sécurité
Bien entendu ce n'est pas de Sébastien Chabal dont il est question ici mais bien de la fonction de hachage SHABAL qui participe à la compétition SHA-3.

Les 14 algorithmes sélectionnés pour participer au second tour de la compétition ont été annoncés avant-hier 24 juillet par le NIST. Constatant que les chercheurs en cryptographie mettaient au point des attaques de plus en plus puissantes contre les fonctions de hachage actuelles de la familles SHA (Secure Hash Algorithm), le NIST (National Institute of Standards and Technology) américain a décidé d'organiser une large compétition pour trouver un successeur.

Comme il y a quelques années avec la compétition du nouvel algorithme de chiffrement AES, c'est tout le gotha de la cryptographie qui participe à cette sélection. On y retrouve le célèbre Bruce Schneier avec Skein, Ron Rivest (le R de l'algorithme de chiffrement à clé publique RSA) avec la proposition MD6. Il y a aussi Daniel J. Bernstein, l'auteur des logiciels libres qmail et djbdns, qui propose son algorithme de hachage maison CubeHash. En tout plus de 60 propositions sont arrivés sur la table du NIST avant le 31 octobre 2008, date limite de participation à la compétition. Après élimination des algorithmes fantaisistes ou facilement cassables, il en restait 25 pour le premier tour de la compétition.

Tout le monde a retenu son souffle et c'est avant-hier que le NIST a annoncé la liste des 14 survivants qui allaient pouvoir passer en demi-finale : BLAKE, Blue Midnight Wish, CubeHash, ECHO, Fugue, Grøstl, Hamsi, JH, Keccak, Luffa, Shabal, SHAvite-3, SIMD, et enfin Skein. Les cryptologues du monde entier ont maintenant un an (jusqu'à la conférence SHA-3 d'août 2010) pour tester les candidats et déceler les failles potentielles avant que ne soit annoncés les deux ou trois participants à la finale.

Alors quel algorithme va gagner et devenir le nouveau standard mondial des fonctions de hachage ? Évidemment personne ne peut le dire à l'heure actuelle... mais si on prend en compte l'humour des propositions il est évident que l'algorithme SHABAL est un sérieux candidat. SHABAL est proposé par une équipe française financée par l'Agence Nationale de la Recherche dans le cadre du projet SAPHIR (Security and Analysis of Hash Primitives). Si vous avez la curiosité de jeter un œil au fichier pdf de présentation vous pourrez constater que, perdus au milieu des formules mathématiques ésotériques, on trouve plusieurs slides qui renseignent sur le choix du nom de l'algorithme. Après tout quoi de mieux pour symboliser la résistance d'une fonction de hachage que d'évoquer un féroce joueur de rugby de plus de 110 kilos et capable de plaquages monstrueux !

Les planches 10 et 11 présentent Sébastien Chabal (French monster EATS babies !) et la planche 12 nous informe que Sébastien dévore Grøstl au petit-déjeuner. Les auteurs de cette fonction de hachage danoise participant à la sélection SHA-3 apprécieront... Le summum est atteint à la planche 16 ou est annoncé l'étude d'une version faible de l'algorithme SHABAL (ces études de versions affaiblies sont très utiles pour déceler les failles des algorithmes).
Les auteurs de SHABAL ont choisi le nom de « Weakinson » pour cette version faible (qui est qualifiée de Fast, efficient, with good statistics, but often broken) en jouant évidemment sur le nom du joueur de l'équipe d'Angleterre Jonny Wilkinson.

Pour l'humour dont a fait preuve l'équipe du projet SAPHIR et pour le prestige de la glorieuse équipe de France de rugby je pense que vous serez tous d'accord avec moi : il faut que SHABAL gagne !
  • # Geek life

    Posté par (page perso) . Évalué à  10 .

    J'avais lu ruby dans mes flux RSS, je pigeais plus rien à la dépêche.
    • [^] # Re: Geek life

      Posté par . Évalué à  5 .

      Moi, j'avais lu "chat-bite" au lieu de "SHAvite", c'est pas mieux... -_-"
  • # CubeHash

    Posté par . Évalué à  3 .

    Je ne saisis pas pourquoi CubeHash est limité en entrée à 2^128-1 bits. J'ai peut-être mal lu l'algorithme, mais je n'y trouve pas cette limite.
  • # À noter qu'une autre proposition française a atteint le même stade

    Posté par . Évalué à  9 .

    SIMD pour SIMD is a Message Digest, proposition du laboratoire d'informatique de l'École Normale Supérieure.

    son originalité est d'utiliser au maximum les fonctions vectorielles (type MMX ou SSE sur architecture x86) des processeurs modernes, ainsi que la possibilité de paralléliser le calcul sur plusieurs cœurs.

    http://www.di.ens.fr/~leurent/simd.html
  • # MD6

    Posté par (page perso) . Évalué à  5 .

    A noter que MD6 n'est plus là. Surprenant...
    • [^] # Re: MD6

      Posté par (page perso) . Évalué à  5 .

      MD6 était bien trop lent (comparé à Shabal par exemple mais aussi à la famille SHA-2). Alors Rivest et son équipe ont voulu l'accélérer en divisant le nombre de tours par deux. Seulement voilà, ils n'ont pas pu produire de preuve de sécurité de cette version "réduite" contre les attaques de type cryptanalyse différentielle.

      Finalement Rivest a annoncé sur la mailing-list de la compétition SHA-3 que MD6 n'était pas suffisamment abouti pour le concours et le NIST a du l'écouter puisqu'il n'est pas dans la liste des 12 candidats pour le second tour.

      http://groups.csail.mit.edu/cis/md6/OFFICIAL_COMMENT_MD6_200(...)
      • [^] # Re: MD6

        Posté par (page perso) . Évalué à  -1 .

        La vitesse s'est bien mais pour, par exemple les hash des mots de passe, on s'en fiche !
        • [^] # Re: MD6

          Posté par . Évalué à  5 .

          Va dire ça aux développeurs d'applications web deupointzoro avec des bases de données contenant des millions d'utilisateurs. Et puis les fonctions de hashage ne servent pas qu'à ça.
          • [^] # Re: MD6

            Posté par (page perso) . Évalué à  1 .

            Je pensais au mot de passe de connexion sur une machine : login, ssh. Pour ces mots de passe la, il n'y a pas de problème de vitesse.

            Pour les applications web des hébergeurs, ce n'est pas pareil.
            • [^] # Re: MD6

              Posté par . Évalué à  2 .

              Pourquoi tenir absolument à MD6 alors que les auteurs ont demandé de le retirer de la compétition ? De toute façon on a besoin d'un algo le plus performant possible pour certains usages. L'algorithme élu sera plus robuste et plus rapide...

              Tu penses vraiment que le monde serait meilleur avec douze algos de hash différents selon les usages ? Ca va justement à l'encontre de l'idée d'AES, SHA etc.
              • [^] # Re: MD6

                Posté par (page perso) . Évalué à  7 .

                Mais je ne tiens pas à MD6 ! Je dis, tiens il n'est plus la, surprenant ! Surprenant tout simplement parce que le compétiteur n'est pas un "amateur" dans le domaine. N'ayant pas suivis les débats, j'ai le droit d'être surpris. Je dirais même qu'il est normal d'être surpris et de vouloir en savoir plus.

                Sinon, je préfère effectivement qu'il y ait plus qu'un seul hash, vu qu'un jour il tombera, s'il toutes les applications ne sont pas sur la même formule, cela me convient. Sinon, je ne vois pas le rapport entre l'AES et le hash mais je dois avoir oublié un truc.
                • [^] # Re: MD6

                  Posté par . Évalué à  1 .

                  > Mais je ne tiens pas à MD6 ! Je dis, tiens il n'est plus la, surprenant !

                  Ta réponse concernant la vitesse pouvait laisser croire le contraire avec son point d'exclamation. Peux tu m'éclairer sur le sens de ta remarque sur la vitesse ? (En tenant compte du fait que tu savais qu'il y avait 14 autres algorithmes jugé aussi robuste que la version lente de MD6 et qui eux sont plus rapides)

                  > Sinon, je préfère effectivement qu'il y ait plus qu'un seul hash

                  Note que personne ne te force à utilise AES ou SHA si tu penses que d'autre fonctions sont moins exposées ou plus sures.

                  Le problème c'est que des gens aptes a étudier la robustesse d'un algo et d'une implémentation il n'en existe qu'une poignée. AES/SHA te certifie que la communauté de la cryptanalyse pense que cette fonction est robuste, rapide et implémentable sur tout type de plateforme. C'est un "survival of the fittest"

                  Multiplié les algos, c'est réduire le temps que cette poignée de personne a pour les valider... Je suis pas certain que tu arrives à l'effet voulu.

                  > Sinon, je ne vois pas le rapport entre l'AES et le hash mais je dois avoir oublié un truc

                  Entre AES et le hash aucun. Par contre entre AES et SHA-3, il y en a un petit... Ils suivent le même processus de standardisation par le NIST: concours ouvert, deux rounds puis élection finale, fenêtre de plus d'une année pour la cryptanalyse.

                  SHA-3 sera au hash ce que AES est au chiffrement: la solution estimé la meilleure par la communauté de la cryptographie. Contrairement à DES et SHA-(0,1,2) qui avaient été poussé unilatéralement par le NIST (et donc la NSA).
                  • [^] # Re: MD6

                    Posté par (page perso) . Évalué à  6 .

                    >>> AES/SHA te certifie que la communauté de la cryptanalyse pense que cette fonction est robuste, rapide et implémentable sur tout type de plateforme. C'est un "survival of the fittest"

                    A noter toutefois que la compétition organisée par le NIST, même si elle est la plus célèbre, n'est pas la seule.
                    La commission européenne a organisé le projet NESSIE entre 2000 et 2003 : http://fr.wikipedia.org/wiki/Projet_NESSIE

                    Là aussi il y a eu évaluation par des cryptographes du monde entier et là aussi il y a eu une sélection finale d'algorithmes.
                    Par exemple le gagnant des fonctions de hachages, outre les SHA-x, a été l'algorithme Whirlpool conçu entre autre par Vincent Rijmen, l'un des auteurs d'AES : http://fr.wikipedia.org/wiki/Whirlpool_%28algorithme%29
                  • [^] # Re: MD6

                    Posté par (page perso) . Évalué à  3 .

                    Pour la vitesse, si tu te loggue via ssh sur une machine, tu n'est pas au millième de seconde près... Donc dans ce cas là, il n'y a pas de problème de vitesse. Pour ouvrir ton trousseau de clef gpg, ssh-agent... ce n'est pas une action que tu fais toutes les deux miniutes et encore une fois, il n'y a pas de problème de vitesse à ce niveau là.

                    > En tenant compte du fait que tu savais qu'il y avait 14 autres algorithmes jugé aussi
                    > robuste que la version lente de MD6 et qui eux sont plus rapides

                    Non, au moment du POST je ne le savais pas. Je n'ai pas pris le temps de surfer sur tout leur site avant d'exprimer que j'étais surpris.

                    > Multiplié les algos, c'est réduire le temps que cette poignée de personne a pour les
                    > valider... Je suis pas certain que tu arrives à l'effet voulu.

                    Il ne faut pas exagérer non plus. Tous les candidats sont très bon même si leur algo ne sont pas tous aussi bon.

                    Je n'y connais rien mais le RSA n'est pas si bon que cela puisque il faut des clefs de plus en plus grosse (cf pb clef gpg chez debian et autre), alors qu'il y a des algo qui permettent de faire bien mieux (courbe elliptique si mes souvenirs sont bons).

                    Bref, avoir plusieurs schéma est une bonne chose. J'ai regardé le schéma proposé par D. J. Bernstein : CubeHash. C'est vrai que comme cela, il semble simple. La suite, sans prendre de crayon et vu mon niveau en crypto, je ne suis pas capable d'en déduire quoi que ce soit.

                    > Par contre entre AES et SHA-3, il y en a un petit... Ils suivent le même processus de
                    > standardisation par le NIST:

                    OK, le lien est quand même faible. Ils suivent la même procédure.

                    > SHA-3 sera au hash ce que AES est au chiffrement: la solution estimé la meilleure par
                    > la communauté de la cryptographie. Contrairement à DES et SHA-(0,1,2) qui avaient été
                    > poussé unilatéralement par le NIST (et donc la NSA).

                    Désolé mais tu te contredie sur les deux dernières lignes. C'est une procédure NIST dans les deux cas. Pour moi, la communauté intervient plus de nos jours on va dire dans leur procédure mais cela reste du NIST. Bref, ton argumentation n'est pas bien développé à ce niveau là si tu cherches à convaincre quelqu'un.
                    • [^] # Re: MD6

                      Posté par . Évalué à  7 .

                      > OK, le lien est quand même faible. Ils suivent la même procédure.

                      Ils suivent le même processus, dans le même but, et ne sont tout les deux que des alias vers un des algos proposé. AES c'est rindjael avec trois longueur de clé. SHA-3 sera l'un des 14 algorithmes encore en course. C'est sur qu'il n'y a aucun rapport.

                      > Désolé mais tu te contredie sur les deux dernières lignes. C'est une procédure NIST dans les deux cas. Pour moi, la communauté intervient plus de nos jours on va dire dans leur procédure mais cela reste du NIST. Bref, ton argumentation n'est pas bien développé à ce niveau là si tu cherches à convaincre quelqu'un.

                      C'est chapeauté par la même organisation. Ca ne contredit en rien ce que je dis.

                      Avant le NIST arrivait avec son algo made in NSA et l'imposait comme standard. Personne n'a jamais eu vraiment confiance en DES. De même le changement entre SHA-0 et SHA-1 n'a, je croi,s jamais été justifié par la NSA (c'est pas mon domaine, corrigez moi si j'ai faux).

                      Pour AES et SHA tu as une procédure ouverte à la communauté, qui a satisfait tout le monde dans le cas d'AES. Pour citer bruce scheier "I have nothing but good things to say about NIST and the AES process", http://www.schneier.com/crypto-gram-0010.html#8

                      Après tu penses ce que tu veux...
                      • [^] # Re: MD6

                        Posté par (page perso) . Évalué à  2 .

                        Je ne dis pas que ce que tu penses est faux, je dis juste que pris comme cela, tes deux paragraphes se contredisait par manque de clareté. J'avais bien compris ou tu voulais en venir et tu as donné exactement ci-dessus la différence entre les deux époques.

                        Ceci dis, comme dis dans un autre post, l'UE a aussi lancé sa propre procédure mais on voit qu'on n'a pas encore le poids des USA car tout le monde va se lancer dans la solution des USA (même si le processus est ouvert à la communauté).

                        Dans mon boulot de tout les jours, je n'ai pas vu encore une seule fois les retours des approches internes à l'UE.

                        Sinon, tout cela est bien beau mais tant que le hash de Windows n'aura pas de grain de sel, on sait ou est le trous. A mon sens, il vaut parfois mieux un hash pas terrible à grain de sel plutôt que l'engin de mort sans sel.
                        • [^] # Re: MD6

                          Posté par (page perso) . Évalué à  2 .

                          Ceci dis, comme dis dans un autre post, l'UE a aussi lancé sa propre procédure mais on voit qu'on n'a pas encore le poids des USA car tout le monde va se lancer dans la solution des USA (même si le processus est ouvert à la communauté).

                          Je dirais plutôt : ceci dit, vu que le concours est ouvert et transparent, pourquoi l'UE a besoin de faire un autre concours à côté?
                          C'est normal que tout le monde se lance dans la solution des USA, et c'est normal que personne n'ai envie de s'emmerder avec un truc europaneo-européen.

                          On va prendre SHA-3 pour le monde entier, et on n'en parle plus.
                          • [^] # Re: MD6

                            Posté par (page perso) . Évalué à  1 .

                            Sauf que si j'ai bien compris, le concours de l'UE a eu lieu avant ;-)

                            Pourquoi les américains ne prennent-il pas la solution européenne ?

                            Comme je l'ai déjà, un hash sans grain de sel ne sers à rien dans pas mal de cas. Ou sont les grains de sels dans ce que je vois ?
                            • [^] # Re: MD6

                              Posté par . Évalué à  2 .

                              en français on dit soit "sel" (traduction littéral de salt), soit graine (seed), mais rarement les deux.
                            • [^] # Re: MD6

                              Posté par . Évalué à  5 .

                              > Comme je l'ai déjà, un hash sans grain de sel ne sers à rien dans pas mal de cas. Ou sont les grains de sels dans ce que je vois ?

                              C'est triste de ne pas comprendre (ou de ne pas vouloir comprendre) à ce point là l'objet du concours SHA-3.

                              SHA-3 à pour but de sélectionner une "cryptographic hash function", c'est à dire une fonction qui a les propriété suivantes:
                              - Il est facile de calculer le hash pour n'importe quel message
                              - Il n'est pas possible de générer un message ayant un hash donné
                              - Il n'est pas possible de modifier un message sans changer son hash

                              Où as tu vu que l'on cherchait à standardiser un password scheme ou un password hash ?

                              Tu me sembles tout mélanger. Le fait que crypt fasse sa tambouille interne en utilisant des fonctions de hashage comme MD5, SHA-[256||256] ou des block cypher (DES, Blowfish), t'a certainement induit en erreur. Les fonctions de hashages peuvent servir de bases pour élaborer un algorithme de password hash mais c'est tout. Le plus marrant c'est que l'algo à base de MD5 à plus la réputation d'être expérimental (made in PHK tout de même) plus que conçu cryptographiquement... Les implémentations sur les autres plateformes se contentant de copier celle de FreeBSD en mettant du genre:

                              195 /* The original implementation now does something weird: for every 1
                              196 bit in the key the first 0 is added to the buffer, for every 0
                              197 bit the first character of the key. This does not seem to be
                              198 what was intended but we have to follow this to be compatible. */



                              Ca reste dommage de mélanger des choses aussi grossières, quand on donne des lecons...

                              Un très bon papier d'OpenBSD sur la conception de bcrypt qui explique les principes d'un password scheme et d'une fonction de password hash: http://www.openbsd.org/papers/bcrypt-paper.ps

                              Le code source de la glibc http://repo.or.cz/w/glibc.git?a=tree;f=crypt;hb=HEAD des choses comme md5-crypt.c valent le coup d'oeil
                              • [^] # Re: MD6

                                Posté par (page perso) . Évalué à  1 .

                                Je ne mélange rien du tout.

                                Simplement, il y a un débat qui tourne sur les hash de mot de passe et je rappelle qu'il est important de mettre du sel dedans, ce que ne fait pas Microsoft.

                                Je sais très bien de quoi je parle et si je met le sujet sur le tapis, c'est que je suis sur que pas mal ici font des applications web avec mot de passe sans sel ! Donc avoir une super fonction de hash sans sel pour les mots de passe, c'est d'la daube !

                                Bien sur que les fonctions de hash servent à autres choses et qu'alors, le sel n'est pas important.

                                Maintenant, peux-tu m'assurer que toutes tes appli web utilisent du sel et tu reviendras avec tes commentaires. Même si c'est pas l'objet direct du concours, la taille du sel est une question qui mérite aussi d'être posé et justement c'est le moment.

                                Tu sais dimensionner la taille du sel pour une fonction de hachage donnée pour avoir une bonne sécurité sur les mots de passe ? Moi non.
                                • [^] # Re: MD6

                                  Posté par . Évalué à  2 .

                                  Mouarf !

                                  Pourquoi mettre du sel dans les mots de passe des web apps ? Les mots de passe sont enregistrés en clair, sinon on ne peut pas l'envoyer par mail à l'utilisateur qui a répondu à ses « questions de sécurité. »

                                  Mais bon, vu comment sont codées la plupart des applications, il est certainement plus facile d'entrer par XSS, injection SQL, hijack de session ou snif mail que par brute force sur les mots de passe... Je suis pour les châtiments corporels contre les devs qui pondent ce genre d'atrocités, mais mon chef m'a répondu qu'on aurait trop de pertes ;-)
                                  • [^] # Re: MD6

                                    Posté par (page perso) . Évalué à  2 .

                                    C'est pas toujours le cas. Dans sympa par exemple, la procédure permet de ré-initialiser le mot de passe, pas de le renvoyer...

                                    Mais bon, c'est bien ce que je disais, il y a du boulot pour former les concepteurs de site web...
                                  • [^] # Password en base???

                                    Posté par (page perso) . Évalué à  1 .

                                    Les mots de passe sont enregistrés en clair, sinon on ne peut pas l'envoyer par mail à l'utilisateur qui a répondu à ses « questions de sécurité. »

                                    Ouch.
                                    Ca fait mal de lire ça.
                                    Un bon développeur ne stocke jamais un mot de passe.

                                    Répète après moi : je ne mettrai jamais de mot de passe en clair dans mes bases de données.

                                    Je suis pour les châtiments corporels contre les devs qui pondent ce genre d'atrocités, mais mon chef m'a répondu qu'on aurait trop de pertes ;-)

                                    Je suis pour les châtiments corporels contre les devs qui pondent des mots de passes en clair ;-).

                                    Il y a plein de moyens de gérer les pertes de password (envoi d'un password temporaire etc...)
                                    Quand je vois des sites qui m'envoient mon mot de passe en clair dans le mail de confirmation d'inscription, j'ai envie de hurler... Bonjour la sécurité.
                                    • [^] # Re: Password en base???

                                      Posté par (page perso) . Évalué à  4 .

                                      Tu as dû lire un peu vite, il est aussi contre ce genre de pratique.

                                      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                                      • [^] # Re: Password en base???

                                        Posté par . Évalué à  1 .

                                        C'est clair que je suis contre !

                                        Mais bon, j'ai eu le malheur de bosser de près ou de loin pour des banques, des sites d'opérations boursières, des grandes surfaces (et leurs cartes de fidélité/paiement), et d'autres trucs bien sensibles... j'aurais préféré ne jamais voir ça, je suis maintenant complètement parano ! Et pourtant, la sécurité n'est pas ma spécialité. Quand je peux faire changer les choses, je le fais, mais il est difficile de contredire directement un client qui ne comprend rien à la technique. On m'a même répondu une fois que les fraudes restaient à un « niveau acceptable » et qu'ils préféraient payer pour que leurs utilisateurs aient accès à un « meilleur service » (envoi du mot de passe saisi par l'utilisateur en clair dans un mail, enregistrement du mot de passe en clair à côté du MD5, utilisation de « questions de sécurité » fermées et obligatoires, envoi du mot de passe original sur n'importe quelle adresse mail si on a répondu correctement à une des trois questions sans même un avertissement à l'adresse de contact).

                                        Je ne sais vraiment plus quoi faire...

                                        Je crois que les banquiers à qui j'ai demandé de désactiver l'accès à mes comptes en ligne n'en sont toujours pas revenus :-/
                                        • [^] # Re: Password en base???

                                          Posté par (page perso) . Évalué à  1 .

                                          > On m'a même répondu une fois que les fraudes restaient à
                                          > un « niveau acceptable » et qu'ils préféraient payer pour que leurs
                                          > utilisateurs aient accès à un « meilleur service »

                                          La sécurité est un compromis. Bienvenue dans la vraie vie. Je te suggère de lire Bruce Schneier : http://www.schneier.com/essay-150.html
                                          Et Marcus Ranum pour l'avis opposé : http://www.ranum.com/security/computer_security/editorials/l(...)

                                          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question. | Free Softwares Users Group Arlon, Belgique : http://fsugar.be/

                                        • [^] # Re: Password en base???

                                          Posté par . Évalué à  3 .

                                          De toutes façons à quoi bon crypter, même en salant, un code secret servant de mot de passe pour accéder à un service bancaire lorsque celui-ci se compose de 6 chiffres...
                                          • [^] # Re: Password en base???

                                            Posté par (page perso) . Évalué à  2 .

                                            De toutes façons à quoi bon crypter, même en salant, un code secret servant de mot de passe pour accéder à un service bancaire lorsque celui-ci se compose de 6 chiffres...

                                            Bon, ça élimine pas déjà pas mal de banques, à force de donner des infos on va connaitre ta banque ;-)

                                            Sinon, le code d'une CB est pire c'est même 4 chiffres.
                                            Mais ça ne dérange aucunement : la CB ou la banque se verrouillant au bout de X tentatives (X étant souvent 3), le fait que tu ai 6 chiffres ou 10000 chiffres pose le même problème au casseur : il n'a que 3 essai. Certes, sur 6 chiffres, ça fait"déjà" 0.003% de chances de réussite, "suffit" de voler 30 000 numéros de comptes, mais bon, après tu a 90% de chances de tomber sur un compte d'une personne qui a 100€ sur son compte, est-ce vraiment rentable?

                                            Trop de sécurité tue la sécurité, un code à 6 chiffres est de mon point de vue un niveau adapté, et même 4 chiffres, car on voit avec les stats de fraude CB qui n'a que 4 chiffres que ce n'est pas par le cassage du code que les fraudeurs passent (vol du numéro pour commander par internet, pays qui n'ont pas encore le code, code donné sous la contrainte)
                                            • [^] # Re: Password en base???

                                              Posté par (page perso) . Évalué à  2 .

                                              car on voit avec les stats de fraude CB qui n'a que 4 chiffres que ce n'est pas par le cassage du code que les fraudeurs passent

                                              Parce qu'il n'y a que 3 tentative. Si cette limitation n'existait pas, le bruteforce serait beaucoup plus utilisé. Si on instaure une limitation de 3 essai sur Internet, tu te fais vite bloquer ton compte.

                                              « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                                              • [^] # Re: Password en base???

                                                Posté par (page perso) . Évalué à  2 .

                                                Si on instaure une limitation de 3 essai sur Internet, tu te fais vite bloquer ton compte.

                                                Je vais t'étonner : c'est fait sur Internet aussi.
                                                Je te propose d'essayer sur ton numéro de compte bancaire si tu ne me crois pas.

                                                Tu as un couple login/password, le login (ton numéro de compte Internet de ta banque) est aussi "secret".

                                                Si un fraudeur dispose de ton numéro Internet bancaire, oui la banque bloquera au bout de 3 essais, la sécurité étant compromise.

                                                Donc non, la brute force n'est pas possible pour un compte bancaire aussi, la sécurité est suffisante, CQFD.

                                                Pour les comptes bancaires, la fraude est surtout sur le fishing (récupération login/code), donc ajout de sécurité supplémentaire (codes uniques pour les virements...)
                                                Mettre un code à 100 chiffres ne résoudrait pas le problème du fishing, ça ne ferait que te rassurer sur la sécurité sans raisons.
                                                • [^] # Re: Password en base???

                                                  Posté par (page perso) . Évalué à  2 .

                                                  Je ne suis pas dans une banque française. De plus, pour m'identifier à ma banque j'utilise un digipass qui calcule un nouveau mot de passe à chaque fois en fonction de mon code pin. (Je peux aussi utiliser un logiciel qui a la même fonction aussi disponible sous Linux (paquet deb ou tar.gz).

                                                  Mais ce système me¹ semble un peu bancal, si quelqu'un lance des attaques sur des comptes calculer au hasard, ça peut vite faire chier des gens non?

                                                  ¹: je ne suis pas spécialiste de la sécurité, cette avis ne se base que sur ce que je connais.

                                                  « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                                                  • [^] # Re: Password en base???

                                                    Posté par (page perso) . Évalué à  2 .

                                                    Personnellement, j'ai un numéro de contrat, un mot de passe et une carte avec 100 codes différents. Quand j'en ai utilisé 90, la banque me renvoie une nouvelle. Si j'ai plus que 3 tentatives échouées le compte est bloqué. En même temps, c'est une banque Suisse.

                                                    "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                                            • [^] # Re: Password en base???

                                              Posté par . Évalué à  1 .

                                              « car on voit avec les stats de fraude CB qui n'a que 4 chiffres que ce n'est pas par le cassage du code que les fraudeurs passent »

                                              Parce que la sécurité ne repose pas exclusivement sur le code/mot_de_passe, mais aussi par le nombre de tentatives autorisées, ce qui peut par contre servir à générer des dénis de service...

                                              Pour en revenir au code à 6 chiffres, ce que je signalais c'était simplement qu'un code ou un mot de passe faible, qu'ils soient cryptés et/ou sallés, n'offrent intrinsèquement qu'une sécurité très limité. Il faut par conséquent complété cette sécurité par d'autres mécanismes.
                                    • [^] # Re: Password en base???

                                      Posté par (page perso) . Évalué à  1 .

                                      > Un bon développeur ne stocke jamais un mot de passe.

                                      Un bon développeur stocke le mot de passe. Comme ça on peut faire du challenge-response pour les authentifications futures sans que le mot de passe ne circule sur le réseau (TLS ou pas).

                                      En fait, j'avais réfléchi au problème récemment et je me disais que l'idéal serait peut-être de stocker la moitié du mot de passe, un hash salé de l'autre moitié et le sel lui même. De cette manière, on a l'avantage de ne jamais faire passer le mot de passe complet sur le réseau (hors initialisation) et de ne pas stocker le mot de passe complet. L'attaquant doit pouvoir à la fois observer le réseau et accéder à la base de données.

                                      Détail d'implémentation : évidemment on va découper un hash du mot de passe original et non le mot de passe original, histoire de minimiser les risques si une des moitiés du mot de passe est faible. Cependant, ce hash suffit à l'authentification donc du point de vue d'un attaquant c'est aussi intéressant que le mot de passe et il doit donc être traité comme tel.

                                      Bon en fait, soit cette méthode a déjà été formalisée et implémentée par quelqu'un d'autre, soit il y a un truc qui m'échappe qui la rend inutilement compliquée.

                                      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question. | Free Softwares Users Group Arlon, Belgique : http://fsugar.be/

                                      • [^] # Re: Password en base???

                                        Posté par (page perso) . Évalué à  -1 .

                                        Si seul le fait qu'on puisse aussi espionner le réseau t'embête, pourquoi ne pas faire un challenge-réponse sur les hashs ? Un MD5 ou autre peut être calculé sur le client de la même façon que sur le serveur (SHABAL seulement si le client est costaud).
                                        • [^] # Re: Password en base???

                                          Posté par . Évalué à  3 .

                                          C'est le principe de l'authentification NTLMv1 sur les réseaux microsoft. Le hash joue ainsi le rôle du mot de passe et sa valeur est suffisante pour s'authentifier, il devient alors inutile de casser le hash pour retrouver le mot de passe original.
                                      • [^] # Re: Password en base???

                                        Posté par . Évalué à  1 .

                                        Un bon développeur stocke le mot de passe. Comme ça on peut faire du challenge-response pour les authentifications futures sans que le mot de passe ne circule sur le réseau (TLS ou pas).

                                        Pas besoin de stocker le mot de passe pour ça. Tu fournis deux graines au client, l'actuelle et la prochaine, le client te retourne la réponse pour les deux graines, tu compares l'actuelle et si elle est bonne tu mets la prochaine à la place de l'actuelle dans la base.
                                        • [^] # Re: Password en base???

                                          Posté par . Évalué à  3 .

                                          Dans ce cas la réponse pour la seconde graine joue le rôle du mot de passe pour la session suivante. La surveillance du canal de communication permet alors d'obtenir l'authentifiant. En plus la corruption du canal de communication peut engendrer une impossibilité d'établir une nouvelle authentification.
                                      • [^] # Re: Password en base???

                                        Posté par (page perso) . Évalué à  2 .

                                        J'ai l'impression que ce que j'ai décrit ressemble un peu à Augmented Encrypted Key Exchange: a Password-Based Protocol Secure Against Dictionary Attacks and Password File Compromise de Steven M. Bellovin et Michael Merritt.
                                        http://scholar.google.com/scholar?cluster=174278290914243224(...)

                                        /me va creuser ça (peut-être)

                                        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question. | Free Softwares Users Group Arlon, Belgique : http://fsugar.be/

                                    • [^] # Re: Password en base???

                                      Posté par (page perso) . Évalué à  3 .

                                      Un bon développeur ne stocke jamais un mot de passe.

                                      Quand il a le choix. Imaginons que tu veuilles proposer de la téléphonie SIP. Ce protocole ne prévoit que le HTTP Digest pour l'identification. Pas de bol, HTTP Digest c'est du défi-réponse, donc le mot de passe doit être stocké en clair.
                                      • [^] # Re: Password en base???

                                        Posté par (page perso) . Évalué à  2 .

                                        Je ne suis pas un bon développeur donc j'ai des passwords à la con dans mes .htaccess (heureusement ,ce sont des sites à la con), mais sur le principe si j'en crois http://en.wikipedia.org/wiki/Digest_access_authentication :
                                        The password is not used directly in the digest, but rather HA1 = MD5(username:realm:password). This allows some implementations (e.g. JBoss DIGESTAuth) to store HA1 rather than the clear text password.

                                        --> Le bon développeur doit choisir de bons outils.
                                • [^] # Re: MD6

                                  Posté par . Évalué à  5 .

                                  Quand on est un bon développeur on ne réinvente surtout pas roue; surtout pour ce qui concerne la sécurité. Si ton système ou les bibliothèques de ton environnement de développement fournissent une fonction telle que crypt() alors tu l'utilise et c'est tout.
                                  Si vraiment il n'y a pas d'implémentation disponible; alors tu réimplémentes un standard en faisant super super super attention. Donc tu cherches "key derivation function" dans google; puisque c'est de ca dont il s'agit. Tu tombes sur des trucs comme PBKDF2, bcrypt ou scrypt, c'est fait pour. Si tu poses des questions comme "comment utiliser MD5 (une "cryptographic hash function") pour hasher un password", alors là, effectivement, tu es mal barré...

                                  Donc si, tu mélanges tout et tu le fais avec assurance. Le débat sur les KDF c'est toi qui l'a amené dans un journal qui n'avait strictement rien à voir. Encore dans ce commentaire tu confonds allègrement les deux types de fonctions.

                                  Après si 90% des devs et des admins sont pas capables de se documenter correctement sur un sujet, de trouver un standard, ou s'en foutent éperdument; le problème il est entre la chaise et le clavier. C'est pas du tout mon domaine, mais quand j'ai quelque chose à implémenter, je prends 1h pour me documenter sur le sujet. Libre a toi de vouloir continuer d'utiliser un marteau ("cryptographic hash function") plutôt qu'un tournevis ("key derivation function") pour enfoncer une vis...
                                  • [^] # Re: MD6

                                    Posté par (page perso) . Évalué à  -1 .

                                    Monsieur le prétentieux qui sais tout, je ne vous répondrais plus.

                                    Moi, je suis admin système et je peux te dire que des mots de passe sans sel, j'en vois... Alors, toi tu es parfait, sur parfait mais la pratique ne l'est pas. Pour reprendre un dernier exemple, dans OpenLDAP, tu as le choix entre plein de hash dont SHA et SSHA. Le premier n'est pas bon sauf raison particulière, combien l'ont pris sans savoir ?

                                    Donc prends le de haut et les choses vont s'améliorer d'elle même ! Et puisque tu penses qu'une news sur les hash n'est pas l'occasion de parler des mots de passe, nous ne sommes pas du tout sur la même longueur d'onde.

                                    Continue comme cela mais sans moi, je n'aime pas les développeurs qui rayent le paquet.
                                    • [^] # Re: MD6

                                      Posté par . Évalué à  2 .

                                      Le SSHA correspond au SHA du mot de passe concaténé avec le sel. C'est certes plus intéressant que du SHA simple puisque le sel, s'il est généré convenablement, protège du cassage à l'aide de tables pré-calculées (comme les fameuses rainbow tables). Cependant cela ne protège pas d'une recherche exhaustive (brute force) si le mot de passe utilisé à la base est faible.

                                      Si matériellement c'est possible, il vaut mieux utiliser un mot de passe à la MD5 freebsd par exemple (le fameux mot de passes unix commençant par $1$... sachant que maintenant la palette s'est agrandie $2$ du blowfish mais aussi $5$, $6$ avec sha256 et 512.
                                      • [^] # Re: MD6

                                        Posté par (page perso) . Évalué à  2 .

                                        Le SSHA correspond de mémoire au $5$ qui est donc mieux que celui a base de MD5...

                                        Pour avoir fait des essais de cassage par brute force sur plus de 400 comptes il y a quelques années, je peux te dire que les mots de passe historique d'UNIX (triple DES avec sel) sont plus solides que ceux de Windows... Du coup, ayant à l'époque des anciennes stations UNIX, j'avais laissé mes utilisateurs avec des hash 3DES. En effet, avec les tables pré-calculés, les mots de passe Windows tombent en quelques secondes pour une grande partie d'entre eux. Les mots de passe 3DES avec sel tombent, en plus faible quantité et bien moins vite. Il doit y avoir plus de 20 ans entre les deux implémentations !

                                        Bref, je vois dans ton autre post que pour toi, le sel n'est pas si important que cela. Je dis que non, le SEL est un composant essentiel du hachage du mot de passe au même titre que la qualité de la fonction de hachage.

                                        Je suis ahuris que tant de personne puisse encore hacher les mots de passe sans sel et puisse penser que le sel n'apporte finalement pas grand chose. C'est une des bases de la sécurité d'UNIX. Le sel améliore sensiblement la protection contre la force brute et assure à 100% que deux personnes ayant le même mot de passe n'auront pas le même hash. C'est y pas bien ;-)
                                        • [^] # Re: MD6

                                          Posté par . Évalué à  1 .

                                          « Le SSHA correspond de mémoire au $5$ qui est donc mieux que celui a base de MD5... »

                                          Non, le SSHA c'est du SHA(mot_de_passe+sel)
                                          alors que le $5$ correspond à une boucle d'itérations de SHA (comme le fait le MD5 à la FreeBSD pour les mots de passe) de plus cette boucle est paramétrable au niveau de PAM sur Ubuntu par exemple où l'on peut fixer le nombre d'itérations à effectuer. (voir: man pam_unix et les paramètres sha256, rounds=n)

                                          « Bref, je vois dans ton autre post que pour toi, le sel n'est pas si important que cela. Je dis que non, le SEL est un composant essentiel du hachage du mot de passe au même titre que la qualité de la fonction de hachage. »

                                          Puisqu'il était question du SSHA, je maintiens que le gain de sécurité est surestimé, et qu'il vaut mieux utiliser un mot de passe du type $1$ si cela est possible car celui-ci fait intervenir une boucle de 1000 itérations, ce qui multiplie d'autant le temps de cassage par brute forcing par rapport à du SSHA.

                                          Et je n'ai jamais dit que le sel était inutile.

                                          « Le sel améliore sensiblement la protection contre la force brute et assure à 100% que deux personnes ayant le même mot de passe n'auront pas le même hash. »

                                          Le sel n'améliore réellement la sécurité, par rapport à une attaque par recherche exhaustive, que s'il existe des tables pré-calculées pour l'algorithme sans sel. A ma connaissance il n'y a pas de tables publiques pour SHA-256 et 512 ou pour Blowfish. A côté de cela il faut savoir que la constitution de tables précalculées est bien plus coûteuse qu'un cassage par brute forcing.

                                          Deux personnes ayant le même mot de passe, peuvent avoir le même hash si le sel est identique. Ce qui peut se produire si le programmeur est ignorant en la matière...

                                          Au final le sel n'est utile que s'il permet d'éviter la constitution de tables pré-calculées (il faut donc éviter les sels trop petits comme celui du DES) mais il ne limite en rien l'efficacité des attaques par recherche exhaustive, pour cela on utilise des boucles itératives. Reste à savoir si la façon dont sont organisées ces boucles ne génère pas non plus une faiblesse dans l'espace des hachés générés, mais c'est là un autre problème...
                                          • [^] # Re: MD6

                                            Posté par (page perso) . Évalué à  3 .

                                            Je suis 100% d'accord avec toi sur tout ce que tu dis. A vrai dire, j'ai encore des hash MD5 $1$ sur 95% de mes comptes, tout va bien ;-)

                                            Concernant le même hash pour deux personnes, j'ai mis 100% de différence car normalement, deux personnes ne devrait pas avoir la même graine. Là, on va dire que si cela arrive, c'est une bogue dans l'implémentation.

                                            Penser un algo pour se protéger des attaques par tables pré-calculées est tout aussi important que d'avoir un bon hash. Avec la RAM qui augmente et coute de moins en moins chère, avec les machines massivement parallèle, la prudence est de mise. Cette protection finalement par un petit ajout de complexité, fournit une garantie pour pas si chère. Il faut aussi savoir que l'attaque par table est fatale car les mots de passe tombent alors de manière "instantanée" ! C'est pas rien... Du coup, il faut changer d'algo en urgence normalement ce qui au niveau d'un SI central n'est jamais facile.
                                            • [^] # Re: MD6

                                              Posté par . Évalué à  1 .

                                              Pour se protéger contre les attaques par table, on peut aussi agir sur le choix du mot de passe. Par exemple les rainbow tables publiées ne prennent pas en charge les caractères accentués. Autre exemple sous windows, l'utilisation du symbole € (euro) empêche la génération et le stockage du haché LanMan (LM: Lan Manager Hash); cela a pour effet d'augmenter le temps d'un brute forcing puisqu'il faut se baser sur l'autre valeur de hachage (MD4) qui elle prend en compte la casse des caractères.
                                              • [^] # Re: MD6

                                                Posté par (page perso) . Évalué à  2 .

                                                C'est pas applicable directement malheureusement dans le milieu de la recherche. J'ai trop d'utilisateurs qui sont en qwerty et trop d'utilisateur qui se promène à l'étranger.

                                                Par contre, imposer petite lettre, grande lettre, chiffre ET symbole parmi les 8 premiers caractères complique grnadement la tâche de john...
                                                • [^] # Re: MD6

                                                  Posté par . Évalué à  1 .

                                                  Certains caractères du clavier qwerty se retrouvent rarement dans les tables, par exemple l'exposant 2 ( ² ) ou encore le symbole de la livre (£). On peut aussi allonger suffisamment la longueur du mot de passe pour rendre l'utilisation des tables impossible. Ainsi en utilisant un mot de passe (ou une phrase passe) de 15 caractères ou plus on se met à l'abri des tables fondées sur l'algorithme LM qui reste opérant pour les tailles inférieures ou égales à 14 (étant donné que le mot de passe est scindé en 2 pour le calcul du haché LM).
                                                  • [^] # Re: MD6

                                                    Posté par (page perso) . Évalué à  1 .

                                                    Il coupe à 8 en faisant deux fois 8. Il faut donc aller à 17 lettres...

                                                    C'est pour cela que j'imposais un mot de passe compliqué sur les 8 premières lettres. Imposer plus de 16 lettres, cela devient dur...
                                                    • [^] # Re: MD6

                                                      Posté par . Évalué à  1 .

                                                      Non, il coupe à 7 en faisant deux groupes de 7 octets (en complétant par des zéros s'il le faut). Chaque bloc de 7 octets fournit une clef de 7*8bits = 56 bits utilisées pour chiffrer suivant l'algorithme DES la chaine de 8 lettres : « KGS!@#$% » ; on obtient ainsi deux blocs finaux de 8*8bits = 64 bits, qui forment le haché LM de 128 bits.

                                                      Donc dès que l'on atteint 15 caractères le mot (ou la phrase) de passe n'est plus haché suivant l'algorithme LM.
                                • [^] # Re: MD6

                                  Posté par . Évalué à  1 .

                                  « Simplement, il y a un débat qui tourne sur les hash de mot de passe et je rappelle qu'il est important de mettre du sel dedans, ce que ne fait pas Microsoft. »

                                  Il faut aussi savoir que les mots de passe utilisés sous windows sont utilisés au niveau du réseau par un système de challenge-réponse-comparaison. En gros le poste client et le poste serveur effectuent le même calcul avec la valeur hachée du mot de passe de l'utilisateur, le client fournissant la réponse au serveur qui la compare avec son propre résultat.

                                  En conséquence de quoi c'est la valeur de hachage (stockée sur le serveur) qui joue le rôle du mot de passe au niveau de l'authentification sur le réseau. Donc peu importe la complexité du hachage mis en oeuvre, sel ou pas sel ça ne changerait rien à la faiblesse de l'authentification...
                              • [^] # Re: MD6

                                Posté par . Évalué à  2 .

                                « Il n'est pas possible de générer un message ayant un hash donné »
                                « Il n'est pas possible de modifier un message sans changer son hash »

                                Il s'agit là d'impossibilités toutes relatives.
                                * Le cassage de MD4 a été utilisé pour engorger le réseau P2P eDonkey.
                                * Et des collisions sur l'algorithme MD5 (deux fichiers postscripts différents mais de même valeur de hachage ou bien encore deux certificats différents mais de même signature) ont mis publiquement en évidence l'intérêt de passer à autre chose.
                          • [^] # Re: MD6

                            Posté par . Évalué à  2 .

                            C'est normal que tout le monde se lance dans la solution des USA, et c'est normal que personne n'ai envie de s'emmerder avec un truc europaneo-européen.

                            Airbus et Ariane sont des échecs commerciaux.
                            • [^] # Re: MD6

                              Posté par (page perso) . Évalué à  -2 .

                              Airbus ? J'ai vu pire, comme échecs, franchement.
                              • [^] # Re: MD6

                                Posté par (page perso) . Évalué à  2 .

                                Quelqu'un peut m'expliquer ce qui me vaut ce moinssage ?

                                Je ne sais pas si les Airbus se vendent bien ou non, mais en tout cas cette entreprise fait vivre la ville de Toulouse, a atteint le niveau de Boeing, et a d'ailleurs forcé ce dernier à évoluer un peu (après le 747, ils s'étaient complètement endormis, ça se voit en regardant l'intérieur d'un cockpit de Boeing, plein de cadrans analogiques dans tous les sens, comme il y a trente ans).

                                C'est un échec, vous trouvez ?
                                • [^] # Re: MD6

                                  Posté par . Évalué à  2 .

                                  Le moinssage est dû au fait que le commentaire auquel il répond était de l'humour, pour montrer que des projets 100% européens ont déjà fait leurs preuves !
                            • [^] # Re: MD6

                              Posté par . Évalué à  2 .

                              Tu peux ajouter Michelin, Renault, Areva, Dassaut, une boîte pharmaceutique dont j'ai oublié le nom, etc :-)
                              Beaucoup de français croient que nous sommes envahis par les autres, ce n'est pas vrai du tout. Et c'est à peu près la même chose pour les pays "évolués".
                              • [^] # Re: MD6

                                Posté par . Évalué à  2 .

                                La boîte pharma, c'est Sanofi-Aventis.
                                Sinon, il y a aussi Air Liquide, Total, Thomson...
                                • [^] # Re: MD6

                                  Posté par . Évalué à  2 .

                                  Ah oui Sanofi-Aventis, merci. C'est parceque j'habite une caverne que j'ai oublié le nom :-)

                                  Quelqu'un a des exemples pour la Belgique ?
                                  C'est un pays comparativement nettement plus petit que la France, on s'attend donc à avoir moins d'exemples. Nous sommes mutuellement assez proche "sentimentalement" (enfin pas pour tous, hum) mais je n'ai aucun exemple qui me vienne à l'esprit.
        • [^] # Re: MD6

          Posté par . Évalué à  1 .

          Une fonction de hachage est très loin de servir qu'à ça. L'intérêt d'un standard est justement qu'il soit utilisable pour tout le monde.

          Si tu veux une fonction de hashage lente et sécure, tu crées une clef RSA dont tu supprime la partie privé.
          • [^] # Re: MD6

            Posté par . Évalué à  1 .

            « Si tu veux une fonction de hashage lente et sécure, tu crées une clef RSA dont tu supprime la partie privé. »

            Non, ce n'est pas aussi simple que ça, si l'exposant choisi est petit (3 par opposition au 65537) et que le message est lui aussi petit alors on risque facilement de ne pas dépasser la taille du modulo et dans ce cas un simple calcul de racine cubique nous redonne la réponse...
        • [^] # Re: MD6

          Posté par (page perso) . Évalué à  4 .

          Pour preciser ce propos, comme ça l'a été demandé un peu plus bas, on pourrait meme dire : la vitesse est un PROBLEME pour les hashs de mots de passe.
          Voir à ce sujet le billet "Enough With The Rainbow Tables: What You Need To Know About Secure Password Schemes" sur le blog matasano (apparement, leur site est hors ligne en ce moment, je ne donne donc pas de lien mort, le cache google est votre ami).

          Pour resumer, la vitesse d'un algo utilisé pour du hash de mot de passe sert principalement l'attaquant, parce que ça va faciliter l'attaque "brute force".
          Par exemple, passer 100 fois plus de temps à calculer le hash lors du login est generalement negligeable, mais ce meme temps passé en plus multiplie par 100 la durée d'une attaque exhaustive.
          D'ou des algos genre bcrypt (dans OpenBSD), ou plus recemment scrypt (http://www.tarsnap.com/scrypt/).

          Bien sur, ce n'est pas du tout l'objet du concours SHA-3 !
          • [^] # Re: MD6

            Posté par (page perso) . Évalué à  -2 .

            Solution : emmerdé l'attaquant et ne pas perdre de temps CPU, un p'tit sleep bien placé pour ralentir la réponse...

            Sinon, il est abérrant qu'avec LDAP, on puisse mettre des hash de mot de passe sans grain de sel ! Sachant qu'il y a plein de mot de passe faible, ne pas mettre de grain de sel revient à dire que les hash des mots de passe ne valent rien, quel que soit l'algo !

            Bref, j'avais testé que les bons vieux MD5 avec sel, voire un triple DES avec grain de sel résiste mieux que certain algo plus moderne à la brute force.

            La technique du grain de sel est archi connu dans UNIX depuis des années, n'est toujours pas utilisé dans Windows et quand aux applications web, j'espère que oui mais je crains le pire...
            • [^] # Re: MD6

              Posté par . Évalué à  5 .

              Solution : emmerder l'attaquant et ne pas perdre de temps CPU, un p'tit sleep bien placé pour ralentir la réponse...

              Sauf si l'attaquant s'est procuré les hash et donc maîtrise l'implémentation de l'algorithme.
              • [^] # Re: MD6

                Posté par . Évalué à  3 .

                vous parlez pas de la même chose, toi tu parle d'une attaque off line, tandis que lui parle d'une attaque online.

                Sinon, le coup du "il faut prendre un hash plus lent parce que ca emmerde plus l'attaquant" ..., c'est relativement nul comme sécurité.
                Il faut mieux un hash qui s'execute très vite MAIS qui a son espace d'entrée/de sortie suffisament grand, et qui un vrai hash cryptographique (aucun moyen de corrélé l'entrée et la sortie) qu'une solution qui repose sur un hypothétique lenteur de l'algo.
                Tu fais quoi si l'attaquant sort une implémentation de ton hash en hard en O(1) (ou 15 000 fois plus rapide que le soft, serait plus juste, vu que pour un attaquant, n n'a pas besoin de varier) ?

                je rappellerais juste le proof of concept qui a existé sur les clés DES ;)
                • [^] # Re: MD6

                  Posté par (page perso) . Évalué à  2 .

                  Non, il vaut mieux quelque chose qui s'execute avec une vitesse parametrable, et qui bien sur a un espace IO suffisant. Evidemment, la lenteur de l'algo n'est pas la seule variable interessante, mais c'est un facteur determinant, sachant que quelque soit l'espace d'entrée, si tu es dans le cas d'un mot de passe, tu peux probablement donner comme limite superieure 100 caracteres ASCII (exemple au pif).
                  Pour ce qui est des attaques en hardware, c'est JUSTEMENT celles là que ces methodes essaient de contrer. Voici ce qui est ecrit sur la page de scrypt :

                  "We estimate that on modern (2009) hardware, if 5 seconds are spent computing a derived key, the cost of a hardware brute-force attack against scrypt is roughly 4000 times greater than the cost of a similar attack against bcrypt (to find the same password), and 20000 times greater than a similar attack against PBKDF2."
                • [^] # Re: MD6

                  Posté par . Évalué à  2 .

                  > Sinon, le coup du "il faut prendre un hash plus lent parce que ca emmerde plus l'attaquant" ..., c'est relativement nul comme sécurité.

                  Non, c'est dans les buts d'un password hash a fin de ralentir les possibilités de brute force offline. Ca passe par l'ajout d'un graine afin de ne pas pouvoir casser plusieurs mdp à la fois et d'éviter les rainbow tables, mais aussi par avoir un algorithme couteux, configurable et pas trop optimisable en hardware pour ralentir encore le processus. Le papier de bcrypt que j'ai donné plus haut l'explique bien.

                  Avec DES il était en effet possible d'implémenter en hardware pour pas cher un truc vraiment performant. Les algorithmes modernes essayent de faire en sortent qu'il ne soit pas possible d'optimiser significativement la vitesse de hashage pour un nombre d'itérations donné.

                  Tu viens de prouver exactement le contraire de ce que tu disais. DES est plus faible que bcrypt ou scrypt, entre autre, par ce qu'il est facilement optimisable en hard.
                  • [^] # Re: MD6

                    Posté par . Évalué à  2 .

                    mais aussi par avoir un algorithme couteux, configurable et pas trop optimisable en hardware pour ralentir encore le processus.
                    etc...

                    Ou comment faire reposer la sécurité sur un truc... non prouvé, non défini objectivement, et en esperant que l'attaquant sera aussi peu doué que nous pour le mettre en hard ou l'optimiser...

                    On as vraiment pas la même approche de la sécurité.
      • [^] # Re: MD6

        Posté par (page perso) . Évalué à  2 .

        La référence comparant les différentes fonctions de hachage se trouve à http://bench.cr.yp.to/results-hash.html .

        C'est un peu difficile à résumer mais globalement par machine on arrive à cerner les différentes performances.
  • # The SHA-3 Zoo

    Posté par . Évalué à  -2 .

    Une synthèse sur les candidats à SHA-3 : [http://ehash.iaik.tugraz.at/wiki/The_SHA-3_Zoo]
    • [^] # Re: The SHA-3 Zoo

      Posté par (page perso) . Évalué à  3 .

      Hum...ce ne serait pas le premier lien de la news par hasard ?
      • [^] # Re: The SHA-3 Zoo

        Posté par . Évalué à  6 .

        Ça m'étonnerait que ce soit un hasard.

        Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

        • [^] # Re: The SHA-3 Zoo

          Posté par . Évalué à  4 .

          Effectivement c'est une erreur, même si l'intitulé « Tous les candidats SHA-3 » juste après NIST aurait du faire référence à la page officielle du NIST...

          Non, voici donc une liste de vulnérabilités ou faiblesses informatiques découvertes dans les implémentations de quelques algorithmes soumis à candidature [http://blog.fortify.com/repo/Fortify-SHA-3-Report.pdf] .

Suivre le flux des commentaires

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