Mot de passe (hash/salage)

[invite78f958b1]

Bonjour !

Je fais des recherches sur le fonctionnement d'un mot de passe.
Je pense avoir compris le principe du mot de passe. (comparaison entre le premier hachage du mot de passe et celui nouvellement calculé lors qu'on rentre le mot de passe.)

Mon problème se situe au niveau du salage. (opération qui consiste à ajouter des chaines de caractère au mot de passe et donc modification du hachage).

Dans l'exemple que j'ai trouvé, il prenne comme mot de passe: azerty

La valeur stockée sur l'ordinateur sera par exemple, H(BoGossazerty_NA) avec H la fonction de hachage.
(_NA et BoGoss corresponde à deux fonctions grains de sels)


Mais si je rentre le mot de passe,azerty, il est calculé le hash: H(azerty).
H(azerty) n'est pas égal à (BoGossazerty_NA). Donc je ne peux pas me connecter ?

2) Il dise que _NA est grain statique commun à l'ensemble des utilisateurs
Si un pirate passe le problème du hash(par attaque brute ou dictionnaire), il obtiendra le mots de passe +grain statique et il ne sais pas qui est qui.
Cependant, Comme ce grain est commun, il suffit qu'il obtienne un mot de passe +grain statique d'un autre utilisateur. Il voit bien le mot commun qui est le grain _NA.
Donc c'est complètement inutile en soit ?

Merci de vos réponses

EDIT: le site http://www.net-actuality.org/billets...ur-le-net.html
-----

[invite765732342432]

Mais si je rentre le mot de passe,azerty, il est calculé le hash: H(azerty).

C'est là qu'est l'erreur: le module d'identification ne calcule pas le hash de la saisie, mais le hash de la saisie+sel, permettant de retrouver le hash stocké en base.

Si un pirate passe le problème du hash(par attaque brute ou dictionnaire), il obtiendra le mots de passe +grain statique et il ne sais pas qui est qui.

Mais comment passe-t-il le problème du hash ?
En fait, plutôt que de chercher 2 mots de passe+grain, son meilleur moyen, c'est de connaître un mot de passe (par exemple le sien), et, par force-brute, de chercher quel peut-être le sel pour son mot de passe.
Seulement, comme le sel est coté serveur (et transparent pour l'utilisateur), celui-ci peut être beaucoup plus complexe que le mot de passe, rendant le dictionnaire inutile et l'attaque par brute force, TRES longue.

Ajouter à cela un grain dépendant du login, par exemple, impose au pirate d'avoir en plus accès aux sources du serveur pour pouvoir lancer cette attaque... ce qui devient vraiment compliqué ! (Mais jamais impossible)

[invite78f958b1]

Bonjour et merci Faith d'avoir répondu.

C'est là qu'est l'erreur: le module d'identification ne calcule pas le hash de la saisie, mais le hash de la saisie+sel, permettant de retrouver le hash stocké en base.

D'accord, je vois. Mais si le sel est spécifique à l'utilisateur (comme grain dynamique) et non commun à l'ensemble des utilisateurs enregistrés, comment le site sait que le sel là correspond à tel utilisateur et pas un autre ?

Mais comment passe-t-il le problème du hash ?

d'après Net-actuality:

3.Dans le cas d'attaque par brute force ou si le mot de passe est présent dans le dictionnaire, le pirate obtiendrait le mot de passe tel que modifié : « azerty_NA ». Le problème pour lui, c'est qu'il ne saurait pas quel est le grain de sel, donc il ne pourrait pas utiliser le mot de passe, sauf s'il arrivait à localiser et à supprimer le salt.

Donc par force brute, il essaye tous les mots de passes possibles (dans notre cas, azerty_NA)
Pour l'attaque de dictionnaires, il utilise des mots de passes qu'il hache (tout a accès à la méthode de hash, n'est ce pas ?) et compare avec celle du serveur. Si c'est le même, il a trouvé un mot de passe.
Quand je dis qu'il passe le problème du hash, c'est qu'il n'a pas besoin de l'inverser (difficile car c'est une fonction à sens unique).

son meilleur moyen, c'est de connaître un mot de passe (par exemple le sien), et, par force-brute, de chercher quel peut-être le sel pour son mot de passe.

Mais dans ce cas, c'est "facile". il connait son mot de passe (azerty), il a récupéré par force-brute (azerty_NA). Il en déduit que le sel est _NA. C'est bien ça ?

Le sel est coté serveur (et transparent pour l'utilisateur),

Je ne savais pas. C'est un peu bête, non ? Si, il est transparent pour l'utilisateur, il le sera pour le pirate qui pourra facilement distinguer le mot de passe du sel.

Merci de votre aide.

[invitee840409b]

Bonjour,

D'accord, je vois. Mais si le sel est spécifique à l'utilisateur (comme grain dynamique) et non commun à l'ensemble des utilisateurs enregistrés, comment le site sait que le sel là correspond à tel utilisateur et pas un autre ?

Dans ce genre de cas, le sel dynamique se base sur une caractéristique de l'utilisateur qui ne peut pas changer. Par exemple, son login (ou quelque chose dérivé de son login).

difficile car c'est une fonction à sens unique

Pour les fonctions de hash de qualité, ce n'est pas difficile, c'est impossible de le faire avec les outils mathématiques actuels. La seule méthode est donc le bruteforce ou les rainbow tables.

Mais dans ce cas, c'est "facile". il connait son mot de passe (azerty), il a récupéré par force-brute (azerty_NA). Il en déduit que le sel est _NA. C'est bien ça ?

Oui.

Je ne savais pas. C'est un peu bête, non ? Si, il est transparent pour l'utilisateur, il le sera pour le pirate qui pourra facilement distinguer le mot de passe du sel.

Ce que voulait dire Faith par "transparent", c'est que l'utilisateur ne le voit pas.

ProgVal

[A voir en vidéo sur Futura]

[invite765732342432]

Mais dans ce cas, c'est "facile". il connait son mot de passe (azerty), il a récupéré par force-brute (azerty_NA). Il en déduit que le sel est _NA. C'est bien ça ?

C'est ça, mais ça n'a rien de "facile" si le sel est correctement choisi (même avec un sel fixe)...

Evidement, si le sel est _NA, ça ne va pas être très long à brute forcer, mais si le sel est un peu plus correct (genre a"1tY-|;$Gs{)aC: ), c'est quasi-impossible.
Comme ça, même si l'utilisateur a choisi "toto" comme password, le pirate ne peut pas faire une attaque par dictionnaire. Il est obligé de se cogner les 128^16 combinaisons du sel (et encore, si le sel est unique et indépendant de l'utilisateur !)
Bref, c'est assez tranquille...