« Le SSHA correspond de mémoire au 5ドル$ qui est donc mieux que celui a base de MD5... »
Non, le SSHA c'est du SHA(mot_de_passe+sel)
alors que le 5ドル$ correspond à une boucle d'itérations de SHA (comme le fait le MD5 à la FreeBSD pour les mots de passe) de plus cette boucle est paramétrable au niveau de PAM sur Ubuntu par exemple où l'on peut fixer le nombre d'itérations à effectuer. (voir: man pam_unix et les paramètres sha256, rounds=n)
« Bref, je vois dans ton autre post que pour toi, le sel n'est pas si important que cela. Je dis que non, le SEL est un composant essentiel du hachage du mot de passe au même titre que la qualité de la fonction de hachage. »
Puisqu'il était question du SSHA, je maintiens que le gain de sécurité est surestimé, et qu'il vaut mieux utiliser un mot de passe du type 1ドル$ si cela est possible car celui-ci fait intervenir une boucle de 1000 itérations, ce qui multiplie d'autant le temps de cassage par brute forcing par rapport à du SSHA.
Et je n'ai jamais dit que le sel était inutile.
« Le sel améliore sensiblement la protection contre la force brute et assure à 100% que deux personnes ayant le même mot de passe n'auront pas le même hash. »
Le sel n'améliore réellement la sécurité, par rapport à une attaque par recherche exhaustive, que s'il existe des tables pré-calculées pour l'algorithme sans sel. A ma connaissance il n'y a pas de tables publiques pour SHA-256 et 512 ou pour Blowfish. A côté de cela il faut savoir que la constitution de tables précalculées est bien plus coûteuse qu'un cassage par brute forcing.
Deux personnes ayant le même mot de passe, peuvent avoir le même hash si le sel est identique. Ce qui peut se produire si le programmeur est ignorant en la matière...
Au final le sel n'est utile que s'il permet d'éviter la constitution de tables pré-calculées (il faut donc éviter les sels trop petits comme celui du DES) mais il ne limite en rien l'efficacité des attaques par recherche exhaustive, pour cela on utilise des boucles itératives. Reste à savoir si la façon dont sont organisées ces boucles ne génère pas non plus une faiblesse dans l'espace des hachés générés, mais c'est là un autre problème...
[^] # Re: MD6
Posté par croux . En réponse à la dépêche Rugby et cryptographie : Shabal est en demi-finale !. É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...