Bonjour,

Envoyé par
Neckara
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).

Envoyé par
Neckara
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...

Envoyé par
Neckara
???
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...)

Envoyé par
Neckara
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)

Envoyé par
Neckara
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).

Envoyé par
Neckara
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.

Envoyé par
Neckara
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.

Envoyé par
Neckara
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-st...re-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).
11 |
2 |