CODAGE MD5 POUR MOT DE PASSE
coucou747
Messages postés
12303
Date d'inscription
mardi 10 février 2004
Statut
Membre
Dernière intervention
30 juillet 2012
-
25 févr. 2005 à 21:10
coucou747 Messages postés 12303 Date d'inscription mardi 10 février 2004 Statut Membre Dernière intervention 30 juillet 2012 - 16 oct. 2005 à 13:53
coucou747 Messages postés 12303 Date d'inscription mardi 10 février 2004 Statut Membre Dernière intervention 30 juillet 2012 - 16 oct. 2005 à 13:53
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/29769-codage-md5-pour-mot-de-passe
https://codes-sources.commentcamarche.net/source/29769-codage-md5-pour-mot-de-passe
16 oct. 2005 à 13:53
J'ai jamais aimé les failles de sécurité... cf mes dèrnières sources php...
Bon, à part ça, si on met les bons droits aux serveurs, sous linux, on ne risque pas grand chose...
16 oct. 2005 à 13:31
Perso c'et ce que j'en pense à discuter.
16 oct. 2005 à 10:39
c'est super ! pour connaitre comment faire pour utuiliser cette fonction ...
c'est bien expliquer ca permet aux gens qui ne connaisse pas la fonction de poster ceci sur le forum !
donc je met 10/10 pour l'explication donnée
27 sept. 2005 à 22:13
- Le mieux pour les vrais parano du cryptage sa serait de ne pas en faire !
- Et puis histoire de rassurer ceux qui ne le savait pas : les mots de passes des zones membres qui transitent (et sont donc lisible) ne sont PAS PIRE que le FTP qui fait exactement pareil (le mot de passe n'est pas crypté lors du login...) bon après il existe SFTP mais c'est une autre histoire ;-)
@+
10 juin 2005 à 15:25
Pour SSL, bah cherches sur google, les protocols, c'est pas super simple, le mieux, c'est d'apprendre juste la théorie pour comprendre, mais pas les protocols (quand on n'en a pas besoin)...
Je peux te passer de la doc sur RSA, AES, DES et les courbes éliptiques...
pour la sécuritée, lis misc...
10 juin 2005 à 14:54
10 juin 2005 à 14:52
5 juin 2005 à 19:10
5 juin 2005 à 19:07
5 juin 2005 à 19:05
Aussi pour une longueur de paire de clé RSA qui sera calculée avec javascript, je peux monter jusqu'à combien en étant raisonnable ?
(je vois déja les:"oh avec un bon 30cm tu peux monter jusqu'à 230 sur l'autoroute !" :))
5 juin 2005 à 17:08
Enfin bon, je reste certain que faut vraiment y aller pour tomber sur une de ces collisions. Il y a même des concours organisés par les laboratoires de crypto à ce sujet, c'est dire!
Alors je ne m'inquièterais pas trop CATMAN ;o)
5 juin 2005 à 16:40
Si on a plusieurs séquences différentes qui peuvent donner le même hash, ça n'a aucune importance que ce soit la bonne séquence ou pas, puisqu'à la comparaison on aura le même hash donc considéré comme valide.
On fait quoi dans ce cas là ?
5 juin 2005 à 14:14
5 juin 2005 à 11:16
PGP (http://www.pgpi.org/doc/pgpintro/#p16)
... The certificate holder's public key ? ... RSA, DH (Diffie-Hellman), or DSA (Digital Signature Algorithm)... The preferred symmetric encryption algorithmfor the key ? ... The supported algorithms are CAST, IDEA or Triple-DES.
GPG (http://www.gnupg.org/(en)/features.html)
... Does not use any patented algorithms.
RSA (http://www.x5.net/faqs/crypto/q22.html)
...RSA is patented under U.S. Patent 4,405,829, issued September 20, 1983
voilà voilà...
5 juin 2005 à 10:43
@malik7934
IDEA n'est pas libre de diffusion, dpnc tout le monde ne peut pas l'utiliser, donc, ca revient à peut près à la même chose que dit Antidote (le JS n'est pas forcément utilisé par le poste client).
5 juin 2005 à 00:18
4 juin 2005 à 23:11
Je remet pas en cause le possibilité de JS met plutot le coté aléatoire de son application. je préfère faire un calcul coté serveur au moins on ai sur qu'il sera éxécuter toujours de la même façon.
4 juin 2005 à 22:03
En revanche, gpg est la version gnu de pgp, et il génére aussi des clés rsa (entre autre).
4 juin 2005 à 20:02
Ceci dit, PGP utilise entre autre RSA, mais pas seulement -> IDEA. Et en ce qui concerne GPG, il n'utilise pas RSA...
4 juin 2005 à 19:23
et en js, tu peux gérer des grands nombres en faisant un iobj...
4 juin 2005 à 18:27
4 juin 2005 à 18:23
4 juin 2005 à 17:27
4 juin 2005 à 12:27
4 juin 2005 à 11:23
-le serveur cré une paire de clef publique qu'il envoi au client dans sa page
-le client tape son mot de passe
-du javascript crypte le mdp
-du php retrouve le password
ici, c'est impossible de trouver le mot de passe... Il faut cependant utiliser toujours la même clef pour le même client, et des clefs différentes pour les autres clients... Les mdp ne doivent pas non plus être trop courts...
4 juin 2005 à 03:43
4 juin 2005 à 01:26
3 juin 2005 à 18:07
3 juin 2005 à 11:45
3 juin 2005 à 08:08
3 juin 2005 à 00:44
Pour ceux qui serait interressé par une méthode d'identification HTTP de l'utilisateur par jeton, voici un lien (en anglais) vers une RFC : http://ftp.ics.uci.edu/pub/ietf/http/rfc2617.txt
3 juin 2005 à 00:11
En ce qui concerne le "déhashage" (le md5 produit bien un hash il me semble ?), il me semble que c'est evident, on parle pas de "déhasher" un md5 mais bien d'obtenir un hash identique à partir d'un dictionnaire ou d'un programme de type brute force.
2 juin 2005 à 23:02
J'aimerais bien que ceux qui sont capables de "déhasher" lèvent la main... car on dirait qu'il y en a par ici! ;o)
2 juin 2005 à 22:52
C'est vrai que dans ce cas, le hash plus la clé, si le message est un passe faible à trois caractères, la clé ne sert pas à grand chose.
Mais par exemple:
$login = "robert";
$pass = "simonepourtoujours";
$cle = nb_aléatoire();
$logpas = md5($login.$pass);
$result = md5($logpas.$cle);
tu pourras donc intercepter $result et clé. Mais là ça devient un peu plus hardu dans la mesure ou il y a deux inconnus concatenes et un troisieme qui est la méthode de calcul du hash final ($result).
Enfin, et c'est l'objetctif de la clé d'ailleurs, il est impossible d'envoyer ce que l'on a intercepté puisque $result sera à chaque fois différent.
Et en asymétrique ça donne quoi ? (je n'ai pas trouvé de methode grain de sel en asymétrique).
2 juin 2005 à 17:58
2 juin 2005 à 00:00
Le message envoyé par le poste client concaténé avec la clé renouvellée du serveur et le tout hashé en md5, c'est vraiment la meilleur solution.
25 mai 2005 à 08:48
Explications :
Imaginez un poste sur un réseau local (adresse ip privée, donc 10.x.x.x, ou 192.168.x.x, ...). Le client ne connaissant que cette adresse ip, et pas celle utilisée sur internet, l'adresse de cryptage sera par exemple, coté client, 192.168.1.1, et, à cause des administrateurs réseaux, sera 193.252.19.4. Or, ces deux adresses sont deux adresses valides, mais une est connue SEULEMENT du réseau local (192.168.1.1), alors que l'autre sera utilisée par le serveur Web pour crypter, et parce que les deux adresses, bien qu'appartenant au même ordinateur, ne donneront pas le même résultat lors du cryptage.
Le meilleur moyen est que le serveur génère une valeur ALÉATOIRE (un jeton), et l'envoie au client. C'est cette valeur qui sera utilisée par le client pour crypter. Mais surtout, il ne faut pas pouvoir deviner les valeurs précédentes, ni suivantes, et que le jeton ne soit utilisé QU'UNE ET UNE SEULE FOIS.
C'est le principe mis en jeu lors d'une authentification HTTP en mode digest, et par d'autres protocoles d'authentifications client/serveur.
24 mai 2005 à 20:54
enfin du coup en oblige le pirate à avoir un niveau suffisament élevé, et lui donner beaucoup de travail ;)
24 mai 2005 à 20:05
24 mai 2005 à 19:50
Et donc le mec ne pourra pas réutiliser le passe tel quel (en crypter dans la trame) car il n'aura pas la même ip et donc le serveur décryptera mais pas le bon mot de passe au final.
1 mars 2005 à 18:27
L'utilité des phrase ici c'est surtout d'expliquer le fonctionnement du script ^^
1 mars 2005 à 08:47
@ Antidote
je ne suis pas tout a fait d'accord avec ton petit script de connexion.
plutot que de mettre "mauvais mot de passe" ou "login inexistant", ce qui donne des indications aux hackers, met simplement "login ou mot de passe incorrect".
28 févr. 2005 à 19:58
28 févr. 2005 à 19:53
28 févr. 2005 à 19:49
" jour " est pris comme élément de la requête donc si j'entre une commande SQL à la place ....
ex : pseudo = bon' OR 1=1 --
les " -- " étant les commentaires de mysql donc ce qui est derrière n'est pas pris en compte. La condition de ta requête se retrouve toujours vrai et donc je suis logué avec le premier utilisateur entré dans la base qui trop souvent est l'administrateur du site. Je me retrouve donc avec les droit d'administration.
Petit exemple trèèèèèèèèèèès connu d'injection SQL dans un champ. Mais puisque c'est pour débutant autant le préciser.
CE N EST PAS POUR INSITER LES PETIT HACKER DEBUTANT.
Protège tes formulaires 'sensibles' qui ont des champ qui irons directement dans ta base.
par exemple met un petit addslashes() que tu relis avec un stripslashes() ...etc
Ensuite ta requête n'est toujours pas sécurisée même avec ça car on est pas à l'abri d'un petit malin qui pourrait passer.
fait pluôt :
if($r = mysql_query("SELECT * FROM matable WHERE pseudo='$pseudo'")) {
// vérifie l'existance du pseudo
if (mysql_num_rows($r) > 0) {
$o = mysql_fetch_object($r);
if ($o->password == $password) {
echo 'connecté';
}else {
die('Mauvais mot de passe');
}
} else {
die('Pseudo inexistant');
}
}
Ainsi même si le hacker passe avec une injection SQL il faudra qu'il rentre avec le bon mot de passe du premier utilisateur de la table.
Ce n'est qu'un exemple.
Débutant à vous de jouer !
PS : J'en profite pour y mettre un peu d'objet j'aime bien ^^
28 févr. 2005 à 08:56
Pour avoir une certainne honneteté vis à vis de l'utilisateur!
27 févr. 2005 à 13:20
27 févr. 2005 à 13:10
Je rappelle cependant que c'est réservé aux paranos... ;o)
27 févr. 2005 à 01:09
26 févr. 2005 à 23:33
26 févr. 2005 à 19:14
26 févr. 2005 à 18:48
on trouve aussi des méthodes de chiffrage (cryptage, crypter, ou autre, ne sont pas des mots français) pour https en AES 256 bits, d'après les certificats affichés par certains sites, tel, par exemple, https://sourceforge.net
Pour le chiffrage en md5 coté client en javascript, il suffit à l'intrut de capturer les trames du client pour récupérer le mot de passe chiffré en md5, puis de le renvoyer au serveur quand il en a besoin, donc, tel quel, ce n'est pas plus utile, si ce n'est beaucoup plus de code coté client, et empèche certains navigateurs internet, ne comprenant pas tout le code javascript, d'utiliser le site Web.
C'est une solution que je ne conseille à personne dans ce cas la, sans utilisation de rejeu.
Je vous laisse méditer tout ça.
26 févr. 2005 à 14:11
26 févr. 2005 à 14:10
donc déja free >> oust
et apres, google je sais pas en detail perso.
26 févr. 2005 à 14:10
plutot que de poster le password, il posteras le password chifré... au pire, il imiteras le comportement du navigateur dans une console en telnet...
26 févr. 2005 à 14:08
26 févr. 2005 à 13:52
on hash le mdp sur le poste client, il le renvoie, on compare, si saibon, saibon sinon spabon ...
Inekman : pour remedier au probleme de circulation en clair certains sites proposent une identification en ssl via https.
26 févr. 2005 à 13:45
26 févr. 2005 à 13:42
quand on sait analyser une trame réseau, on sait lancer telnet....
26 févr. 2005 à 13:22
Une solution serait de hasher le mot de passe sur le poste client à l'aide d'une implémentation javascript du md5 puis de balancer le mot de passe hashé sur le serveur pour l'insertion dans la base de données et là l'autre il l'a dans l'os.
Voilà, sinon, pour des débutants, y'a la base de ce qu'il faut savoir pour faire ce que tu as dis en haut dans la description du code.
Bravo.
26 févr. 2005 à 12:45
d'apres ce que j'ai lu ( question de rigueur quoi ), ça serait une transformation de chaîne dans un seul sens.
ce qui rend les mots de passé inrecuperables.
J'encourage quand meme la source.
5+
26 févr. 2005 à 12:42
quand on crypte, on a un mécanisme de décryptage (ou notre corespondant l'a)
26 févr. 2005 à 10:28
bon c'est quand meme plus une base qu'autre chose mais bon, au moins c'est crypté :)
bonne continuation en php.
25 févr. 2005 à 21:10
si je mettais toutes les pages de mon site sur celui là, j'aurais posté plus de sources...