MD5/SHA1 généralement c'est fait au niveau de la BDD, pas celui de la requête POST ^^

Mais je réfléchis à un système pour pouvoir envoyer un footprint de password qui serait inutilisable avec une autre IP ou un autre contexte en fait. (Peut-être un nombre aléatoire mis en session + cookie, je sais pas)

Deviner un mot de passe? Il a été fortement chanceux alors...

Ah bon ? lol moi quand j'envoie un mot de passe il est toujours encodé a la volée (javascript) en md5 avant d'expédier le formulaire par POST...

Ton idée est intéressante par contre!

Et la personne étais peut-être de ton entourage, je ne sais pas... ^^
Enfin une attaque "basique" me parais plus probable aussi, dommage que Loisirados ne sois pas la pour nous en dire plus (mais peut-être ne souhaite-t-il pas révéler d'informations sur son code, ce qui est compréhensible.)

Le soucis de ça, Black3Angel, c'est que si ton passe est encodé ainsi, c'est le footprint qui peut être réutilisé ^^

Tu transformes le problème, mais ça ne fait que le reporter au final...

Moi je cherche un moyen efficace d'éviter d'avoir un footprint/mot de passe réutilisation juste en sniffant le bon paquet...

Par exemple, sur la session, le serveur envoie un grain de sel différent pour chaque session, la session DOIT être également associée à une adresse IP, etc...

Donc le serveur aurait en fait un mot de passe en clair (ou une version transformée) dans sa BDD, et demanderait un hash MD5 de, disons NombreAléatoire . MotDePasse.

Javascript se chargerait d'effectuer ce petit travail, et la requête pour matcher aussi également.

 

Tout a fait, je préfère ne pas trop en dire à ce sujet ^^

Par contre, je ne vois pas l'intérêt de crypter en javascript plutôt que coté serveur. Puisque de toute façon rien d'important n'est stocké sur vos machines (cookies)

C'est pour ça Azor que j'associe toujours la session a l'IP qui s'est connecté.

Le système encode le mot de passe en md5 avant de valider le formulaire (d'ou l'intérêt de le faire côté client... de plus ça permet de se passer d'un tunel SSL dans la mesure bien évidement ou le contenu des pages n'est pas a proprement parler confidentiel), et efface la zone de texte contenant le mot de passe en clair avant d'utiliser POST.
Ensuite, le md5 reçu est comparé avec sa version dans la BDD.

En cas de sniffing, le pirate se retrouve avec une empreinte md5 crypté sur 128 bits, totalement inutilisable donc puisque le système de connexion réclame impérativement un mot de passe en clair... même moi en ayant accès a phpMyAdmin, je ne peux que changer les mots de passe si je veux me connecter a un compte dont je n'ai pas l'accès.

Sauf que ton serveur reçoit quoi? Des requêtes.

Et en analysant le code source client, une personne, avec un hash md5 du password et le login, pourrait reconstruire une requête HTTP qui permettrait l'identification ^^

(Hey, coder un serveur HTTP en guise de projet à l'école, ça aide à voir pleins d'attaques ^^ surtout que c'est hyper simple de construire des requêtes HTTPs)

Euh, analyser le code source client ? Mouais, juste l'implémentation Javascript de l'algo md5 et un peu de xhtml... ça sert aussi à ça le PHP.

Tu me dis donc qu'avec juste ça on peux casser facilement le système de login ?

On peut se faire passer pour quelqu'un d'autre oui xD

Regarde ce que tu envoies comme données en POST, et réfléchis bien, tu comprendras..

C'est pour ça que je cherche un moyen qui permettra d'envoyer une footprint du mot de passe différente à chaque session.

Même en vérifiant l'ip de la session ?


J'envoie uniquement le login et la footprint, en appelant cette fonction au passage :

function submit_pass()
{
pass=document.forms['log'].passwd.value; document.forms['log'].passwd.value="";
buf=MD5(pass);
document.forms['log'].md5.value=buf;
document.forms['log'].submit;
return false;
}

C'est tout ce qu'on peux intercepter. La, je sèche ;)

Autrement pour ton truc, peut-être en utilisant l'heure locale du serveur comme donné pseudo-aléatoire ?
En fait ça me parait difficile de faire passer une donnée supplémentaire qui doit être connue a la fois du client et du serveur, sans avoir un danger d'interception comme le reste.

un PC est identifiable par son IP uniquement. Le reste est falsifiable (l'ip aussi, mais ça devient du très haut niveau là)

Moi si j'intercepte ton hash MD5 au passage, j'aurais un hash valide, t'es bien d'accord? Ce hash me sert donc de password,puisque le serveur l'accepte quelque soit la session.

Donc ensuite, si je m'arrange pour faire une page trafiquée qui réutilise ce hash, je pourrais me logger facilement ^^ IP différente, ou non

Tu vois l'idée?

Donc moi ce que je pense qu'il faut faire, c'est, d'une, une vérification de session par adresse IP, et de deux, une autre valeur qui va affecter le hash du password, et qui va en donner un nouveau qui ne sera valide que pour cette session.

D'accord, la je pige mieux ^^
enfin bon faudrai encore casser le mot de passe MySQL (qui est en dur dans le fichier PHP de configuration, donc...)

Autrement, que pense tu d'utiliser justement cet fameux numéro ip pour obtenir une chaine de caractères et affecter le hash avec ?

Niveau client, on modifie le hash et on l'envoie classiquement au serveur.
Le serveur, lui, récupère l'ip du client et effectue la même maneuvre. Si les deux correspondent c'est OK, autrement ça bloque.
A moins de falsifier l'ip ce qui est, comme tu dis, de la haute volée.

Par contre, gaffe aux ip justement...
Derrière un routeur X.X.X.X tu peux avoir un 192.168.Y.Y ^^

Mais l'idée est là, c'est comme ça que je voulais te mener en fait. Je pense qu'il doit y avoir encore mieux ^^

Oui lol, mais généralement on obtiens toujours au moins l'ip de la box locale...

Encore mieux... surement. C'est domage qu'on ne puisse pas récupérer l'adresse MAC du client (et non celle d'un des multiples hubs qui sont sur le chemin), en combinaison avec l'ip ça serait une technique imparable.

En tout cas ton idée est très très intéressante.

Le mieux ça serait de passer toute les requêtes en post, faire un algo de cryptage de ouf et tout. Mais là tu recodes une sorte de SSL et donc... autant le mettre :p

Effectivement... mais tu ne pense pas que ça pourais être une idée sympa ? SSL n'est pas infaillible, loin de la
Pis si on est parano on s'arrange pour passer en plus par une connexion SSL... quoique je ne sais pas si c'est possible, j'ai pas étudié assez SSL