Discussion :

[contremaitre]

Bonjour,

Je me pose une question sur la sécurité des mots de passe cryptés grace à des hash comme MD5 ou SHA.

Dans le cas d'une application réseau qui stocke les mot de passe hachés dans une BD et où le client se connecte au serveur (grace à une application écrit par moi) par socket et lui envoie le mot de passe haché également. Une fois identifié, le serveur accepte diverses commandes du client.

Qu'est ce qui empeche un pirate avec un sniffer de récupérer le mot de passe haché, et de se connecter lui meme au serveur en envoyant la meme chose.
Ou est l'avantage d'utiliser le hachage ? Qu'est ce que j'ai raté dans l'histoire ?

merci

[ram-0000]

Qu'est ce qui empeche un pirate avec un sniffer de récupérer le mot de passe haché, et de se connecter lui meme au serveur en envoyant la meme chose.

rien effectivement, cela s'appelle "le rejeu de session".

Ou est l'avantage d'utiliser le hachage ? Qu'est ce que j'ai raté dans l'histoire ?

Cet agresseur ne pourra pas utiliser ton application pour se connecter à ton serveur puisque ton application demande un mot de passe en clair (genre "toto") et qu'elle va le transformer en hash.

[contremaitre]

ok, merci, c'est bien ce que je pensais.
Et quels sont les éventuels moyen d'empêcher un pirate de se connecter lui même avec un mot de passe "haché" ?

[Médinoc]

Avec ce faible niveau de sécurité, pas des masses.

Un pirate peut même modifier/patcher ton application pour envoyer directement le mot de passe haché qu'il avait sniffé...

C'est pourquoi généralement, transmettre le mot de passe haché ou en clair n'a que peut d'influence. Le hachage sert surtout à stocker le mot de passe.
Pour une vraie transmission sécurisée, il faut utiliser du vrai cryptage fort (RSA, etc.)

[contremaitre]

Pour une vraie transmission sécurisée, il faut utiliser du vrai cryptage fort (RSA, etc.)

Je ne vois pas bien la différence...
Ici aussi on peut toujours envoyer le mot de passe déjà crypté qu'on peut sniffer

[Médinoc]

Avec un cryptage fort comme RSA, la clé de cryptage change à chaque session, donc le même mot de passe crypté ne peut pas être utilisé deux fois.

[contremaitre]

d'accord merci

[ram-0000]

Le hachage sert surtout à stocker le mot de passe.

Tout à fait d'accord.

Ceci dit, vaut mieux transmettre un hash que le mot de passe en clair.

Autre possibilités, utiliser une connexion SSL. Ainsi, il n'est plus possible de sniffer la session.

Encore une possibilité, utiliser un protocole à base de challenge/response dans le protocole d'authentification. En général, ce type de protocole est insensible au rejeu.

[granquet]

Avec un cryptage fort comme RSA, la clé de cryptage change à chaque session, donc le même mot de passe crypté ne peut pas être utilisé deux fois.

le pirate ne seras en aucun cas capable de décrypter le mot de passe (comme avec sha1 et MD5), mais RSA étant déterministe, il est tout aussi sensible au replay que les sus-cités.

y'as pas mal de 'boulot' pour éviter le replay
un exemple avec l'EAP-TTLS : http://tools.ietf.org/html/draft-funk-eap-ttls-v0-04

[Médinoc]

Il me semblait pourtant que la "clé de session" était générée aléatoirement par un générateur de nombres pseudo-aléatoires de qualité cryptographique (CSPRNG)...

Comment peut-on faire un replay du mot de passe crypté si la clé utilisée a changé entretemps?

[granquet]

Il me semblait pourtant que la "clé de session" était générée aléatoirement par un générateur de nombres pseudo-aléatoires de qualité cryptographique (CSPRNG)...

Comment peut-on faire un replay du mot de passe crypté si la clé utilisée a changé entretemps?

le RSA (fin, le même principe en tout cas) est souvent utilisé pour faire du "4 way handshake".
dans ce cas, la session n'est pas 'violable' car l'échange de la clef servant au cryptage symétrique est crypté par une session à cryptage asymétrique (je sais pas si je me fait comprendre)
mais le RSA tout seul ... je ne vois pas ce qui le rendrais insensible au replay
le RSA est simplement un cryptage asymétrique déterministe

[Médinoc]

Je vois ce que tu veux dire: Si on envoyait le mot de passe crypté directement en RSA au lieu de passer par un cryptage symétrique intermédiaire (dont seule la clé est transmise cryptée en RSA), un pirate pourrait facilement faire du replay.