Reprise du message précédent :

 

 
Je suis désolé mais si tu génére le hash MD5 à partir d'un numéro de session PHP (qui represente 128 bits), tu peux t'accrocher pour le brute forcé, meme avec un super calculateur  

 
Et donc reprogrammer le système de sessions à la main ?
 
Quel est l'interêt ?

 
L'interet c'est qu'une session c'est dependant de divers infos pour être "valide" (IP etc... et c'etait ca le probleme). Alors que ma solution est independante et marche "toujours"  

Et si on pique le hash du password ?

 
Et comment tu veux le piquer ?    
 
Ca revient exactement au même qu'un pirate pique ton password et ensuite qu'il s'authentifie grace a lui et se fasse attribuer un numéro de session  

Ben pour pouvoir le transmettre à chaque page ? Ca veut dire qu'on peut le piquer, non ?

Bah pas vraiment, ca depend de beaucoup de parametres (surtout le "comment tu te connectes au net" : réseau d'entreprises ou modem adsl chez toi). Pour une sécurité maximale, il faut encrypter les transactions avec du SSL.  

Oui mais si tu fait du https alors l'ennoncé du probleme change ... et se simplifie vu que tu peux transmettre ce que tu veux sans avoir de problemes

 
Cela ne simplifie rien du tout. Ca garantie uniquement que les données ne seront pas interceptés par un tiers. Si le site a une faille quelconque, SSL ou pas, le pirate pourra s'authentifier  

 
Et que le site est bien celui qu'il déclare être dans son certificat (mais ça, personne ne vérifie)

Oui mais ca c'est completement accessoire dans le problème posé.  

 
attaque man in the middle

Mais tu crois que c'est la fete, man in the middle c'est vraiment pas orienté internet comme attaque    
 
C'est plus la petite PME avec un pirate sur le réseau local informatique...

 
C'est bien ce que je dis, ca simplifie, j'ai pas dit que ca résou. Mais au lieu de devoir faire gaffe au sniffing outre mesure,on peut se concentrer sur la securité du serveur

Bon, en somme, c'est presque impossible de sécuriser la chose à 100%

bein sur un dedié, avec SSL, et en forçant les utilisateurs a utiliser les cookies on arrive deja a un tot de securité qui est loin d'etre facile a contourner...

Bon, à part le SSL, je rempli les conditions.

faudrait te mettre a jour... ca fait longtemps qu'on a trouve des failles dans le md5 qui permettent de reduire dramatiquement le temps de calcul. Et meme le sha1 dispose d'uve faille.
 
Si tu veux vraiment utiliser une clef de hashing (ce qui n'est pas la bonne facon de faire, mais soit...), utilise de sha2.

 
Sources ?  

Euh... T'as hiberné dernièrement ? Tout le monde le sait

http://www.arnnet.com.au/index.php [...] ;16;fpid;0
 
entre autre...

 
Il y a une grosse différence entre la capacité de générer rapidement deux suites d'octets qui vont donner le meme hash MD5 (ce dont l'article parle) et pouvoir retrouver rapidement la suite d'octets qui a donné lieu à un hash MD5    
 
Ca n'a strictement rien a voir.    
 
A moins qu'il y est encore d'autres "flaw" dans le MD5 ?  

Est-ce que tu sais au moins que le md5 est irreversible et qu'il est donc IMPOSSIBLE d'etre sur que la chaine qui produit le md5 est l'originale?
 
Dans ce context, on se fout donc de l'original tant qu'on a une version qui matche.

Tout a fait, mais le problème est de savoir s'ils ont besoin de connaitre la premiere suite d'octets qui aboutit à un hash MD5 qu'on nommera "X". Si tel est le cas, ca revient a ce que je viens de dire, que c'est deux choses totalement différentes    
 
Par contre s'ils ont besoin de connaitre uniquement le hash MD5 "X" pour trouver x combinaisons de suites d'octets qui donnent ce hash MD5 "X", en un temps assez court, tu as raison.    
 
 

C'est assez technique tout ça ... pauv' newbie un peu largué ^^
 
Juste une question en passant : pour le dossier /sessions qui se trouve à la racine du serveur sur les comptes Free, est-il véritablement sécurisé avec un .htaccess en "deny from all" ou bien y-a-t'il autre chose à faire ? Contre les aspirateurs de site par exemple ?
 
PS : désolé de vous interrompre ^^°

http://faq.free.fr/?q=933

Non, c'est bon, j'avais déjà lu ça ^^.
 
Mais ce que je veux dire, c'est si à partir des fichiers stochés dans ce dossier session, un pirate pourrait éventuellement faire quelque chose ? Et si le bloquer avec un Htaccess suffit ...

Je n'ai jamais utilisé free, mais je pense que le repertoire doit être protéger "automatiquement". Tu n'as qu'à éssayer de le "pirater" pour voir si il y a besoin d'y mettre un .htaccess.

Ben s'il n'y a ni de Htaccess ni de fichier index dans le répertoire sessions, il y a moyen d'avoir accès à tout un tas de fichiers ...
Je ne sais pas les manipuler, donc c'est pour ça que je pose la question. Mais bon, avec le .htaccess ça devrait aller ^^ (espérons ...)

Tu as peut-être raison.  
Mais free a peut-être déjà mis une protection sur TOUT les répertoires sessions à la base de leurs sites.
 
Tu n'as qu'à éssayer de liste le contenu de ton repertoire /sessions ou de l'aspirer avec un logiciel. Tu verras bien le résultat et tu nous le feras partager.