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 !
Aller plus loin
- Tous les candidats SHA-3 (39 clics)
- SHABAL (37 clics)
- Le fichier pdf qui présente SHABAL (46 clics)
- Article LinuxFR sur l'abandon progressif de SHA-1 (16 clics)
# Geek life
Posté par Dup (site web personnel) . Évalué à 10.
[^] # Re: Geek life
Posté par windu.2b . Évalué à 5.
# CubeHash
Posté par Kerro . Évalué à 3.
[^] # Re: CubeHash
Posté par khivapia . Évalué à 2.
On pourrait casser pas mal de systèmes de chiffrement avec une telle quantité de données !!
[^] # Re: CubeHash
Posté par Kerro . Évalué à 2.
D'après certains, ce serait un bon moyen de chauffage :-) http://blogs.sun.com/bonwick/entry/128_bit_storage_are_you
# À noter qu'une autre proposition française a atteint le même stade
Posté par khivapia . Évalué à 9.
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
[^] # Re: À noter qu'une autre proposition française a atteint le même stad
Posté par M . Évalué à 5.
skein [1] tourne a 6 cpb sur une core 2 64 bits.
il est aussi // sur plusieurs coeurs. On peut aussi l'optimiser avec du SIMD pour que l'implémentation X86 32 bits tourne en 20/10 cpb [2].
[1] http://www.skein-hash.info/about
[2] http://www.schneier.com/blog/archives/2009/07/sha-3_second_r(...)
[^] # Re: À noter qu'une autre proposition française a atteint le même stad
Posté par jcs (site web personnel) . Évalué à 6.
http://crypto.rd.francetelecom.com/echo/
À noter également que l'ENS et FT/Orange font partie du projet SAPHIR et ont participé à la conception de SHABAL.
# MD6
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
[^] # Re: MD6
Posté par jcs (site web personnel) . Évalué à 5.
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 Sytoka Modon (site web personnel) . Évalué à -1.
[^] # Re: MD6
Posté par suJeSelS . Évalué à 5.
[^] # Re: MD6
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
Pour les applications web des hébergeurs, ce n'est pas pareil.
[^] # Re: MD6
Posté par ckyl . Évalué à 2.
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 Sytoka Modon (site web personnel) . Évalué à 7.
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 ckyl . Évalué à 1.
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 patrick_g (site web personnel) . Évalué à 6.
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 Sytoka Modon (site web personnel) . Évalué à 3.
> 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 ckyl . Évalué à 7.
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 Sytoka Modon (site web personnel) . É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é).
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 Zenitram (site web personnel) . Évalué à 2.
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 Sytoka Modon (site web personnel) . Évalué à 1.
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 briaeros007 . Évalué à 2.
[^] # Expression totopopulaire
Posté par Kerro . Évalué à 5.
http://www.kecidi.com/general/mettre-son-grain-de-sel.html
[^] # Re: MD6
Posté par ckyl . Évalué à 5.
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 Sytoka Modon (site web personnel) . É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.
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 François B. . Évalué à 2.
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 Sytoka Modon (site web personnel) . Évalué à 2.
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 Zenitram (site web personnel) . Évalué à 1.
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 claudex . Évalué à 4.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Password en base???
Posté par François B. . Évalué à 1.
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 Krunch (site web personnel) . Évalué à 1.
> 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.
[^] # Re: Password en base???
Posté par croux . Évalué à 3.
[^] # Re: Password en base???
Posté par Zenitram (site web personnel) . Évalué à 2.
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 claudex . Évalué à 2.
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.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Password en base???
Posté par Zenitram (site web personnel) . Évalué à 2.
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 claudex . Évalué à 2.
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.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Password en base???
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Password en base???
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
[^] # Re: Password en base???
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Password en base???
Posté par croux . Évalué à 1.
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 Krunch (site web personnel) . É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).
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.
[^] # Re: Password en base???
Posté par Cédric Chevalier (site web personnel) . Évalué à -1.
[^] # Re: Password en base???
Posté par croux . Évalué à 3.
[^] # Re: Password en base???
Posté par Antoine . Évalué à 1.
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 croux . Évalué à 3.
[^] # Re: Password en base???
Posté par Krunch (site web personnel) . Évalué à 2.
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.
[^] # Re: Password en base???
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
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 Zenitram (site web personnel) . Évalué à 2.
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: Password en base???
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
[^] # Re: MD6
Posté par ckyl . Évalué à 5.
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 Sytoka Modon (site web personnel) . Évalué à -1.
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 croux . Évalué à 2.
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 Sytoka Modon (site web personnel) . Évalué à 2.
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 croux . Évalué à 1.
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 Sytoka Modon (site web personnel) . Évalué à 3.
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 croux . Évalué à 1.
[^] # Re: MD6
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
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 croux . Évalué à 1.
[^] # Re: MD6
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
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 croux . Évalué à 1.
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 croux . Évalué à 1.
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 croux . Évalué à 2.
« 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 Antoine . Évalué à 2.
Airbus et Ariane sont des échecs commerciaux.
[^] # Re: MD6
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à -2.
[^] # Re: MD6
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
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 windu.2b . Évalué à 2.
[^] # Re: MD6
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
[^] # Re: MD6
Posté par Kerro . Évalué à 2.
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 François B. . Évalué à 2.
Sinon, il y a aussi Air Liquide, Total, Thomson...
[^] # Re: MD6
Posté par Kerro . Évalué à 2.
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 Vincent Meurisse (site web personnel) . É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é.
[^] # Re: MD6
Posté par croux . Évalué à 1.
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 castorpilot . Évalué à 4.
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 Sytoka Modon (site web personnel) . Évalué à -2.
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 suJeSelS . Évalué à 5.
Sauf si l'attaquant s'est procuré les hash et donc maîtrise l'implémentation de l'algorithme.
[^] # Re: MD6
Posté par briaeros007 . Évalué à 3.
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 castorpilot . Évalué à 2.
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 ckyl . Évalué à 2.
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 briaeros007 . Évalué à 2.
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 Clément David (site web personnel) . Évalué à 2.
C'est un peu difficile à résumer mais globalement par machine on arrive à cerner les différentes performances.
# The SHA-3 Zoo
Posté par croux . Évalué à -2.
[^] # Re: The SHA-3 Zoo
Posté par patrick_g (site web personnel) . Évalué à 3.
[^] # Re: The SHA-3 Zoo
Posté par 2PetitsVerres . Évalué à 6.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: The SHA-3 Zoo
Posté par croux . Évalué à 4.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.