Discussion :

[Neckara]

d'utiliser bcrypt pour le hashage des mdp

Pas obligatoirement, tout algorithme de hash recommandé peut faire l'affaire.
Le plus important est surtout de suivre les recommandations au niveau des paramètres que tu donnes comme le sel.

Pour voir les recommandations, tu peux consulter celles de l'ANSSI ou d'autres organisations.

stocker le contenu hashé en BDD (1 champ) + 1 champ pour stocker le nombre d'itérations de hashage (1 champ)

En somme, il te faut stocker le hash ainsi que tous les paramètres permettant de le recalculer, à partir du mot de passe. Donc aussi le sel.

Quelqu'un pourrait me donner les bonnes pratiques dans la gestion des mdp ?

Je pense que tu peux retrouver des débuts de réponses dans des sujets similaires dans le forum de la rubrique sécurité et dans les articles de la rubrique.

Après, c'est une question très ouverte que tu poses et très générale, on pourrait écrire des livres à ce sujet. Le mieux serait peut-être que tu créés ton propre sujet pour expliciter ta question (?).

[Neckara]

Si tu tiens vraiment à utiliser une fonction sha* au lieu de blowfish, il faut se tourner vers PBKDF2 qui est d'ailleurs recommandé par le Department of Commerce pour ce genre d'usage

J'ai tout de même pris la peine de lire ton seul document sérieux.

Dès les premières lignes :

Abstract

This Recommendation specifies techniques for thederivation of master keys from passwords or passphrases to protect stored electronic data or data protection keys.

Tu es déjà en HS sachant qu'on parlait de, pour te citer, "stoquer un mot de passe."

[BufferBob]

tu bases ta sécurité sur l'idée que ton adversaire a des ressources limitées.

ben oui, c'est le propos de n'importe quel algorithme de chiffrement à l'heure actuel (à l'exception du masque jetable)
si j'avais un ordinateur assez puissant pour factoriser des nombres très grands très rapidement RSA ne serait plus considéré comme sûr lui non plus, et inversement si les ordinateurs actuels étaient moins puissants qu'ils le sont on aurait pas la patate suffisante pour attaquer MD5 qui serait du coup encore considéré comme safe
si j'osais je dirais qu'il suffit juste d'avoir un minimum de culture en sécurité et en informatique.

si je commence à utiliser des caractères spéciaux peu usuels comme "…"

sauf que c'est un caractère multibytes, donc chaque octet le composant sera chiffré/hashé indépendamment

ensuite on peut relever un certain nombre de contradictions dans ce que tu racontes :

<Neckara> Le sel est surtout utilisé pour contrer les attaques par dictionnaire. Une attaque par force brute se moque bien du sel.
<Neckara> Le sel n'est pas là pour se protéger des attaques par force brute.
VS
<Neckara> Avoir plusieurs sels d'origine différente peut être un plus
<Neckara> tout algorithme de hash recommandé peut faire l'affaire. (...) Le plus important est surtout de suivre les recommandations au niveau des paramètres que tu donnes comme le sel.

<Neckara> Un mot de passe "fort", ne peut pas être retrouvé par force brute.
<Neckara> le plus important, ce n'est pas la durée d'un test mais de la complexité de l'attaque.
<Neckara> Généralement, on ne fait pas une attaque par brute force directement, c'est beaucoup trop long
<Neckara> Une attaque par brute force sur un SHA512, c'est 2^512 possibités à tester !
VS
<Neckara> Pour une attaque par force brute, qu'on mette 1seconde ou 1nano secondes à calculer un hash, cela ne fait aucune différence si l'espace de départ (sans collisions) est suffisamment grand.
<Neckara> Une telle protection (tenter de rallonger la durée de calcul d'une possibilité) ne vaut rien face à des attaques par force brute.

<Aramiil> Par contre bcrypt est différent (...) un algorithme de chiffrement (en l'occurence, Blowfish, qui présente la particularité d'être lent)
<Neckara> les algorithmes de chiffrement, que tu recommandes, eux ne servent pas à ça !
<Aramiil> apprends ce qu'est le bcrypt et en quoi il _utilise_ mais _n'est pas_ un algorithme de chiffrement.
<Neckara> Je n'ai jamais affirmé cela.

et enfin quelques citations qui trouveraient facilement leur place dans les recommandations pour bien débattre (coucou à son auteur ) :

<Neckara> Tu te moques un peu de moi.
<Neckara> Tu mélanges un peu tout.
<Neckara> je pense m'y connaître un peu plus que toi dans le domaine .
<Neckara> Tu formules mal tes propos.
<Neckara> je suis très gentil comme vous pouvez le constater.

la dernière étant j'imagine destinée à ton public...

[Neckara]

ben oui, c'est le propos de n'importe quel algorithme de chiffrement à l'heure actuel (à l'exception du masque jetable)
si j'avais un ordinateur assez puissant pour factoriser des nombres très grands très rapidement RSA ne serait plus considéré comme sûr lui non plus, et inversement si les ordinateurs actuels étaient moins puissants qu'ils le sont on aurait pas la patate suffisante pour attaquer MD5 qui serait du coup encore considéré comme safe
si j'osais je dirais qu'il suffit juste d'avoir un minimum de culture en sécurité et en informatique.

… Sérieusement, parfois il faut se taire au lieu de dire n'importe quoi.

Pour reprendre mon exemple du SHA512, il faudrait multiplier (pour une attaque par brute force) ta puissance de calcul par… 2^412 !
Je ne sais pas si tu arrives à imaginer à quel point c'est un nombre immense !

Ensuite, pour le MD5, c'est surtout qu'on lui a trouvé des vulnérabilités. Pour le DES, en effet, il a été cassé à cause de la montée en puissance de calcul.


Pour d'autres types d'attaques, on se base sur des complexités exponentielles. C'est à dire que même si tu as une machine pourrie et ton adversaire tous les ordinateurs de la Terre, il n'aura toujours pas assez de puissance de calculs. Quand bien même il réussirait à obtenir cette puissance de calcul, il suffirait de rajouter juste 1 ou 2 caractères/itérations/… pour que cela redevienne impossible.

Une protection linéaire, si tu as une petite machine, tu vas y mettre 1seconde avec le mode le plus sécurisé. Si les machines actuelles ont un gain de puissance x10, il faudra, pour conserver le même niveau de sécurité, que tu y mettes… 10 secondes !
Donc celui qui ne peut s'acheter une machine ayant un minimum de performance, ne pourra pas bénéficier d'une sécurité.

Une protection linéaire, c'est se dire "mon adversaire n'aura pas de matériel X fois plus performant". Une protection exponentielle, c'est se dire "il est impossible que mon adversaire arrive à avoir les ressources suffisantes, et quand bien même, j'ai juste à modifier un paramètre (nombre d'itération/nombre de caractères) pour un coût très faible et cela redeviendra impossible."

sauf que c'est un caractère multibytes, donc chaque octet le composant sera chiffré/hashé indépendamment

Hein ????

Depuis quand ???
Tu ne fais quand même pas un hash par octet que je sache ?
Même pour le chiffrement par flux, le chiffrement de chaque octet est dépendant des octets précédents. Et je ne parle pas du chiffrement par bloc.

Ce qui compte, ce n'est pas le nombre de caractères, ou d'octets sur lesquels ils sont codé, mais le nombre de bit/octets d'informations/utiles.

ensuite on peut relever un certain nombre de contradictions dans ce que tu racontes

<Neckara> Le sel est surtout utilisé pour contrer les attaques par dictionnaire. Une attaque par force brute se moque bien du sel.
<Neckara> Le sel n'est pas là pour se protéger des attaques par force brute.

VS

<Neckara> Avoir plusieurs sels d'origine différente peut être un plus
<Neckara> tout algorithme de hash recommandé peut faire l'affaire. (...) Le plus important est surtout de suivre les recommandations au niveau des paramètres que tu donnes comme le sel.

Parce que les attaques par brutes forces ne sont pas les seules attaques existantes. Bien que d'autres types d'attaques peuvent partiellement s'appuyer sur de la brute-force.
Je te l'apprend peut-être.

<Neckara> Un mot de passe "fort", ne peut pas être retrouvé par force brute.
<Neckara> le plus important, ce n'est pas la durée d'un test mais de la complexité de l'attaque.
<Neckara> Généralement, on ne fait pas une attaque par brute force directement, c'est beaucoup trop long
<Neckara> Une attaque par brute force sur un SHA512, c'est 2^512 possibités à tester !
VS
<Neckara> Pour une attaque par force brute, qu'on mette 1seconde ou 1nano secondes à calculer un hash, cela ne fait aucune différence si l'espace de départ (sans collisions) est suffisamment grand.
<Neckara> Une telle protection (tenter de rallonger la durée de calcul d'une possibilité) ne vaut rien face à des attaques par force brute.

Où vois-tu la contradiction ?
Il faut que tu m'explique là…

Les attaques par forces brutes ne sont pas correctes car justement l'espace de départ est suffisamment grand.
Et j'ai déjà démontré que le fait de rallonger la durée de calcul d'une possibilité ne vaut rien, justement à cause de systèmes utilisant des pipelines. C'est donc que la sécurité contre les attaques par brutes forces est assurée par autre chose… comme l'espace de départ !

<Aramiil> Par contre bcrypt est différent (...) un algorithme de chiffrement (en l'occurence, Blowfish, qui présente la particularité d'être lent)
<Neckara> les algorithmes de chiffrement, que tu recommandes, eux ne servent pas à ça !
<Aramiil> apprends ce qu'est le bcrypt et en quoi il _utilise_ mais _n'est pas_ un algorithme de chiffrement.
<Neckara> Je n'ai jamais affirmé cela.

Ensuite, le principe est que pour hasher un texte (et donc le vérifier) il faut répéter un algorithme de chiffrement (en l'occurence, Blowfish, qui présente la particularité d'être lent) plusieurs fois pour forcer le calcul lui-même à être lent.

Tu disais ?

[BufferBob]

… Sérieusement, parfois il faut se taire au lieu de dire n'importe quoi.

tu m'étonnes...

[Neckara]

tu m'étonnes...

Les plaisanteries les plus courtes sont les meilleures.

C'est en effet assez comique de dire :

• le but est de rallonger la durée de calcul d'une possibilité pour éviter les attaques par brute force ;
• le SHA2 est vulnérable parce qu'il est trop rapide ;

Mais il faut s'arrêter au bout d'un moment de raconter des inepties.


Rajouter du temps de calcul, n'est qu'un effet de bord à l'augmentation du nombre d'itérations utilisés, ce n'est en rien un objectif.
Certaines attaques ont une complexité en O(X^N) où N est le nombre d'itération.

On va dire X = 2 et N = 100.
À un instant T, on considère qu'on a pas la puissance de calcul nécessaire pour une attaque.
Si la puissance de calcul est multipliée par 2^Y, on va augmenter la recommandation et ajouter Y étapes.
On va donc être effectivement plus lent. 100+Y itération, ou Y% plus lent.

Si, comme vous l'affirmez, la protection se fait grâce au rallongement du temps de calcul, il faudrait multiplier le nombre d'itération par… 2^Y ! On passe donc très facilement d'une seconde à plusieurs minutes, heures voir même siècles !
Et je vous ai démontré qu'avec des pipelines, cela ne sert à rien, seule la première série de hash sera lente à calculer.

EDIT : je vais peut-être expliciter.
Sans pipeline, si on prend 1seconde pour calculer un hash, si on veut en calculer N, il faudra 1xN = N secondes.
Avec un pipeline de T étages, le principe, c'est qu'on calcule jusqu'à T hash en même temps. À chaque cycle, on "décale" chaque hash de l'étage Ti à l'étage Ti+1 puis on ajoute un hash à calculer à l'étage T0 et on récupère un hash fini de calculé à l'étage final.

Donc au final, au début, le premier "hash" doit traverser T étages, donc il faut attendre T cycles. Mais le suivant arrivera à T+1 cycle, et le prochain à T+2, etc.
Donc pour calculer N hash, il faut T + N - 1 cycles. Donc en moyenne, le calcul d'un hash ne prendra que 1 cycle.

Les cartes graphiques ont un pipeline de quelques étages, mais on peut faire beaucoup mieux et beaucoup plus avec d'autres types de matériel. Donc au final, qu'importe le temps de calcul d'un hash, c'est négligeable, le plus important, c'est le temps de calcul d'une série de hash et, surtout, du nombre de hash à calculer.
[Fin édit]


Pour le SHA2, je vous ai montré que même avec toute la puissance de calcul que vous voulez, et quand bien même le calcul d'un hash soit rapide, vous n'arriverez pas à calculer tous les hashs possibles.


J'ai trouvé sur un blog, le temps qu'une personne a mise pour 100 000 hashs :

Temps total de SHA-512: 0.231705188751

Donc on va dire 500 000 hash en une seconde.

Waaa c'est énorme ! Panique !
500 000 ~= 2^19.
Bravo, plus que 2^493 secondes à attendre .



Il est normal de se tromper, mais il faut aussi reconnaître ses erreurs quand on nous les montre.
Tout le monde n'a pas eu de formation en sécurité, je peux le comprendre, mais persister malgré les preuves que je vous apporte…


EDIT : Vous n'avez peut-être pas conscience des grandeurs.
2^100, c'est 2^50 x 2^50.

Une seconde, c'est 10^9 ~= 2^30 nanosecondes
Une minute, c'est 60 secondes ~= 2^6 x 2^30 = 2^36 nanosecondes
Une heure, c'est 60 minutes ~= 2^6 x 2^36 = 2^42
Une journée, c'est 24h ~= 2^5 x 2^42 = 2^47
Une année, c'est 365 jours ~= 2^9 x 2^47 = 2^56
1 000 000 000 ans ~= 2^30 x 2^56 = 2^86

Je suis très gentil et très loin de 2^100 !
2^100 nanosecondes ~= 16 384 000 000 000 ans.

2^512… c'est 2^100 x 2^412.
Donc 2^100 x 2^100 x 2^100 x 2^100 x 2^100 x 4096.


Il est presque impossible de s'imaginer à quel point c'est grand.
Tu peux calculer autant de hash que tu veux en une nanoseconde, tu n'arriveras jamais à tous les calculer.

Oui, pas la peine de tous les calculer, il suffit de trouver le bon et c'est fini.
Chaque hash étant équiprobable, on espère trouver le bon en n'en calculant que la moitié.
Donc en calculer… 2^… 511 !
Pour avoir 1,6% de chance de trouver le bon, 2^506 hash à calculer !
Pour avoir 0,0000006 % de chance de trouver le bon, 2^498 hash à calculer !

Bref, tu as plus de chance de gagner à l'euro-million sans y participer !


EDIT : Vu que vous utilisiez Wikipédia pour argumenter, peut-être que cette citation, de la même source donc, finira de vous convaincre, si vous ne l'êtes pas encore. Bon, cela reste Wikipédia tout de même.
https://fr.wikipedia.org/wiki/Attaque_par_force_brute

L'attaque par force brute est une méthode utilisée en cryptanalyse pour trouver un mot de passe ou une clé. Il s'agit de tester, une à une, toutes les combinaisons possibles. Cette méthode est en général considérée comme la plus simple concevable. Elle permet de casser tout mot de passe en un temps fini indépendamment de la protection utilisée, mais le temps augmente avec la longueur du mot de passe. En théorie la complexité d'une attaque par force brute est une fonction exponentielle de la longueur du mot de passe, la rendant virtuellement impossible pour des mots de passe de longueur moyenne […]

En plus c'est en français donc pas vraiment d'excuse.

EDIT : Vous pourrez me remercier pour le cours gratuit.

[BufferBob]

Les plaisanteries les plus courtes sont les meilleures.

c'est donc pour ça que tu fais des pavés interminables

pour ma part c'est limpide depuis un moment déjà, je te réponds une dernière fois histoire de voir si tu vas tenter de m'expliquer les additions à ton prochain post

merci donc pour le cours gratuit, ton guide de la bienséance sur les forums et disons-le franchement, l'ensemble de ton intervention, c'est toujours aussi édifiant et instructif

[Neckara]

De toute façon, j'ai dit ce que j'ai à dire, j'ai argumenté, démontré puis prouvé ce que je soutenais.
Ainsi lorsqu'une personne lira vos bêtises, elle pourra au moins lire mes explications et ne pas se faire avoir.


J'apprécie tout de même la valeur de ton argumentation, qui, au lieu de contre-argumenter ou d'essayer de me montrer où tu penses que j'aurais pu faire une erreur dans mon raisonnement (personne n'est à l'abri d'une erreur), se contente de tenter des attaques ad-hominem ou de rechercher des pseudo-contradictions dans mes dires dévoilant au grand jour ton ignorance et ta bêtise.


J'ai été jusqu'à donner de longues explications, à rentrer dans les détails, faire des preuves pour être sûr que vous compreniez bien si quelque chose vous avait échappé ou, le cas échéant, vous donner l'occasion de me faire remarquer une faille dans mon raisonnement. Et en toute récompense du temps que j'ai donné, je me reçois des réponses d'une qualité argumentative bien piètre comme l'attestent tes dernières réponses.

J'apprécie bien que tu donne le lien de mon article, c'est toujours agréable d'avoir un peu de pub. Mais j'aurais bien apprécié que tu le lises et en applique un peu plus les conseils, bien que je reconnaisse qu'il n'est pas évident de tous les suivre en toutes circonstances et que nul n'est parfait, moi le premier.


La sécurité informatique est mon domaine, je sais tout de même un peu de quoi je parle. Je ne suis pas contre échanger ou argumenter avec un amateur ou un néophyte, et je suis prêt à reconnaître mes limites. Je ne suis pas infaillible et peu éventuellement commettre une erreur de raisonnement.
Je ne suis donc pas opposé à un échange argumenté. Mais pour avoir un échange argumenté, il faut être deux.

Sur ce je te souhaite une bonne soirée, et j'espère que tu seras un peu plus ouvert lors de nos prochaines discutions et que tu daigneras sortir un jour de ton ignorance.

[Neckara]

Bon, j'ai tout de même fait quelques recherches, comme quoi, cela ne tue pas.

Le bcrypt a en effet, mea culpa, une composante s'appuyant sur le fait qu'on considère que les mots de passes ont une longueur maximale, qu'on ne veut ou ne peut pas changer pour des raisons pratiques.
Donc oui, ils tentent effectivement de rallonger la durée de calcul d'un hash ce qui est une assez mauvaise idée comme je l'ai déjà prouvé.

Bon, les chercheurs ne sont pas non plus stupides et ont tenté de rendre l'optimisation sur GPU assez "difficile". Le GPU réduit donc le coût d'une attaque mais cela reste limité.

C'est un peu comme si on avait une fonction F(X) = f(X) = 2^X, et qu'on recommande un F >= 2^100, mais qu'on ne peut pas avoir X > 99 pour des contraintes diverses (ex. nombre de caractères maximums), on tente alors de faire un F(X, Y) = f(X)g(Y) où g(Y) = 2Y. Au final avec (X=99 et Y=1), on va réussir à atteindre les 2^100.
C'est donc une sorte de complément de sécurité, un peu comme on met des talonnettes pour être un peu plus grand, cela reste artificiel.

Sauf que c'est une protection de complexité linéaire avec tous les problèmes que cela pose et que j'ai déjà évoqué. Ce n'est donc pas une solution vraiment convenable/optimale, mais si on part du principe qu'on conserve un nombre de "caractères fixe" dans les mots de passe, actuellement, on ne sait pas faire vraiment mieux pour conserver une certaine sécurité au fil du temps.

Mais comme je l'ai déjà précisé, cette protection est vulnérable/inutile face à un système de pipeline.
Et ce qui devait arriver est donc en train d'arriver, les FPGA étant de plus en plus performant, le complément de sécurité en est très fortement diminué, je n'irais pas jusqu'à dire annulé, grâce à des optimisations d'implémentations.

La piste actuelle pour contrer les FPGA semble être de proposer des algorithmes utilisant plus de RAM (peut-être que d'autres pistes sont aussi étudiées) cf scrypt¹ (?), mais le matériel continuera à s'améliorer aussi. Donc le temps qu'on ai la puissance de calcul pour craquer un hash de mot de passes en force brute, on peut aussi avoir potentiellement eu le temps d'annuler le complément de sécurité grâce aux avancées technologiques.


L'autre solution est d'accepter d'augmenter la taille des mots de passes (ou d'utiliser d'autres moyens d'authentification comme des clés), dont la taille recommandée augmente bel et bien petit à petit. Si on accepte cela, l'utilisation d'algorithme de hash comme SHA2 ou SHA3 est parfaitement correct et sûr.


Voilà, c'était peut-être trop dur de me le faire remarquer au sein d'une remarque constructive (bon, encore fallait-il le savoir).
Au final, je n'avais pas tord dans mes démonstrations, mais dans les intentions de bcrypt, mea culpa. Donc vous pouvez reprendre mes démonstrations pour montrer les limites de bcrypt.

Voilà, c'est tout de même un peu plus constructif que certains précédents messages.


¹ Je n'ai pas regardé tous les détails, mais il semblerait que scrypt, pour certaines raisons, ne soit finalement pas plus performant que bcrypt, et ne soit donc pas la solution à ce problème qu'il tentait de résoudre.

[Neckara]

@SaiRictus Je t'ai trouvé une note technique de l'ANSSI, Recommandations de sécurité relatives aux mots de passe.
Rien de vraiment révolutionnaire, je ne sais pas s'il t'intéresse. Sinon, tu peux tenter de chercher d'autres recommandations de l'ANSSI.

Il faut tout de même prendre du recul sur 3.1 et 3.2, et ne surtout pas utiliser des dictons (e.g. 1haev2 : 1 homme averti en vaut 2), assez connus. Si cette pratique se répand, le mot de passe ne tiendra pas longtemps¹.

J'essaye de regarder si je trouve d'autres recommandations. Là j'ai un Tweet de la gendarmerie Nationale : https://twitter.com/Gendarmerie/status/430345930454212608/photo/1?ref_src=twsrc^tfw

Ils recommandent 12 caractères minimums, il y a quelques décennies, c'était 8. Comme quoi même en ayant bcrypt, on continue d'augmenter la taille des mots de passes.

¹C'est comme au loto, pour gagner et ne pas partager ses gains, il faut jouer ce que personne d'autre n'a joué. Si tout le monde utilise le même mots de passe, quelque soit sa force, il ne vaudra plus rien.


EDIT : Je continu de lire ce que je trouve sur bcrypt.
D'ailleurs il y avait un sujet sur DVP à ce sujet.
J'ai aussi trouvé quelques papiers pour ceux que ça intéresse :
https://www.usenix.org/legacy/event/...vos/provos.pdf
https://www.usenix.org/system/files/...14-malvoni.pdf
http://www.openwall.com/presentation...ient-Cracking/
https://www.emsec.rub.de/media/crypt...g14_bcrypt.pdf

[aserf]

Bonjour,

Aramii je ne suis pas tout as fait d'accord avec vous, si on prend 350 millions de test par seconde, il faut quand même en brut force quelle millions d'années pour cracké un md5.
16 xy 32 / 350 000 00 test par seconde / 3600 s / 24h / 365j = 30829380202302897682772,940442829 années (peut être que mes calcul sont faux, a verifier, mais les possibilités sont énorme)

l'ajout d'un sel permet de ne pas pouvoir utilisé les RT. ensuite ce que les développeur on fait pour récupérer les password il aurait pu le faire avec bcrypte de la même manière. Si bcrypte prend 5 fois plus de temps, a générer une clef il aurait juste mis 5 fois plus de temps pour avoir le même résultat.

le vrai problème est que les hacker on eu la base de donnée ET le code source avec la méthode de cryptage...

Cordialement,

[Neckara]

Aramii je ne suis pas tout as fait d'accord avec vous, si on prend 350 millions de test par seconde, il faut quand même en brut force quelle millions d'années pour cracké un md5.

En fait, on part du principe que le mot de passe va être dans un sous-domaine de départ très réduit par rapport à celui "permit" par md5 ou tout autre algorithme (domaine sans collisions).

En effet, on part de l'hypothèse qu'un mot de passe a, de facto, une taille "limite" (et -presque- atteinte) inférieure à la taille maximale possible avec l'algorithme utilisé ¹.
Cela pour des raisons pratiques, e.g. si le mot de passe est trop long, l'utilisateur ne pourra pas le retenir.

On accepte donc arbitrairement cette hypothèse. Ainsi on ne part pas du domaine de départ permit par MD5… mais à partir d'un sous-domaine arbitraire bien plus petit, qu'on pourrait nommer domaine des "mot de passes".

À 8 caractères avec 100 possibilités par caractères, on a que 100^8 possibilités, donc 10^16.
Donc, d'après tes chiffres, 285 714 286 secondes soit 217 années, si, 35 000 000 tests/secondes.
C'est déjà énormément moins que si tu utilisais toute le domaine possible permit par tout algorithme de hash, indépendamment de celui utilisé.

Bien qu'en se qui concerne md5 et SHA1, ces algorithmes sont en effet considérés comme craqué. Il est bien plus cohérent de parler de SHA2 ou SHA3 à la place.

Mais si on considère l'hypothèse de départ fausse, ou tout du moins pas encore atteinte, il n'y a aucun problème à utiliser du SHA2 sur des mots de passes suffisamment forts.
Dire que le SHA2 n'est pas adapté pour stocker des mots de passes, comme cela a pu être dit, est donc abusif, si on n'explicite pas se placer dans un référentiel où on considère arbitrairement l'hypothèse de départ juste.

Si bcrypte prend 5 fois plus de temps, a générer une clef il aurait juste mis 5 fois plus de temps pour avoir le même résultat.

Soit T(X) le coût de calcul de X hash.

Pour tout algorithme, on a T(X) <= X*T(1). à cause d'optimisations possibles (parallélisme, pipeline, coût matériel, consommation électrique, densité minimale d'un cœur, pré-calculs, étapes communes, caches, …).
Le but est bien évidement de rapprocher T(X) de X*T(1).
C'est pour cela que bcrypt tente d'empêcher les optimisation sur GPU.

Sauf que désormais, avec les FPGA, on peut réduire grandement les coûts… et on a pas fini.
Le jour où on atteindra T(X) ~= T(1) + (X-1)*k, bcrypt sera totalement cassé.

Donc si bcrypte coûte 5 fois plus pour générer un hash, cela aurait coûté moins de 5 fois plus à un attaquant.

Cf les papiers dont j'ai donné le lien dans mon message précédent.

l'ajout d'un sel permet de ne pas pouvoir utilisé les RT.

Je viens de m'apercevoir que j'ai fait un petit abus de langage. Quand je disais qu'un bon sel empêchera de faire des attaques par dictionnaires, j'aurais dû préciser "pré-calculé".
Quand on parle d'attaque par dictionnaire, on pense plus généralement à des dictionnaires non-précalculé. Désolé pour cet abus .

L'exécution d'une attaque par compromis temps-mémoire ou RT est plus performante qu'une attaque par brute force. J'ai en revanche oublié de prendre en compte le coût du précalcul.
En effet, si le sel respecte correctement les recommandations en vigueurs et surtout est unique pour chaque hash, on ne peut pas vraiment utiliser de pré-calcul donc on se retrouve avec des complexités pires qu'une attaque par brute force.

Dommage qu'on ne me l'ai pas fait remarquer plus tôt .

¹ d'autres travaux de recherches partent dans une autre direction en faisant en sorte que cette hypothèse soit fausse. Donc en cherchant comment faire pour ne pas avoir de facto une taille "maximale" à un mot de passe. Ou en cherchant des alternatives aux mots de passes.

[aserf]

Tous dépend, tu pars du principe que le mot de passe n'a que 8 caractères, si tu met dedans un sel de 100 caractères (3 guid par exemple), il est nécessaire de tester toutes les solutions s'il n'ont pas le sel. Et s'il retrouve une correspondance c'est la password avec le sel qu'il retrouve (mais la c'est pour moi presque impossible avec les temps de calcul nécessaire).
maintenant s'ils ont le sel et l'algo ... bhein peu importe la complexité ils n'ont effectivement que les password simples à tester ...

[Neckara]

maintenant si ils ont le sel et l'algo ... bhein peu importe la complexité ils n'ont effectivement que les password simple a tester ...

Effectivement, en sécurité informatique, on considère le sel et l'algorithme utilisé connu ou pouvant être connu. La connaissance de ces éléments ne doivent pas pour autant compromettre la sécurité du système.

En effet, on considère que la sécurité par l'obscurité ne fournit pas de réelle sécurité. Un attaquant pouvant potentiellement réussir à récupérer la BDD, le code source de l'algorithme, faire du reverse engineering…

[Stéphane le calme]

Ashley Madison : les gendarmes de la vie privée du Canada et de l'Australie assurent que le site trompait ses clients,
en brandissant une fausse récompense de sécurité

L’année dernière, Ashley Madison, le site canadien de rencontre en ligne entretenant l’adultère, a fait l’objet d’un piratage par un groupe de pirates qui se font appeler The Impact Team. Ces derniers ont menacé Avid Life Media (ALM, qui a changé de nom après le scandale et a opté pour Ruby), qui a dans son portfolio plusieurs sites de rencontres pour adultes, de divulguer les données de leurs utilisateurs si elle ne retirait pas d'Internet ses sites AshleyMadison.com et EstablishedMen.com. Leur demande n’ayant pas reçu de réponse favorable, ils ont décidé de publier une base de données de 36 millions d’utilisateurs de la plateforme qui contenait des informations comme des informations relatives au profil de l’utilisateur (nom, autodescription de l’utilisateur, profil recherché, code postal, date de naissance, etc.), les informations relatives au compte de l’utilisateur (utilisées pour faciliter l’accès au service Ashley Madison comme l’adresse mail fournie au moment de l’inscription, les questions de sécurité et les réponses ainsi que les mots de passe hashés) et les informations de paiement (le nom réel de l’utilisateur, l’adresse de facturation et les quatre derniers chiffres de la carte de crédit).

Si des chercheurs avaient déjà dénoncé la faiblesse de la sécurité du site, notamment le choix de la protection des mots de passe par la fonction de hash bcrypt, cette fois-ci c’est une enquête des autorités de protection de la vie privée du Canada et de l’Australie qui vient souligner les mauvaises pratiques de sécurité. D’après les résultats de l’enquête, bien qu’Ashley Madison encourageait l’adultère en proposant un « processus de gestion des risques dédié pour protéger les renseignements personnels », le site lui-même s’appuyait sur des pratiques de sécurité qui ne correspondaient pas aux normes et ne répondaient pas aux lois relatives à la vie privée.

L’un des problèmes était le manque d’éthique : sur sa page d’accueil, Ashley Madison avait porté la mention « Trusted Security Award » à la droite d’une médaille. Étrangement, c’était le seul site en ligne à porter une telle mention. Aussi, l’entreprise derrière le site a admis plus tard qu’il s’agissait d’une récompense factice et a décidé de la retirer.

De plus, comme l’avait déjà indiqué The Impact Team, malgré la suppression par l’utilisateur, la désactivation d’un compte ou même l’inactivité d’un profil (c’est-à-dire un profil qui n’a pas été consulté par son propriétaire depuis une longue période), Ashley Madison conservait en réalité les informations personnelles de ses clients à moins que les utilisateurs n’optent pour l’option payante afin de supprimer définitivement leurs données. Cette pratique n’était pas clairement définie dans la politique de confidentialité d’Ashley Madison.

L’analyse de l’étendue du piratage n’a pas pu être menée convenablement, en partie parce que les pirates ont pu élever leurs privilèges pour s’octroyer des privilèges administrateurs et effacer les logs qui auraient pu contenir des traces de leurs activités. Aussi, ALM a fait savoir à l’équipe d’investigation ainsi qu’aux individus affectés via un courriel de notification, qu’en dehors des numéros complets de carte de paiement, qui n’étaient en général pas enregistrés par ALM, « toutes les autres informations que les visiteurs ont fournies via Ashleymadison.com pourraient avoir été acquises par les pirates ». Ces informations comprennent les photos des utilisateurs, les communications entre eux et avec le personnel ALM, et d’autres informations en plus de celles qui avaient déjà été affichées par les pirates.

Les gendarmes de la vie privée canadien et australien ont donné une série de recommandations que Ruby a accepté de suivre comme par exemple fournir une option gratuite pour supprimer les informations des utilisateurs une fois qu’ils suppriment leurs profils (les utilisateurs devaient payer 15 dollars US).

« Les conclusions de ce rapport comportent des leçons importantes pour d'autres organisations qui détiennent des renseignements personnels. La leçon la plus largement applicable est qu'il est crucial que les organisations qui détiennent des renseignements personnels numériques adoptent des processus clairs et appropriés, des procédures et des systèmes pour gérer les risques relatifs à la sécurité de l'information, appuyés par une expertise adéquate (interne ou externe). Cela doit encore être plus vérifié dans le cas où les renseignements personnels détenus comprennent des informations de nature délicate qui, si elles étaient compromises, pourraient causer d'importants dommages à la réputation des personnes touchées ou à d'autres personnes. Les organisations qui détiennent des informations personnelles sensibles ou une quantité importante de renseignements personnels, comme ce fut le cas ici, devraient avoir des mesures de sécurité de l'information, y compris, mais sans s'y limiter :

• une ou plusieurs politiques de sécurité ;
• un processus de gestion des risques explicite qui aborde les questions de sécurité de l'information, en s’appuyant sur une expertise adéquate  ;
• des formations adéquates à la vie privée et à la sécurité pour l'ensemble du personnel. »

Source : rapport de la Commission de la vie privée (Canada), Ashley Madison (déclaration de Ruby)

Voir aussi :

19 % des consommateurs américains seraient prêts à délaisser un commerçant dont les données ont été piratées, d'après un récent sondage de KPMG

[rawsrc]

[B][SIZE=4]De plus, comme l’avaient déjà indiqué The Impact Team, malgré la suppression par l’utilisateur, la désactivation d’un compte ou même l’inactivité d’un profil (c’est à dire un profil qui n’a pas été consulté par son propriétaire une longue période), Ashley Madison conservait en réalité les informations personnelles de ses clients

Les gendarmes de la vie privée canadien et australien ont donné une série de recommandations que Ruby a accepté de suivre comme par exemple fournir une option gratuite pour supprimer les informations des utilisateurs une fois qu’ils suppriment leurs profils (les utilisateurs devaient payer 15 dollars US).

Quand on vous dit que vos informations (privées ou pas) valent une fortune, c'est pas des blagues...

On croit rêver, allez une dernière petite louchette (15 $) juste pour bien te faire sentir l'énorme manque à gagner quand l'utilisateur décide de supprimer son compte et ses données (quand elles sont réellement effacées... et pas, comme trop souvent, juste archivées et soi-disant inaccessibles).

[TheLastShot]

Un site de rencontre qui permet aux gens de tromper leur partenaire, et qui trompe ses clients... Malgré les problèmes éthiques évident de mon point de vue professionnel, du point de vue personnel j'aurais presque envie de dire que c'est une juste retour des choses =D

[Saverok]

après toutes les révélations en pagailles sur ce site, il n'y a rien de plus rien surprenant.

[NSKis]

après toutes les révélations en pagailles sur ce site, il n'y a rien de plus rien surprenant.

Il n'y a malheureusement pas que ce site qui pose problème... What'sApp vient d'annoncer qu'il allait partager les données privées de ses utilisateurs dont les numéros de téléphone avec FaceBook (et pourtant lorsque FaceBook avait racheté la société en 2014, les dirigeants avaient promis ne jamais partager leur données avec FaceBook)...

Bien sûr, on viole la politique de confidentialité de hier mais toujours pour la bonne vieille raison "En connectant votre numéro de téléphone avec les systèmes de Facebook, ce dernier peut vous offrir de meilleures suggestions d'amis et vous montrer des publicités plus pertinentes si vous avez un compte Facebook" (dixit What'sApp)

Quand est-ce que les utilisateurs vont finir par comprendre qu'ils sont les dindons de la farce...

[TheLastShot]

@NSKis, le problème c'est que pour beaucoup ils s'en rendent compte... Mais il s'en fiche totalement. La notion de vie privée (et pis encore, de respect de la vie privée) est quelque chose qui se perd de plus en plus depuis quelques années. Sous prétexte qu'on a des outils qui permettent de données des informations sur soi, certains se sentent "obligé" de tout dire sur eux et sur les autres... Il suffit de voir comment ont pulluler les émissions de télé-rézlité, le succès des tabloids, la prolifération de photos ou vidéos à caractère privé sur youtube (bien sûr au détriment de celui qui est photographié ou filmé, et sans réfléchir à l'impact que ça peut avoir...)
Alors après tout, si ces personnes sont prêt à tout déballer, pourquoi les services se gèneraient pour exploiter leurs données ?
(bien sûr je ne cautionne absolument pas ce système, mais j'ai trouvé un moyen très simple de le contrer: il n'y a que très peu d'information sur moi sur internet, et absolument rien de privé !)