Discussion :

[PierreDv]

Bonjour à tous,

Depuis quelque temps je suis à la recherche d’explications claires et concises en vain. C’est pour cela que je viens solliciter vos connaissances et compréhensions à ce sujet.

Je vais essayer de résumé ma compréhension de ce sujet et vous pourrez alors si vous le voulez bien éclairer ma lanterne.

La fonction crypt() permet de hacher une chaîne de caractères (jusque-là tout va bien).

Elle prend deux arguments la chaîne de caractères (obligatoire) et Salt.
La chaîne de caractères ne tient compte que des 8 premiers caractères.

Salt permet de choisir le type de hachage, le nombre de fois ou la chaîne passe par la boucle de hachage et une chaîne de caractères dont le nombre varie en fonction des différents hachs.

Première question :
Si la chaine de caractères est plus grande que 8, il faudra la couper tous les 8 caractères puis la hacher et enfin la concaténer avec le précèdent hach ?
Sinon saisir un mot de passe supérieur à 8 caractères serait totalement inutile non ?

Deuxième question :
Apparemment seul un des différents hachs disponibles et viable en termes de sécurité Blowfish. D’accord, sans aller dans le pourquoi, n’y aurait-il pas mieux pour sécuriser les mots de passes?

Troisième question :
La chaîne de caractères contenue dans le sel permet d’empêcher l’utilisation d’attaque par dictionnaire, mais si elle est attribuée « aléatoirement » comment vérifier que le mot de passe saisi dans la bdd correspond bien à celui saisi lors de l’identification ?
Si les sels sont différents les hachs le seront aussi.
Il faudrait la stocker dans la basse mais dans ce cas-là elle perdrait son utilité non ?

Je remercie d’avance tous ceux qui pourront m’aider à mieux comprendre.
Je tiens aussi à m’excuser pour les fautes d’orthographes.

Je vous souhaite à tous une excellente journée.

[ram-0000]

Première question :
Si la chaine de caractères est plus grande que 8, il faudra la couper tous les 8 caractères puis la hacher et enfin la concaténer avec le précèdent hach ?
Sinon saisir un mot de passe supérieur à 8 caractères serait totalement inutile non ?

La fonction crypt() n'utilise que les 8 premiers caractères, c'est comme cela. Effectivement plus de 8 caractères est inutile avec cette fonctions.
hash("azertyuo") = hash("azertyuo123456") = hash("azertyuoqsdfghj")

Deuxième question :
Apparemment seul un des différents hachs disponibles et viable en termes de sécurité Blowfish. D’accord, sans aller dans le pourquoi, n’y aurait-il pas mieux pour sécuriser les mots de passes?

On n'a pas trouvé mieux pour l'instant. La fonction hash est irréversible, c'est à dire que connaissant le mot de passe, on peut calculer le hash très facilement mais connaissant le hash, on ne peut pas retrouver le mot de passe initial.

D'ailleurs, je m'interroge toujours sur la sécurité des systèmes qui disent "vous ne pouvez pas choisir ce mot de passe car il est trop ressemblant avec le précédent". La notion de ressemblance de chaine de caractère ne peut se calculer que sur le mot de passe en clair, pas sur le hash. Cela veut donc dire que le mot de passe en clair est stocké en base ou alors qu'il est chiffré de manière réversible.

Troisième question :
La chaîne de caractères contenue dans le sel permet d’empêcher l’utilisation d’attaque par dictionnaire, mais si elle est attribuée « aléatoirement » comment vérifier que le mot de passe saisi dans la bdd correspond bien à celui saisi lors de l’identification ?
Si les sels sont différents les hachs le seront aussi.
Il faudrait la stocker dans la basse mais dans ce cas-là elle perdrait son utilité non ?

Il faut que le salt soit aussi stocké dans la base de données. Que le salt (de même que le hash) soit connu et accessible par tout le monde n'est pas un problème en soit, cela n'autorise que les attaques par dictionnaires. Bien sûr rien n'empêche de sécuriser un peu la table ou le fichier qui héberge les hash et salt.

Le salt permet uniquement que 2 utilisateurs ayant 2 mots de passe identiques (toto par exemple) n'aient pas le même hash.

[PierreDv]

Merci Raymond pour tes réponses, c'est déjà un peu plus clair pour moi. Mais j'ai encore quelques questions si vous me le permettez.

Quand vous dîtes :

La fonction hash est irréversible

Cela me paraît étonnant, je m’explique.
Si l’on connait le sel alors on peut tester avec des chaînes de caractères jusqu’à ce que l’on retrouve un hach similaire et à ce moment on retrouve le mot de passe initial.

Faut-il encore connaître l’algorithme et l’itération de la boucle de hash. Mais cela ne représente que très peu de possibilités.

J’en viens à ma question :
Si l’on utilise le mot de passe saisit (8 caractères) retouché pour ne pas contenir de caractères spéciaux et concaténé à une chaîne (14 caractères) on obtient alors notre chaîne de 22 caractères à utiliser dans notre sel.

Et de ce faite n’ayant qu’une partie du sel si attaque il y a, elle n’en sera que plus longue puisque il faudra non seulement trouver la chaîne saisit par l’utilisateur mais aussi le sel non ?

[ram-0000]

Si l’on connait le sel alors on peut tester avec des chaînes de caractères jusqu’à ce que l’on retrouve un hach similaire et à ce moment on retrouve le mot de passe initial.

Oui, c'est le principe même d'une attaque brute force (à la bourrin quoi). On peut raffiner un peu en utilisant un dictionnaire.

Ceci dit, je persiste et signe, connaissant un mot de passe, il est facile de calculer son hash. Connaissant le hash (et le salt et l'algo et le nombre de rondes), il est impossible de déduire le mot de passe.

Une fonction de hash est irréversible. Si elle est réversible, ce n'est plus une fonction de hash.

Regarde ici, Introduction à la Cryptographie au paragraphe 6, je parle des algo de hash.

Maintenant, reprenons ton attaque brute force avec quelques nombres. Supposons :

• Des mots de passe de 8 caractères
• Un jeu de caractères de 70 signes (26 minuscules + 26 majuscules + 10 chiffres + quelques caractères spéciaux)
• Cela nous fait 70^8 mots de passe différents, soient 576 480 100 000 000 mots de passes différents (d'après ma calculatrice).
• La possibilité de tester 1000 mots de passe par secondes (c'est déjà très rapide)
• ce qui fait 576 480 100 000 secondes pour tester tous les mots de passe
• soient 160133361 heures et donc 18280 années (environ).

Et maintenant, la question : est ce que tu veux jouer ?

[PierreDv]

Je veux !!!
Car comme dans tous les jeux il y a le facteur chance.
Les 18280 années ce n'est que le lapes de temps pour tester tout les mots de passes mais il se peut très bien que je le trouve au bout de 10s

En tous cas je vous remercie pour toutes ces informations et votre réactivité.

Je vous souhaite une excellente journée.

Pierre

[ram-0000]

...mais il se peut très bien que je le trouve au bout de 10s

Ou pas