Yep on est d'accord.
Disons que je trouve l'approche "égoïste" de dire "c'est bon de toutes façons s'il a accès à la base de données c'est mort". Pour moi non, on peut et doit protéger les données de nos membres/clients.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Yep on est d'accord.
Disons que je trouve l'approche "égoïste" de dire "c'est bon de toutes façons s'il a accès à la base de données c'est mort". Pour moi non, on peut et doit protéger les données de nos membres/clients.
J'ai l'impression que (sans ssl bien entendu) :
1) Soit on rend inutilisable ce qui transite sur le réseau avec un grain de sel qui change à chaque fois (le sniffeur ne saura pas quoi renvoyer la prochaine fois) mais alors la page de vérification doit pouvoir reconstituer ce qui doit etre recu (et du coup un type qui a accès à la base aussi)
--> faire envoyer par le javascript md5(GDS+md5(mdp))
--> On vérifie coté serveur en comparant md5(GDS + le md5(mdp) de la bd) avec ce qui arrive
Au passage il me semble que le grain de sel n'est pas forcé d'être unique à l'utilisateur mais peut etre unique par session ce qui évite d'avoir 2 formulaires.
2) Soit on rend inutilisable ce qu'il y a dans la base mais c'est la même chaine qui transitera toujours sur le réseau (et donc un sniffeur pourra l'intercepter et la renvoyer pour s'autentifier)
--> faire envoyer en javascript md5(mdp + GDS constant)
--> On vérifie coté serveur en calculant md5(de ce qui arrive) et en le comparant avec la base
Je sais pas si je suis très clair
Mais bon c'est largement suffisant dans les 2 cas pour moi !
Concernant le Grain de Sel dite dynamique doit être le même du coté client que le coté Serveur pour qu'il puisse faire la comparaison. ?
Salut!
Nous avions déjà discuté de ce problème
http://www.developpez.net/forums/sho....php?t=14438#4
La technique du grain de sel ne me semble pas pertinante.Envoyé par m@
A partir du hash MD5 un hacker pourrait donc retrouver des chaînes encryptés du genre :
lula{grain1}
04janvier{grain2}
roxxorbill{grain3}
Il est aussi à parier que puisque le hacker connait les MD5 il est aussi probablement en possession des grains.
Alors combien de génie lui faudra-t-il pour casser la deuxième couche d'encryption et donc retrouver les chaînes lula, 04janvier et roxxorbill ?
Bien peu, j'en ai peur.
Bah non.
Avec la technique du grain de sel, le hacker ne peut plus trouver le mdp par du reverse md5. il voit passer un md5(mdp+gds), comme le grain de sel change à chaque connexion, il ne peut plus s'identifier comme cela.
Apres quand il voit passer un md5(mdp+gds), et qu'il connait le grain de sel, c'est pas facile de retrouver le mdp.
O_O
Si je susi un hacker (je ne le suis pas) que je capte un MD5, que je retrouve la chaîne cryptée "Maxoo@kz654" et que je connais le grain de sel "@kz654", je retrouve "Maxoo".
Maintenant si je ne connais pas le grain de sel et que j'intercepte plusieurs MD5 que je décrypte et que j'obtiens "Maxoo@kz654", "Maxoo#qs123", "Maxoo§sf667", je retrouve encore "Maxoo".
PS : Si ton MDP est "Maxoo", prends en à toi même
on peut pas faire un md5 inverse !!
tu peux juste tester avec des dico si en prenant chaque mot tu va retourner au meme md5 !!
imaginons mon mdp Maxoo avec un gds : Maxoo123 -> fera un md5
le mec cherche pleins de mot qui peuvent faire ce md5, tu peux trouver des fois plusieurs mot qui correspondent au meme md5 : donc par exemple il trouve toto, apres il faut qu'il sache quel partie est le mdp quel partie est le gds, en plus dans ce cas, il n'a meme pas trouvé mon bon mdp.
avec SHA-1 c'est encore plus vrai.
Pour résumé : quand tu hash (et pas crypte, parce qu'on peut pas décrypter) en md5 tu peux pas retrouver le mdp qui était a l'origine.
C'est pour ca que c'est déja pratique un md5 tout seul, mais du coup un hacker peur envoyer direct le md5 au serveur et se faire passer pour toi sans connaitre ton mdp, du coup avec le gds tu es tranquille
Ce n'est pas moi qui avait émis l'hypothèse que le hacker ait un dictionnaire complet des chaînes de caractères vers leur MD5 (et donc puisse retrouver une chaîne à partir du MD5)on peut pas faire un md5 inverse !!
tu peux juste tester avec des dico si en prenant chaque mot tu va retourner au meme md5 !!
imaginons mon mdp Maxoo avec un gds : Maxoo123 -> fera un md5
le mec cherche pleins de mot qui peuvent faire ce md5, tu peux trouver des fois plusieurs mot qui correspondent au meme md5 : donc par exemple il trouve toto, apres il faut qu'il sache quel partie est le mdp quel partie est le gds, en plus dans ce cas, il n'a meme pas trouvé mon bon mdp.
avec SHA-1 c'est encore plus vrai.
Pour résumé : quand tu hash (et pas crypte, parce qu'on peut pas décrypter) en md5 tu peux pas retrouver le mdp qui était a l'origine.
C'est pour ca que c'est déja pratique un md5 tout seul, mais du coup un hacker peur envoyer direct le md5 au serveur et se faire passer pour toi sans connaitre ton mdp, du coup avec le gds tu es tranquille
=> http://sub0.developpez.com/php/m@/authentification.htm
Une chose m'échappe dans ce que tu dis.
Le serveur connait le GDS mais pas le MDP en clair (sinon gros risque*), comment fait-il alors la vérification de la correspondance avec le MD5(MDP + GDS) que lui envera le client ?
* Exemple de gros risque : l'administrateur aura accès au MDP en clair et vu que les utilisateur ont rarement un MDP distinct par application/site, l'administrateur pourrait se faire passer pour l'utilisateur ailleurs.
Hint : md5($salt . md5($clear_password) . $salt)
Cela ne représente aucun élément de réponse à ma question.
Le client n'envoie pas le mot de passe en clair mais le MD5 du mot de passe.
Nous en avons déjà discuté longuement dans ce sujet-même...
Comme le dit Yogui faudrait peut etre que tu lises tout le topic
Je sais c'est long, mais tu aurais les réponses à tes questions !!
Sur la BDD le mdp est en md5.* Exemple de gros risque : l'administrateur aura accès au MDP en clair et vu que les utilisateur ont rarement un MDP distinct par application/site, l'administrateur pourrait se faire passer pour l'utilisateur ailleurs.
de plus si les utilisateurs mettent des mdp comme toto ou autres, c'est leur problèmes.
Et nous avons toujours dit que la seul méthode sécurisée était SSL, mais un grain de sel sur le mdp c'est un plus.
Yogui j'ai une question, par exemple sur un serveur super sécurisé avec SSL et tout, et bien protégé.
Quand l'administrateur du site va uploader des fichiers, il passe par FTP, hors il n'est pas sécurisé ce protocole ... non ?
Et par exemple la BDD de developpez.net pour le forum, l'administrateur passe par une connexion sécurisé ou un ssh sur la machine pour accéder à la BDD ou ca passe en clair sur internet ?
Car en fait je me dis que si un site est sécurisé mais que meme si le mdp de l'admin est super compliqué et pas trouvable en brutal force ou dico, si les transferts ne sont pas en sécurisé, ca sert pas à grand chose ...
SSH n'est pas un protocole de transport mais un layer d'encryption. Il peut être appliqué à HTTP (https://), FTP (ftps://) et certainement à d'autres protocoles de transfert (pourquoi pas un e2dks://, par exemple).
Quand l'admin d'un site uploade des fichiers, il ne touche pas à la BDD. S'il veut toucher à la BDD, il peut effectivement utiliser SSH (donc sécurisé, comme son nom l'indique) ou n'importe quelle interface Web mise en place (qui utilise donc éventuellement un système comme SSL).
Tu pourrais toi aussi lire ce sujet : il a été proposé que le mdp soit encodé en MD5 côté client, transmis au site puis encodé à nouveau par le serveur. Cela permet de ne jamais transférer le mot de passe en clair par Internet et de ne pas stocker en BDD ce qui est envoyé par le client en tant que mot de passe.
Bien sûr, somme tu l'as dit, SSL serait une garantie supplémentaire.
je parlais juste des admins ...
je savais pas qu'on pouvait appliqué SSL à ftp ou autre ...
parce que si on a SSL et qu'on se connecte à la bdd via une interface web (phpMyAdmin par exemple) et qu'on a SSL : pas de probleme, mais dans ma tête c'était plutôt le FTP qui poserait des problemes.
Mais si on peut le forcer à être sécurisé, c'est cool
je l'ai lu
Et je vois pas bien trop à quel question tu me réponds la ... je suis tout a fait d'accord avec ce que tu dis et je l'ai toujours dit.
Là :Non, ça ne passe pas en clair. Enfin, ça dépend des forums et de la configuration du navigateur... Disons que ça pourrait ne pas passer en clair.l'administrateur passe par une connexion sécurisé ou un ssh sur la machine pour accéder à la BDD ou ca passe en clair sur internet ?
Oui je comprend, mais donc pour une modification d'une BDD sur un serveur qui n'a pas de SSL, on peut faire ce hashage en md5 avec ou pas gds dont on parle depuis tout a l'heure, mais ce n'est donc pas sécuritaire à fond.
Sécurités sans fin
Bonjour,
Je voudrai aussi mettre mon grain de sel. Bien qu'ayant plusieurs sites spécialisés, je suis encore débutant en PHP et MYSQL et travaille justement sur un système "préfabriqué" en GPL, ou j'ai extirpé les fonctionnalités de l'application pour en faire un fichier d'inscription centralisé pour plusieurs BD.
Ne comprenant pas tout ce qui se dit ici, j'essaye de mieux comprendre pour installer le plus de sécurités. Celà fait longtemps que je ne crois plus à la sécurité 100%! Mes sites ont été moultes fois hackés, on a même installé sur mon hébergement un site de pishing Paypal! Mon propre hébergeur a été hacké rien qu'il y a quelques semaines et sur tout le contenu!
La question que je me pose: Dans mon système, les mdp circulent en clair par des Get ou Post, mais seulement pendant le processus de connexion. Une fois collectés, ces donnés sont simplement encryptés par un MD5 coté php qui a aucun moment ne circule ni dans les variables cession, ni par des Get et Post. Dès que je le pourrai, je placerai en https, j'en ai la possibilité technique.
Le mdp figure encrypté dans la base de données. Avec plein accès à la Mysql, je ne puis pas savoir un mdp membre en clair et même pas le mien!
Le MD5 est tranquillement inséré dans un fichier texte tiers, mais qui pourrait facilement être modifié en extention indécriptable et protections d'accès. A terme j'envisage un MD5 alternant et varié.
Login persistant par cookie sur demande du visiteur. A lui de savoir si oui ou non il peut faire confiance à son entourage.
Je pense que celà est suffisant à un taux de sécurité avoisinnant les 99%.
Il est intéressant de voir ce que font les banquiers.... la banque postale par exemple. La saisie du mdp passe par des chiffres-images, un mouseover ... même pas de click! dont les chiffres ne sont jamais au même endroit!
D'autres ont un système d'appel de code aléatoire prédéfini et envoyé par liste de 100 et uniquement par courrier. Lors d'une saisie importante, transaction financière, un numéro de code est demandé aléatoirement et seul celui qui a le courrier papier peut alors répondre correctement!
Question: Peut-on trouver le MD5 si on a le mdp ? et en combien de temps ??
Rodolphe
je suppose que tu voulais demander si on peut trouver le MDP si on a le MD5.
parce que dans le cas contraire, c'est immédiat (cf : fonction md5 en PHP par exemple)
pour l'inverse, il faut avoir les tables, en effet, MD5 étant de par sa nature limité, il suffit d'avoir une table listant tous les MD5 possibles et une chaîne les générant (sachant qu'il y a forcément plusieurs chaines pour un MD5 donné).
Ensuite, il y a le problème des grains de sel. Admettons que tu ajoutes ".motdepasse.monsite.com" à la fin des mots de passe avant d'en faire un md5. Dans ce cas, le hacker récupérera le md5 et avec sa table aura une chaine qui génère directement ce md5, qu'il soumettra en tant que mot de passe. Comme tu ajoutera ".motdepasse.monsite.com" à la fin du mot de passe soumis, tu auras md5 différent de ce qu'il attendait, et de fait ses tables ne seront plus valident.
regénérer des tables de md5 soumises à un grain de sel est non-trivial (il faut d'abord récupérer de nombreux md5 "sablés" pour pouvoir extraire le grain de sable, puis regénérer la table en prenant compte du grain de sable (ce qui déjà en soit est assez long
un grain de sable peut-être le simple ajout d'un caractère au début de la chaîne, le tout est que ça modifie le md5 associé à un mot de passe.
Ensuite, avoir accès au md5 d'un mot de passe implique qu'il ait déjà accès à la bdd (ou aux cookies j'ignore comment tu les valides).
Et avoir accès à de nombreux md5 pour trouver le grain de sable implique d'avoir accès aux transactions MySQL par exemple...
Autrement dit, ça implique de déjà pirater à un haut point le site... et dans ce cas, le md5 peut généralement être contourné (création d'un compte root pirate, copie du cookie, etc...)
Ensuite, il ne faut pas regarder uniquement la sécurité de ton appli, il faut que les serveurs soient eux aussi sécurisés
Répondre avec citation
Partager