Discussion :

[xxkirastarothxx]

Bonjour à tous et à toute.

C'est la première fois que je lance un sujet général, et celui ci abordera le thème du hachage.

Première Partie: Le MD5 est dépassé, obsolète et surtout cassé

Comme vous le savez tous, les deux méthodes de hach les plus utilisées à l'heur actuelle, si je ne dis pas de bêtise, sont le md5 et le sha1.
Mais il existe plusieurs soucis avec ces méthodes:
- Attaque par dictionnaire:
il suffis d'enregistrer tout les mots du dictionnaire et leur valeur md5, pour pouvoir réalisé une telle attaque
- Collision:
comme une somme md5 est une valeur de 256bits (32 caractères hexa (base 16; 32x16 = 256) il existe de nombreuses valeur ayant la même somme md5; et a l'heure actuelle, il existe également de nombreux générateur de collision

Deuxième partie: Du nouveau, Une utilité ?

Alors voila, je me suis décidé aujourd'hui d'essayer de créer un nouveau hash (que j'ai pour le moment nommé SecH (Secure Hach))
Quelques caractéristiques:
- valeur de 24576 bits ((128+256=)384 caractères base 64)

- partie de 256 caractères: utilisé pour stoké la somme du hash, ce qui fait une somme haché de 16384bits; les ordinateur actuelle ne sont, je suppose, pas du tout assez puissant pour pouvoir calculé une collision de 16384bits.

- partie de 128 caractères: généré aléatoirement afin d'être utilisé automatiquement comme anti-dico: cette phrase permet de crypter/décrypter le hash. Un cryptage étant moins performant qu'un hachage (puisque lui est prévu pour être décrypté), cette partie ne sert pas a renforcé le hash, mais uniquement à empêcher toute attaque par dictionnaire.

- des fonctions en objet qui permettent d'interdire sa propre utilisation d'une fois par seconde, afin d'empercher toute attaque de type "brute-force"

Troisème et dernière partie: C'est bien beau.. mais est-ce vraiment sécurisé ?

euuh... bah là par contre... j'aimerai avoir vos avis, et conseil sur comment tester ?
Par exemple, des tests on montrés, si je ne m'abuse, que le sha1 est plus performant que le md5, mais je suppose qu'il n'y à pas que le nombre de bits utilisé qui font la différence.
Donc si vous connaissez des "trucs" pour tester la solidité d'un hachage... je prends avec plaisir

Edit: un petit commentaire avec le sondage serrais sympa

[Sergejack]

Il existe une infinité de mots de passe possibles.
Il existe un nombre fini de hash MD5 possibles.
On peut considérer que les différents mots de passe possibles se répartissent avec équilibre sur l'ensemble des hash MD5 possibles.
Donc chaque hash MD5 possible correpont à une infinité de mots de passe possibles.

Avec un MD5 tu ne peux pas retrouver un mot de passe, mais tu peux retrouver des ce mot passes plausibles parmis lequel se trouve peut-être celui de l'utilisateur.

Pour éviter qu'un mot de passe soit retrouvé, il suffit de lui adjoindre un/des grains de sel qui rendront "monmotdepasse" en un moins plausible "b4a60b84a640b6540ba654b0ab7a897ba9monmotdepasse" par exemple.

[Neitsa]

Bonjour,

- des fonctions en objet qui permettent d'interdire sa propre utilisation d'une fois par seconde, afin d'empercher toute attaque de type "brute-force"

C'est ce qu'on appelle "Sécurité par obscurité". (cf. http://en.wikipedia.org/wiki/Security_through_obscurity ).

Pour qu'un système de sécurité soit viable, on doit considérer (même si ça n'est pas effectivement le cas) que son implémentation est ouverte aux attaquants.

Dans le cas d'une temporisation pour éviter tout bruteforce, il serait possible à un attaquant ayant accès au programme (binaire ou script, peu importe) de hashage de circonvenir à ce type de protection, ce qui rend cette dernière caduque.

En ce qui est de tester ton algo, tu peux toujours te référer à la page du NIST qui organise un concours à ce sujet, il y a de la doc intéressante: http://csrc.nist.gov/groups/ST/hash/index.html

Voir notamment le CAVP (Cryptographic Algorithm Validation Program): http://csrc.nist.gov/groups/STM/cavp/index.html

Un exemple avec le SHAVS (The Secure Hash Algorithm Validation System), même si c'est pour SHA, tu y trouvera toute une panoplie de test:

http://csrc.nist.gov/groups/STM/cavp.../shs/SHAVS.pdf

[xxkirastarothxx]

@Sergejack
Bah... je sais... mais je demandais pas comment fonctionnait le md5

Avec un MD5 tu ne peux pas retrouver un mot de passe, mais tu peux retrouver des ce mot passes plausibles parmis lequel se trouve peut-être celui de l'utilisateur.

ce qui suffis amplement à passer pas mal de protec (url avec &userid=xxxxxxxxxxxxxxxxxx)

Pour éviter qu'un mot de passe soit retrouvé, il suffit de lui adjoindre un/des grains de sel qui rendront "monmotdepasse" en un moins plausible "b4a60b84a640b6540ba654b0ab7a897ba9monmotdepasse" par exemple.

ouais sauf que comme tu viens de le faire remarquer, il faut implémenter sois même la fonction (en php, java ou autre) pour que les attaquent anti-dico soit "désactivé", et encore, en imaginant que la phrase anti-dico soit bien inconue.
Et dans le cas ci dessus, une fois que le md5 est récupéré il est toujours possible de calculer une collision.

C'est ce qu'on appelle "Sécurité par obscurité"

très bonne remarque.
Je vais éviter le développement "à la microsoft"
Mais bon il ne s'agit que d'un plus
et merci beaucoup pour les liens, c'est le genre de choses que je cherchais

[Sergejack]

@Sergejack
Et dans le cas ci dessus, une fois que le md5 est récupéré il est toujours possible de calculer une collision.

Et alors ?

C'est le mot de passe que tu souhaites conserver secret, pas le hash md5.

Avec un grain de sel connu, on pourrait regénéré un dictionnaire de mots de passe l'incluant. Cela prendrait du temps mais on arriverait à un résultat efficace.

La seule bonne sécurité, c'est de communiquer via SSL puisque toutes les réflexions que l'on est en train d'avoir portent sur des attaques Man in the middle.

[xxkirastarothxx]

Et alors ?
C'est le mot de passe que tu souhaites conserver secret, pas le hash md5.

Bah oui, justement...
Alors, soit il y'a quelque chose que j'ai pas compris, soit j'ai mal expliqué le soucis, mais, de mon point de vu, imaginons:

Mon password (inconnu) est hashé en md5. ce md5, plus ou moins "publique", ou tout du moins "récupérable", peu très facilement être dangereux:

Considérons "123456" comme mon mot de passe, parsé avec la phrase "anti-dico": ce qui nous donne un md5 de la phrase "anti-dico123456"
Ce md5 est: f9d75c5961dcf7aca012f48c1936f147

si une personne mal attentionnée récupère ce md5, et calcule une valeur de collision (disons que "XXXXXX" est cette valeur).
Si cette personne se retrouve sur mon site est tape "XXXXXX" comme mot de passe, comme la valeur de collision est la même, l'accès lui serra autorisé a mon compte.

Ok! bon en relisant, je me suis aperçu de ma bêtise, c'est la valeur de collision de "anti-dico123456" qui est sera trouvée, et non la valeur de collision de mon mot de passe.
Mais il faut s'assurer que la phrase antidico est absolument inconnue (sécurité par l'obscure ici aussi ?), et sur un developpement "diffusé" (CMS, application, plugins...) il faut également être sur que personne ne peut avoir la même phrase anti-dico.

Autre point: dans tout les cas, la "valeur" de la phrases anti-dico peut aussi être repérée, par exemple si une personne s'inscrit plusieurs fois avec un mot de passe trèès simple à "déchiffrer" ("1", puis "2" (ou "123456" dans le cas d'une obligation d'un minimum de caractère)etc... par exemple) ce qui permettra de retrouver la phrase anti-dico par attaque brute force, long mais tout à fais possible (puisque,encore, il ne s'agit que d'un hachage 256bits)

Enfin dites moi si je me trompe, mais la problématique pour moi, c'est bien ça.

[Sergejack]

Si Mister Hacker a le MD5 de ton password, nécessaire et suffisant à l'identification, il n'a pas besoin de passer par la page login ton site pour faire une requête avec ce MD5

Sachant cela, je ne vois pas en quoi l'usage réussi d'une collision serait un mal plutôt qu'un symptôme d'un mal plus grand encore.

[wiztricks]

Mais il faut s'assurer que la phrase antidico est absolument inconnue (sécurité par l'obscure ici aussi ?), et sur un developpement "diffusé" (CMS, application, plugins...) il faut également être sur que personne ne peut avoir la même phrase anti-dico.

Il n'y a pas d'obscurité au 'salt'.
C'est une méthode pour compliquer les attaques avec un dictionnaire qui est assez ancienne.
Voir le WIKI

Autre point: dans tout les cas, la "valeur" de la phrases anti-dico peut aussi être repérée, par exemple si une personne s'inscrit plusieurs fois avec un mot de passe trèès simple à "déchiffrer" ("1", puis "2" (ou "123456" dans le cas d'une obligation d'un minimum de caractère)etc... par exemple) ce qui permettra de retrouver la phrase anti-dico par attaque brute force, long mais tout à fais possible (puisque,encore, il ne s'agit que d'un hachage 256bits)

Enfin dites moi si je me trompe, mais la problématique pour moi, c'est bien ça.

De toutes façons avec des moyens et du temps, on peut tout cracker.
L'article Wiki donne des idées sur le nombre d'essais à faire dans ce cas.
-W