Discussion :

[Stéphane le calme]

Des chercheurs ont trouvé des failles dans le système de protection de mots de passe d'Ashley Madison,
qui fait appel à la fonction de hash bcrypt

Il y a quelques jours, Ashley Madison, le site canadien de rencontre en ligne pour les hommes mariés, a fait l’objet d’un piratage qui s’est soldé par la publication de la base de données des utilisateurs de la plateforme.

Les réguliers du service avaient été assurés que leurs mots de passe n’étaient pas conservés en texte clair mais étaient protégés par la fonction de hash bcrypt. Cette fonction est connue comme étant adaptative (c'est-à-dire que l'on peut augmenter le nombre d'itérations pour rendre le sel de l’algorithme plus lent) et donc très résistante aux attaques par recherche exhaustive malgré l’augmentation de la puissance de calcul. Dans ce cas particulier, les développeurs s’étaient servis d’un paramètre « cost » (coût souhaité de l’algorithme, il s’agit de la puissance de deux du nombre d’itération choisi) d’un facteur de 12.

Aussi, au lieu d’utiliser une attaque exhaustive dans son analyse des données rendue publique par les pirates, CynoSure Prime, un groupe qui a fait de sa spécialité le déchiffrement des mots de passe, a décidé de s’y prendre autrement. « Nous avons identifié deux fonctions qui ont suscité notre intérêt et, après une analyse plus approfondie, nous avons réalisé que nous pourrions exploiter ces fonctions comme catalyseurs dans l’accélération du déchiffrement des hashs de bcrypt. Par les deux méthodes non sécurisées de la génération de la variable $logkinkey dans deux fonctions différentes, nous avons été en mesure de gagner une énorme augmentation dans la vitesse de déchiffrement des mots de passe hashés par bcrypt », ont-ils assuré.

« Au lieu de nous attaquer directement aux hashs bcrypt, qui font la une en ce moment, nous avons pris une approche plus efficace en attaquant plutôt les tokens md5(lc($username).”::”.lc($pass)) et md5(lc($username).”::”.lc($pass).”:”.lc($email).”:73@^bhhs&#@&^@8@*$”). Ayant déchiffrés les tokens, nous n’avions plus qu’à les faire correspondre à leur équivalent en bcrypt », ont-ils avancé. Résultat ? En une dizaine de jours, ce sont plus de 10 millions de mots de passe qui ont pu être déchiffrés.

Cette décision par donc de deux observations. La première porte sur amlib_member_create.function.php et plus précisément sur la fonction amlib_member_create() aux lignes 69 et 70. La ligne 70 suggère que la variable $loginkey a été générée en convertissant en caractères minuscules les variables username et password dans md5 ( $loginkey = md5(strtolower($username).'::'.strtolower($password)) ).

La seconde observation porte sur AccountProvider.php et plus précisément sur la fonction generateLoginKey() aux lignes 78 et 79. « Cette fonction utilise une routine légèrement différente pour générer la variable $loginkey puisqu’elle incorpore l’utilisation des variables $username, $password et $email avec une constante salt de type string appelée $hash. Ensemble, ces variables ont été hachées dans l’algorithme MD5. Il apparaît que la fonction generateLoginKey() est invoquée lorsqu’un utilisateur modifie les attributs de son compte (username, password et email). La résultante est qu’un nouveau loginkey est généré pour ce compte. De ce que nous avons compris, il apparaît que bcrypt n’a pas toujours été utilisé pour hasher le mot de passe avant qu’il ne soit introduit dans la fonction generateLoginKey(). Ce qui signifie que cette méthode pourrait être utilisée pour récupérer les mots de passe de comptes qui avaient été modifiés avant cette modification du code », ont-ils expliqué.

Le groupe a fait savoir qu’il ne publierait pas les mots de passe qu’il a réussi à déchiffrer afin de protéger les utilisateurs. Cynosure Prime a émis l’hypothèse selon laquelle ce hashage insécurisé pourrait avoir été mis sur pied afin de s’assurer que les utilisateurs puissent se connecter au site rapidement.

Source : blog Cynosure Prime

Et vous ?

Qu'en pensez-vous ?

Forum Sécurité

[Jarodd]

Cynosure Prime a émis l’hypothèse selon laquelle ce hachage insécurisé pourrait avoir été mis sur pied afin de s’assurer que les utilisateurs puissent se connecter au site rapidement.

En quoi un hashage (et non hachage, les développeurs ne sont pas des bûcherons ) insécurisé permet-il de se connecter plus rapidement ?

[bedane]

Parce que un hash bcrypt, ça prend du temps, et c'est d'ailleurs fait pour ça. (long -> dur à brute force)

Les concepteurs du système se sont tirés une balle dans le pied en stockant des md5 du mot de passe concaténé avec d'autres données apparemment, bcrypt reste une manière sécurisée (paranoïaque ?) de stocker les mots de passe.

[Jarodd]

Mais un utilisateur ne fait pas un brute force quand il se connecte. Que le password soit chiffré en md5, sha1, bcrypt ou autre ne change pas le temps de connexion au site...

[bedane]

Il faut hasher le mot de passe pour le comparer au hash stocké en base de données quand l'utilisateur se connecte.

[Jarodd]

Et quelle est la différence de temps entre un bcrypt et un moins sécurisé ? Elle est perceptible par l'utilisateur quand il se connecte ?

[bedane]

La lenteur est configurable avec bcrypt, et pour avoir testé un équivalent (pbdkf2) avec un grand nombre d'itérations sur une vielle machine, il peut y avoir un temps de calcul non négligeable même pour un seul hash.

[hotcryx]

Vous parlez de brute force, c'est bien mais la technique la plus efficace et la plus rapide pour trouver un mot de passe, ce sont les rainbow tables, de plusieurs TB, prêtes à l'emploi.

[hotcryx]

Comme l'article le dit il faut impérativement ajouter du sel "salt" pour compliquer l'utilisation des rainbow tables.
Au niveau db, le plus efficace (j'ai déjà lu un paquet d'article mais beaucoup disent des âneries) est de stocker le "salt" et le résultat du hash(pwd+ salt) => 2 champs.

[Rinrynque]

Si je comprend bien, normalement (quand c'est bien fait), il faudrait virtuellement une rainbow table par utilisateur qui prendrait en compte le salt.

[Aramiil]

Non, les RT ne sont pas la plus grosse menace. En pratique, le concept de salt + hash est de nos jours une mauvaise idée : avec un ordinateur moderne, on peut facilement casser un mot de passe à coup de brute force. Il y a quelques années, c'était compliqué, aujourd'hui, on peut casser environ 350 millions de clefs par seconde sur du md5 - c'est à dire qu'on peut brute forcer ces clefs là. Et le sel ne l'empêche en rien. C'est pourquoi une fonction tel que md5 ne doit pas, en aucun cas, même avec du sel, même si vous l'aimez bien, être utilisée pour des mots de passe (et idem pour sha1). Elle est obsolète, c'est tout. Et les rainbow table le sont tout autant : avec une telle vitesse, casser le mot de passe ne nécessite plus de RT (source de la vitesse : http://3.14.by/en/md5 )

Par contre, le bcrypt est différent. D'une part, il intègre _de base_ un sel (donc inutile d'en ajouter un, ça n'aura aucun intérêt) : il fait partie intégrante du hash obtenu. 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. De ce fait, il devient très compliqué de brute-forcer le mot de passe (puisqu'il est très lent de faire un seul test, sans compter plusieurs), et le sel rend les rainbow table inutiles. Voila pourquoi c'est la manière actuellement sécurisée de stoquer un mot de passe.

Et donc stop au md5, sha1 et autres sha512. Ça ne sert pas à ça !

[Neckara]

c'est-à-dire que l'on peut augmenter le nombre d'itérations pour rendre le sel de l’algorithme plus lent

Rendre le sel plus lent ?

Vous êtes sûr de la traduction ?

et donc très résistante aux attaques par recherche exhaustive malgré l’augmentation de la puissance de calcul.

Le sel est surtout utilisé pour contrer les attaques par dictionnaire.
Une attaque par force brute se moque bien du sel.

Je ne suis pas non plus sûr qu'augmenter le nombre d'itération améliore vraiment la sécurité contre une attaque par force brute, le nombre de possibilités restent identiques juste la durée de calcul d'une possibilité prend un peu plus de temps, mais la complexité de l'attaque reste identique.

En revanche contre d'autres types d'attaques, oui, cela peut offrir une sécurité supplémentaire.

CynoSure Prime, un groupe qui a fait de sa spécialité le déchiffrement des mots de passe

Je ne suis pas sûr qu'on puisse dire qu'ils déchiffrent.

nous avons été en mesure de gagner une énorme augmentation dans la vitesse de déchiffrement des mots de passe hashés par bcrypt

Déchiffrer des mots de passe hashés ? C'est un non-sens.

aux lignes 69 et 70.

Vous êtes sûr que ce n'est pas à la ligne 71 ?

En pratique, le concept de salt + hash est de nos jours une mauvaise idée : avec un ordinateur moderne, on peut facilement casser un mot de passe à coup de brute force.

Non, ce que tu dis est faux.

Un mot de passe "fort", ne peut pas être retrouvé par force brute.

Et le sel ne l'empêche en rien.

Le sel n'est pas là pour se protéger des attaques par force brute.

Et les rainbow table le sont tout autant : avec une telle vitesse, casser le mot de passe ne nécessite plus de RT (source de la vitesse : http://3.14.by/en/md5 )

???

Les rainbow table sont une attaque, pas un algorithme de hashage comme md5.

D'une part, il intègre _de base_ un sel (donc inutile d'en ajouter un, ça n'aura aucun intérêt)

Pas nécessairement. Avoir plusieurs sels d'origine différente peut être un plus si on considère qu'un des générateur génère des sels "faibles" ("peu aléatoire"), ou qu'on ne lui fait pas vraiment confiance.

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.

Non.

Si tu utilises un algorithme de chiffrement, c'est que tu peux le déchiffrer. Quand bien même tu utiliserais une fonction de compression, tu pourrais retrouver un mot de passe différent de l'original qui sera accepté.

Il faut donc utiliser des fonctions de compression non-réversibles, une sorte de fonction de hash en somme. Mais dans ce cas là, on ne parle plus d'algorithme de chiffrement.

De ce fait, il devient très compliqué de brute-forcer le mot de passe (puisqu'il est très lent de faire un seul test, sans compter plusieurs)

Non, le plus important, ce n'est pas la durée d'un test mais de la complexité de l'attaque.

Si un test par brute force prend 10 fois plus de temps, il suffit d'avoir des machines 10 fois plus performantes ou 10 fois plus de machines à notre disposition, cela n'offre donc pas une réelle sécurité.

D'autant plus qu'on ne peut pas non plus rendre l'algorithme trop lent si on veut qu'il soit utilisable.

et le sel rend les rainbow table inutiles.

Pas nécessairement.

Voila pourquoi c'est la manière actuellement sécurisée de stoquer un mot de passe.

Non, c'est faux.

Et donc stop au md5, sha1 et autres sha512. Ça ne sert pas à ça !

Faux.

MD5 et SHA1 ne sont effectivement plus recommandée.
SHA2 l'est encore et on a désormais SHA3.

Et si, cela peut bien servir au stockage de mots de passes, en revanche, les algorithmes de chiffrement, que tu recommandes, eux ne servent pas à ça !

[Pat_AfterMoon]

Et quelle est la différence de temps entre un bcrypt et un moins sécurisé ? Elle est perceptible par l'utilisateur quand il se connecte ?

Probablement pas au niveau d'un seul utilisateur, mais la différence est très sensible pour le serveur qui gère pleins d'authentifications d'utilisateurs différents en simultané. C'est généralement ça qui pousse les développeurs à "simplifier" l'authentification afin de limiter la surcharge.

[Aramiil]

Bonjour,

Non, ce que tu dis est faux.

Un mot de passe "fort", ne peut pas être retrouvé par force brute.

Non, ce que tu dis est faux. Fais le test par toi-même : sur un ordinateur de bureau (certes orienté jeu, en l'occurence un GE60 de MSI) j'ai mis un peu moins de 20 minutes à trouver un mot de passe "fort", ou plus exactement retrouver un mot de passe de 8 caractères incluant des majuscules, minuscules, chiffres et caractères spéciaux. La force d'un mot de passe n'y fait donc rien (sauf à choisir un mot de passe vraiment très long, et encore, on pourrait trouver des collisions... et la plupart des utilisateurs ne le retiendrons de toutes manières probablement pas).

Le sel n'est pas là pour se protéger des attaques par force brute.

Oui, c'est précisément ce que je dis...

???

Les rainbow table sont une attaque, pas un algorithme de hashage comme md5.

C'est aussi précisément ce que je dis (ne pas hésiter à lire le message avant de le citer par petit bouts en ne le comprenant pas...)

Pas nécessairement. Avoir plusieurs sels d'origine différente peut être un plus si on considère qu'un des générateur génère des sels "faibles" ("peu aléatoire"), ou qu'on ne lui fait pas vraiment confiance.

??? Le sel doit de toutes manières être stoqué en clair et à part du mot de passe pour pouvoir faire une comparaison de hash. Le seul intérêt du sel, c'est d'empêcher les attaques par rainbow table (puisque même si le mot de passe est dans la table, le mot de passe + sel n'y sera lui probablement pas). Pour plus d'informations : https://fr.wikipedia.org/wiki/Salage_(cryptographie)

Non.

Si tu utilises un algorithme de chiffrement, c'est que tu peux le déchiffrer. Quand bien même tu utiliserais une fonction de compression, tu pourrais retrouver un mot de passe différent de l'original qui sera accepté.

Il faut donc utiliser des fonctions de compression non-réversibles, une sorte de fonction de hash en somme. Mais dans ce cas là, on ne parle plus d'algorithme de chiffrement.

Et pourtant, le blowfish est bien un algorithme de chiffrement, et le bcrypt est bien une fonction de hash. L'utilisation d'un algorithme de chiffrement n'interdit pas d'obtenir, en l'intégrant dans un second algorithme, une fonction de hash (les deux liens de la phrase précédente te donnerons des informations plus complètes sur le sujet).

Non, le plus important, ce n'est pas la durée d'un test mais de la complexité de l'attaque.

Si un test par brute force prend 10 fois plus de temps, il suffit d'avoir des machines 10 fois plus performantes ou 10 fois plus de machines à notre disposition, cela n'offre donc pas une réelle sécurité.

D'autant plus qu'on ne peut pas non plus rendre l'algorithme trop lent si on veut qu'il soit utilisable.

Sur ce point, c'est vrai. Mais ce n'est qu'une question de sémantique. En l'occurence, sur des attaques sur des mots de passe hashés, le but est d'obtenir une collision (c'est à dire un texte donnant le même hash que celui connu au départ). Si on excepte le cas de faiblesse propres à l'algorithme, qui sont rares et donc peuvent temporairement être ignorées, on aura à s'intéresser à deux cas de figures (en tous cas à l'heure actuelle) : tester toutes les possibilités (bruteforce) ou regarder une liste de hash déjà connus (rainbow tables). Le sel sert à éviter la seconde, on va donc s'intéresser à la première.

Dans le cas d'une attaque par brute force, le but recherché va être, comme tu le dis, d'augmenter la complexité de l'attaque. Ta première phrase est donc vraie (tout le reste est faux). En effet, lorsque la complexité augmente, il faut plus de ressources à un ordinateur (ou un cluster d'ordinateurs) pour obtenir une collision. Le résultat est donc qu'avec une quantité de ressources limitées, on est dans l'obligation de mobiliser plus de temps (ou d'assembler plus de ressources, donc plus de machines ou des machines plus puissantes) pour casser le hash et obtenir une collision.

Pour empêcher l'attaquant d'obtenir plus de ressources, les fonctions dites "adaptatives", telles que bcrypt, ont un facteur dit de "coût". Je cite wikipedia pour clarifier ce terme "on peut augmenter le nombre d'itérations pour le rendre plus lent. Ainsi il continue à être résistant aux attaques par recherche exhaustive malgré l'augmentation de la puissance de calcul.". En d'autres termes, pour exécuter l'algorithme une fois et donc tester une clef, il faut en fait exécuter des sous-éléments de l'algorithme un nombre plus grand de fois, ce qui implique plus de puissance de calcul, donc plus de temps si la puissance disponible à un instant T est limitée (et elle le sera toujours jusqu'à ce qu'on découvre un ordinateur de puissance infinie). Cela offre donc une réelle sécurité, contrairement à ce que tu sembles penser.

Enfin, l'algorithme ne sera jamais trop lent au sens où nous sommes ici sur des vitesses "informatiques" : un chiffrement par bcrypt, par exemple, prendra une ou deux secondes avec un paramètre de coût adapté. C'est négligeable pour un utilisateur normal qui ne le verra qu'une seule fois (au moment d'entrer son mot de passe), mais pour un attaquant, c'est différent. En imaginant que chaque test demande 1 seconde avec une capacité de calcul normale, que l'attaquant est en mesure (comme tu le suggère) de multiplier par 10 sa puissance de calcul, et que le mot de passe est composé de six lettres minuscules (et rien d'autre, donc nous sommes ici sur un mot de passe très faible), il lui faudra environ 15 milliard d'années pour pouvoir trouver une collision. En admettant une forte augmentation de puissance de calcul (mettons un facteur 1000 pour l'attaquant), nous restons face à plus de 150 millions d'années (et là, nous parlons d'un attaquant disposant de 1000 machines équivalentes à celles utilisées pour la génération du mot de passe). Pour donner un ordre d'idée plus précis, en admettant que la totalité du plus gros botnet recensé sur wikipedia, soit 30 millions de machines, cherche à casser un seul mot de passe, il faudrait plus de 5000 ans.

Pas nécessairement.

En soit, c'est exact : si quelqu'un s'amuse à passer les millions d'années dont j'ai parlé juste avant pour générer tous les sels possibles en plus des mots de passe, la table obtenue serait utile. Mais comme c'est en pratique impossible, si, un sel utilisé dans un algorithme de hash adapté permet de rendre les rainbow table inutiles.

Faux.

MD5 et SHA1 ne sont effectivement plus recommandée.
SHA2 l'est encore et on a désormais SHA3.

Et si, cela peut bien servir au stockage de mots de passes, en revanche, les algorithmes de chiffrement, que tu recommandes, eux ne servent pas à ça !

Faux. Comme précisé plus haut, je ne recommande pas d'algorithme de chiffrement mais un algorithme de hash.

Pour la comparaison sha2/sha3 vs bcrypt, je t'invite à te reporter à ce papier : http://codahale.com/how-to-safely-store-a-password/

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 et est techniquement plus sécurisé encore que bcrypt. Mais il fonctionne de la même manière, en particulier avec un facteur de coût qui le rends plus lent (et j'emploi le terme à dessin : oui, on cherche à ralentir l'algorithme).

Dans tous les cas, une fonction de hash seule (donc sha2/sha3/sha512) ne suffit pas. Un autre lien pour t'en convaincre : https://news.ycombinator.com/item?id=2004962 (au cas où, le ycombinator est l'incubateur d'où viennent dropbox, 4chan, 9gag, et pas mal d'autres).

[BufferBob]

avec un ordinateur moderne, on peut facilement casser un mot de passe à coup de brute force. Il y a quelques années, c'était compliqué, aujourd'hui, on peut casser environ 350 millions de clefs par seconde sur du md5 - c'est à dire qu'on peut brute forcer ces clefs là. Et le sel ne l'empêche en rien. (...)
Par contre, le bcrypt est différent. (...)
stop au md5, sha1 et autres sha512

entièrement d'accord, moi le premier j'ai souvent utilisé SHA512 pensant être relativement tranquille mais forcé de constater que la génération d'un hash SHA512 est très rapide, ce qui en pratique permet des attaques par force brute bien plus que bcrypt

par ailleurs et pour l'avoir vu en pratique, avec un bon cluster de Radeon HD6990 et des techniques de sioux on pète des passphrases quasi-aléatoires de +20 caractères en MD5 ou en SHA1 dans un temps plus que raisonnable (quelques heures, quelques jours au maximum), mais la théorie du petit spécialiste sécu improvisé ne mentionne pas ces choses là c'est sûr...

[Neckara]

j'ai mis un peu moins de 20 minutes à trouver un mot de passe "fort", ou plus exactement retrouver un mot de passe de 8 caractères incluant des majuscules, minuscules, chiffres et caractères spéciaux.

On recommande désormais un mot de passe de 12 caractères désormais, voir même 16. Voir même des passphrases.

Si on compte 100 possibilité par caractères (je prend un chiffre rond, mais on devrait avoir un peu plus de possibilités pour un caractère), cela te prendra déjà 100*100, soit 10 000 fois plus de temps.

Environ 139 jours si tu as mis 20 minutes à trouver un mot de passe.

Avec 12 caractères, c'est encore 10 000 fois plus, soit 3808 ans.

Ensuite tu parle de "trouver un mot de passe", un seul test ne suffit pas, tu as peut-être mis 20 minutes pour celui-là, mais tu en mettra peut-être 40 sur un autre. Il faut tester sur un ensemble de mots de passes.


Je reconnais que si on compte 7 bits d'informations par caractères, avec 10 ou 12 caractères (70 ou 84 bits), on reste loin des 2^100 possibilités demandées pour résister à une attaque par brute force.

Mais si je commence à utiliser des caractères spéciaux peu usuels comme "…", cela peut aider.

La force d'un mot de passe n'y fait donc rien

Généralement, on ne fait pas une attaque par brute force directement, c'est beaucoup trop long. On va d'abord rechercher les mots de passes les plus faibles et fréquents (e.g. 123456).

sauf à choisir un mot de passe vraiment très long, et encore, on pourrait trouver des collisions...

Oui et non.

Certes un mot de passe plus grand que l'empreinte générée ne sert à rien, car on est sûr d'avoir une collision de plus petite taille.
Quand bien même, la recherche de cette collision est très dure, sur un SHA512, c'est 2^512 possibilités !

et la plupart des utilisateurs ne le retiendrons de toutes manières probablement pas

Ça c'est une autre problématique.
Sachant que certaines personnes recommandent des passphrases ou l'utilisation de gestionnaires de mots de passes.

C'est aussi précisément ce que je dis (ne pas hésiter à lire le message avant de le citer par petit bouts en ne le comprenant pas...)

Tu formules mal tes propos.

Quand tu dis "et le sel ne l'empêche en rien", c'est assez étrange car ce n'est pas le but du sel, on ne voit donc pas pourquoi tu en parles ici, à moins que tu n'ai pas compris l'utilité du sel.

??? Le sel doit de toutes manières être stoqué en clair

Cela ne change rien.

Si tu rends certains sels plus fréquents, en particulier des valeurs de sels qui t'arranges ou diminue juste le nombre de sels possibles, tu peux affaiblir la protection offerte par le sel.
Par exemple au lieu d'avoir 2^512 2^128 (16 octets recommandés pour certains algos) sels possibles, tu fais en sorte que le sel soit unique.

Le seul intérêt du sel, c'est d'empêcher les attaques par rainbow table

Pas uniquement, tu as aussi les attaques par dictionnaires ou éviter de déduire, à partir de hash identiques que les comptes ont un même mot de passe.

Pour plus d'informations : https://fr.wikipedia.org/wiki/Salage_(cryptographie)

Merci, mais je pense m'y connaître un peu plus que toi dans le domaine .

Et pourtant, le blowfish est bien un algorithme de chiffrement, et le bcrypt est bien une fonction de hash. L'utilisation d'un algorithme de chiffrement n'interdit pas d'obtenir, en l'intégrant dans un second algorithme, une fonction de hash

Tu mélanges un peu tout.

Un algorithme de chiffrement est réversible, tu peux le répéter autant de fois que tu le veux, il le sera toujours.
Je n'ai pas dit qu'on ne peut pas se baser sur une fonction de chiffrement, mais ce n'est pas tout.

On peut se baser sur des fonctions de compressions, ou sur un Block Cipher Mode adapté. Mais répéter un algorithme de chiffrement, n'est pas le principe pour hasher un texte, c'est un peu plus compliqué et ce n'est pas la seule solution.

si la puissance disponible à un instant T est limitée (et elle le sera toujours jusqu'à ce qu'on découvre un ordinateur de puissance infinie). Cela offre donc une réelle sécurité, contrairement à ce que tu sembles penser.

Cela offre en effet un type de sécurité, tu bases ta sécurité sur l'idée que ton adversaire a des ressources limitées.

Il suffit donc juste que ton adversaire ai suffisement de ressources pour détruire ta sécurité. Or certains adversaires, organisations gouvernementales, réseaux de Zombis, ont énormément de ressources.
On ne considère pas en sécurité informatique ce type de sécurité comme étant "sûr" ou apportant une réelle sécurité, c'est comme la sécurité par le secret.

En revanche, effectuer plus d'itérations va retarder d'autres types d'attaques. Notament les attaques qui vont tenter d'inverser les fonctions irréversibles de l'algorithme.

Enfin, l'algorithme ne sera jamais trop lent au sens où nous sommes ici sur des vitesses "informatiques"

Cela peut dépend du nombre d'itérations et en fonction de l'algorithme, ce que tu chiffres.

Si une itérations dure T seconde, il suffit de faire 1/T itérations pour que cela dure au moins une seconde. Fais-en 20/T et cela durera 20 secondes.

un chiffrement par bcrypt, par exemple, prendra une ou deux secondes avec un paramètre de coût adapté. C'est négligeable pour un utilisateur normal qui ne le verra qu'une seule fois

Une ou deux secondes peuvent être considérées comme trop long ou trop coûteux pour le serveur.

mais pour un attaquant, c'est différent.

La complexité est en O(N).

Un attaquant peut utiliser des clusters de cartes graphiques infecter des ordinateurs, et donc tester plusieurs mots de passes en même temps.

En imaginant que chaque test demande 1 seconde avec une capacité de calcul normale, que l'attaquant est en mesure (comme tu le suggère) de multiplier par 10 sa puissance de calcul, et que le mot de passe est composé de six lettres minuscules (et rien d'autre, donc nous sommes ici sur un mot de passe très faible), il lui faudra environ 15 milliard d'années pour pouvoir trouver une collision. En admettant une forte augmentation de puissance de calcul (mettons un facteur 1000 pour l'attaquant), nous restons face à plus de 150 millions d'années (et là, nous parlons d'un attaquant disposant de 1000 machines équivalentes à celles utilisées pour la génération du mot de passe). Pour donner un ordre d'idée plus précis, en admettant que la totalité du plus gros botnet recensé sur wikipedia, soit 30 millions de machines, cherche à casser un seul mot de passe, il faudrait plus de 5000 ans.

Parce qu'un mot de passe a une complexité exponentielle.
C'est ton mot de passe qui va te donner le plus gros de ta sécurité.

Si on prend la loi de Moore, "tout" (puissance de calcul, etc.) double tous les 18 mois, c'est donc exponentiel. Et je ne t'apprends rien en te disant qu'une exponentielle croît plus vite qu'une droite linéaire.

Pour une attaque par force brute, une protection de complexité linéaire ne convient pas.

EDIT : "il lui faudra environ 15 milliard d'années pour pouvoir trouver une collision."
Et tu le sorts où ce nombre ? De ton chapeau ?

Petit cours de maths, soit f(x) fonction linéaire et g(x) fonction exponentielle.
f(2X) = 2f(X).
g(2X) = g(X)*g(X)
Dans le premier cas, si tu doubles tes efforts, ton attaquant n'a qu'à doubler les siens.
Dans le second cas, si tu doubles tes efforts, ton attaquant doit en faire g(X) fois plus !

Mais comme c'est en pratique impossible, si, un sel utilisé dans un algorithme de hash adapté permet de rendre les rainbow table inutiles.

Je pense que tu confonds dictionnaire et rainbow tables.

Si tu as un sel unique pour toute ta table, cela peut être éventuellement utilise.
Sinon, tu peux toujours l'utiliser pour attaquer un seul mot de passe avec des complexités plus intéressantes que les attaques par brute force ou par dictionnaire.

Pour la comparaison sha2/sha3 vs bcrypt, je t'invite à te reporter à ce papier : http://codahale.com/how-to-safely-store-a-password/

Il n'a pas vraiment le format d'un papier

EDIT : assez marrant d'ailleurs "Keep in mind I might be wrong. Y’know.".

Dans tous les cas, une fonction de hash seule (donc sha2/sha3/sha512) ne suffit pas. Un autre lien pour t'en convaincre : https://news.ycombinator.com/item?id=2004962 (au cas où, le ycombinator est l'incubateur d'où viennent dropbox, 4chan, 9gag, reddit et pas mal d'autres).

J'attends de voir un craqueur de SHA2 par brute force.

Une attaque par brute force sur un SHA512, c'est 2^512 possibités à tester !
Quand bien même le calcul d'une itération est très rapide, et qu'on peut tenter de tout paralléliser, 2^512, c'est beaucoup trop.
En une seconde, tu as 10^9 nanosecondes, on va dire ~2^30.
On va dire qu'une carte graphique a 6 000 cœurs, on va dire ~2^13.
On est 7 milliards sur Terre, on va dire une carte graphique par personnes, on va dire 2^34.

Donc en une seconde, on va dire 2^77 possibilités testées, je suis très gentil comme vous pouvez le constater.
Pour tester 2^100 possiblités, il faudrait 272 années. Et on a à peine calculé 1/2^412 des possibilités !!!

[Neckara]

par ailleurs et pour l'avoir vu en pratique, avec un bon cluster de Radeon HD6990 et des techniques de sioux on pète des passphrases quasi-aléatoires de +20 caractères en MD5 ou en SHA1 dans un temps plus que raisonnable (quelques heures, quelques jours au maximum)

C'est pour cela que ces algorithmes ne sont plus recommandés.
Et ce n'est pas vraiment une attaque par force brute si on utilise certaines heuristiques ou vulnérabilités.

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.
Par contre, si on tente d'utiliser certaines vulnérabilités ou d'inverser certaines composantes de l'algorithme, répéter certaines étapes peuvent être un plus.

EDIT : D'ailleurs, cela prend 1 seconde sur un GPU.
Mais avec d'autres types de matériels en utilisant des pipelines, on peut se faire X possibilités en un cycle.
Le calcul de la première série possibilité sera relativement longue, mais plus rapide que sur GPU, et les suivantes ne prendront qu'un seul cycle.

CQFD : Une telle protection (tenter de rallonger la durée de calcul d'une possibilité) ne vaut rien face à des attaques par force brute.

[Aramiil]

Je ne vais pas reciter les liens du précédent message. Je t'invite juste à consulter la quasi-totalité des papiers récents sur bcrypt / sha512, d'où qu'ils émanent (en particulier les agences de sécurité américaine qui en font régulièrement) qui disent tous l'exact contraire de tes messages, et que le fait de ralentir l'algorithme sert compliquer le bruteforce. Suis les liens que j'ai mis dans mon précédent message, apprends ce qu'est le bcrypt et en quoi il _utilise_ mais _n'est pas_ un algorithme de chiffrement. C'est toi qui mélange un peu tout, et cela discrédite nettement tes réponses de ne pas prendre le temps de lire celles des autres et de t'informer sur le sujet...

[Neckara]

apprends ce qu'est le bcrypt et en quoi il _utilise_ mais _n'est pas_ un algorithme de chiffrement.

Je n'ai jamais affirmé cela.



Tu te moques un peu de moi. Je t'ai prouvé par A+B que :

• la durée de calcul d'une possibilité n'a aucune influence si l'espace de départ est suffisamment grand.
• rallonger linéairement la durée de calcul d'une possibilité est inutile face à des attaques par force brute si on utilise des systèmes de pipeline.

Il suffit juste d'avoir un minimum de culture en sécurité et en informatique.

Je t'invite juste à consulter la quasi-totalité des papiers récents sur bcrypt / sha512, d'où qu'ils émanent (en particulier les agences de sécurité américaine qui en font régulièrement) qui disent tous l'exact contraire de tes messages

Si tu as des liens, je ne suis pas contre.
Car pour le moment, à part des liens Wikipédia (en version française ) et un pseudo-papier je n'ai pas vu grand chose.


Et sérieusement, si le SHA2 était aussi vulnérable, il ne serait pas recommandé.
Les hashs sont utilisés pour des applications très critiques, qu'il faut protéger contre des organisations ayant de très grands moyens.
Mais oui, tu as raison, le SHA2 est très vulnérable parce qu'il est trop rapide et tous les chercheurs en sécurité du monde se trompent depuis des années.

[SaiRictus]

Bonjour à tous,

Le sujet m'intéresse grandement car j'essaie autant que possible d'appliquer la 'meilleure" pratique possible pour ce qui est du stockage des logins/mdp.

De ce que j'ai pu lire ici et là ... il est recommandé :
- d'utiliser bcrypt pour le hashage des mdp
- stocker le contenu hashé en BDD (1 champ) + 1 champ pour stocker le nombre d'itérations de hashage (1 champ)
- de comparer les mdp hashés (hash BDD vs hash client) pour la validation des

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

Merci d'avance