|
Publicité ' | |||||||||||||||||||||||
|
|
#1 |
|
Membre habitué
![]() Inscription : mai 2002 Messages : 635 ![]() |
Bonjour,
Est-ce que cela sert vraiment, selon vous, à crypter/décrypter certaines données dans une base de données ? Je m'explique, si la base de données est piratée, alors c'est que le site Web l'est aussi. On a forcément les identifiants de connexion donc un accès au site et aux algos de cryptage finalement à tout ! Par conséquent, la sécurité n'est-elle pas une protection absolue aux répertoires contenant les fichiers de configurations plutôt qu'à l'encryptage des données stockées en base ? merci |
|
|
00
|
|
|
#2 | |
|
Membre chevronné
![]() Ingénieur développement logiciels Inscription : août 2003 Messages : 581 ![]() |
Citation:
il y a (à mon sens) une petite faille dans ton raisonnement. 1°) Ce n'est pas parce que tu as réussi à "pirater" la base de données que tu as accès aux sources du site (quand bien même les sources du sites seraient situées sur le même serveur que la base de données) 2°) "On a forcément les identifiants de connexion" > en général, les login sont stockés en clair dans la base de données, donc, oui, tu (enfin le pirate Il est clair que si tu as un algo fait maison (et facilement inversable), qu'en plus tu as les codes source de l'algo, ta fonction de cryptage va pas faire long feu. Heureusement, il existe des fonctions assez bien faites et disons "standards", comme MD5. Attention, je ne dis pas que MD5 est incassable, mais il faudra un peu de temps et de persévérance pour ça, et ça devrait suffir pour protéger ton site web. J'espère avoir été clair. N'hésite pas à demander des eclaircissement sinon. a+, nako. |
|
|
|
00
|
|
|
#3 | |
|
Membre habitué
![]() Inscription : mai 2002 Messages : 635 ![]() |
Si tu as réussi à pirater la base de données c que tu as les identifiants de connexion à la base et qui te permettent d'y accéder...donc va pas falloir longtemps pour avoir accès au site. Tu les dis toi-même
Citation:
Par conséquent md5() est inutilisable dans mon cas... |
|
|
|
00
|
|
|
#4 | |
|
Membre émérite
![]() |
Citation:
ou alors tu changes de stratégie en recréant un nouveau mot de passe quand le client les a perdu. Mais la question que je me pose alors c'est: Est ce que le pirate peut faire un update de la base de données pour changer le champ "password" par ce qu'il veut et ainsi accèder au site? |
|
|
|
00
|
|
|
#5 |
|
Membre habitué
![]() Inscription : mai 2002 Messages : 635 ![]() |
exactement il peut le faire ! tu crées un md5 de ton mot de passe et tu l'insères dans les champs mot de passe de la base et le tour est joué
|
|
|
00
|
|
|
#6 |
|
Expert Confirmé Sénior
![]() Inscription : septembre 2004 Messages : 5 421 ![]() |
Il faut savoir aussi que les utiisateurs utilisent les mêmes mots de passe sur plusieurs sites différents. Et savoir que mon mot de passe que j'utilise ailleurs est stocké en clair me rend un poil paranoiaque...
Et de toutes façons, deux précautions valent mieux qu'une
__________________
Get your motor runnin' Head out on the highway... |
|
|
00
|
|
|
#7 |
|
Membre émérite
![]() |
On est parti du postulat que quelqu'un avait accès à la base de donnée, mais quelle est la faisabilité d'une telle intrusion ?
|
|
|
00
|
|
|
#8 |
|
Membre Expert
![]() ![]() Inscription : janvier 2004 Messages : 1 238 ![]() |
en php il est *relativement* simple d'acceder a la base de donnée depuis un site mal programmé. de plus, il ne faut pas oublier "l'ennemi interieur". Si tu stocke tes mots de passe en clair dans ta base de donnée, tu y a acces (c'est a dire que tu peux voir les passwords de tes utilisateurs) mais ton hebergeur y a acces aussi ! En général on peut lui faire confiance, mais une entreprise comme un autre, avec des gens qui bougent, des stagiaires, etc... si ton site commence a devenir important et connu, c'est une chose a prendre en compte je pense.
Edit : Dans ce cas là, l'hebergeur peux aussi modifier les données, mais il est plus intelligent de "juste" regarder les mots de passe en clair, puis se connecter au site avec le bon mot de passe, ou encore d'utiliser cette connaissance du mot de passe pour l'utiliser sur un autre site avec le meme utilisateur (car comme l'a dit Mr N. on a tendance a utiliser les memes mots de passe sur plusieurs sites)
__________________
PHP : Regle n°1 : mysql_query(...), mysql_connect(...) et mysq_select_db(...) doivent EN DEBUG etre suivies de or die(mysql_error()); (mais jamais en production) Regle n°2 : Mieux encore : mysql_query($requete) or die("$requete<br/>".mysql_error()); Regle n°3 : echo '<pre>';var_dump($var);echo '</pre>'; affiche le contenu et le type d'une variable. Publiez vos textes de fantasy et de science-fiction sur http://www.cercledefaeries.com/concours/ |
|
|
00
|
|
|
#9 | |
|
Membre du Club
![]() Inscription : février 2006 Messages : 99 ![]() |
Citation:
merci par avance |
|
|
|
00
|
|
|
#10 |
|
Membre confirmé
![]() Inscription : décembre 2006 Messages : 297 ![]() |
Si tu es face à un «Pirate malin», il fera un copie de ton site sur un de ses serveurs, pour ensuite accédé comme toi, avec une administration classique (même si protégé par mot de passe, il peut toujours «nulled» la parti authentification de l'administration du site qu'il aura copier sur son serveur).
Ensuite, il pourra accédé à ta base de donnée de tel manière que le cryptage de lui poseras aucun problème (il est même fort possible qu'il ne sache même pas que la base est crypté). Sinon, je sais qu'en fonction des hébergeurs, il est possible que si il trouves des choses étrange dans ta base de donnée (base de donné crypter = donnée illégale), ils peuvent (selon leur CGV) te suspendre ton compte. |
|
|
00
|
|
|
#11 |
|
Membre émérite
![]() Inscription : août 2006 Messages : 943 ![]() |
....On aspire pas comme ca un site dynamique.....
Tout ce que le client voit, c'est ses pages HTML, et ses GET et POST. Si quelqu'un arrive à te chopper ton site entièrement (administration, etc....) ca viendra surtout d'une grosse faille serveur, et pas de la programmation du site....
__________________
Veni Vidi Vici ------------------------- Mes articles : developpez.com ou bien vbview.net ------------------------- Et SURTOUT ne pas oublier la bible PHP : --> php_manual_fr.chm!!! Et aussi : --> pear_manual_fr.chm!!! Ou encore : --> Les tutoriaux & cours PHP de Développez.com ------------------------- |
|
|
00
|
|
|
#12 |
|
Membre confirmé
![]() Inscription : décembre 2006 Messages : 297 ![]() |
non, mais je disait une copie du site, la source PHP, si il pirate le site et qu'il peut avoir le «config.php» avec les login et mot de passe de la base de donnée, il est claire qu'il peut avoir facilement tout supprimer, ou encore tout recopier ailleurs
(dans la probabilité ou il arrive à trouver une faille qui lui permet d'avoir un accès totale) viny : «si la base de données est piratée» Mais c'est claire que de toute façon pour arrivé à avoir la possibilité de lire la source d'un fichier PHP il faut une faille très critique. |
|
|
00
|
|
|
#13 | |
|
Membre du Club
![]() Inscription : février 2006 Messages : 99 ![]() |
Citation:
|
|
|
|
00
|
|
|
#14 |
|
Membre confirmé
![]() Inscription : décembre 2006 Messages : 297 ![]() |
Je sais que la plus par du temps, si tu cryptes des données dans une base, l'hebergeurs qui à pour obligation d'interdire (sans quoi il peut avoir des problèmes) des contenues tel que:
pédophilie, protégé, raciste... Si il ne peut pas contrôler |
|
|
00
|
|
|
#15 |
|
Membre Expert
![]() ![]() Inscription : janvier 2004 Messages : 1 238 ![]() |
Pour ce qui est du contournement d'une partie admin, oui, il faut une faille dans le code php... mais il est hélas tres fréquent d'en trouver.
Bien souvent une telle faille a pour origine : * une mauvaise configuration de l'hebergeur (donc il faut faire tres attention si c'est un hebergeur spécialisé ou un p'tit hebergeur qui n'a pas l'habitude. Si c'est un "grand compte" genre free, wanadoo, ou autre, y a moins de chances mais c'est pas un gage de sécurité absolue quand meme) * Une absence de tests poussés par le developpeurs du site * Une méconnaissance par le developpeur des possibilités de failles et d'attaque Pour résoudre le dernier point, je ne peux que vous conseiller de lire les articles disponibles ici : http://www.phpsecure.info/v2/zone/pArticle Les articles sont super vieux mais hélas toujours d'actualité. Il s'agit d'une "introduction" plutot complete sur les failles les plus courantes. Reste peut etre les failles de Cross Site Scripting, mais je vous laisse google pour ca ;o) Crypter toutes les données d'une base de données ne me parait pas pertinent... Il te faut determiner a quoi sert le cryptage avant de l'employer : * Cryptage non bijectif (md5, sha1, crypt mysql) Utile pour les mots de passe : le mot de passe n'est pas stocké en clair dans la base de données, donc quelqu'un qui a acces en lecture a la base ne peux *theoriquement* pas retrouver le mot de passe d'origine (ce n'est pas tout a fait vrai, mais y a pas tellement de meilleur systeme... alors autant prendre "le moins pire") * Cryptage bijectif (xor ou avec clé publique/privée) Là tu indique clairement que tu souhaites pouvoir décrypter les données. Donc quelque part, ton site contient l'algorithme qui permet de faire ca. Donc qqun qui a acces a ta base en lecture a des chances d'avoir acces a ton code source php. Le seul moyen pour que ca ne lui permette pas de décrypter tes données c'est de demander a ton internaute, a chaque visite, de copier/coller dans un formulaire une clé de cryptage de 2km de long pour travailler avec ;o) Bref, les données de ta base étant "figées" (ie : elles ne se déplacent pas sur le réseau) je ne pense pas qu'il soit besoin de les crypter. Eventuellement tu peux les crypter avant de les envoyer a l'internaute, et les décrypter sur le poste client en javascript par exemple ou avec un autre moyen. Apres ca depend... si tu veux stocker la position géographique des groupuscules terroristes que tu dirige, forcement, vaux mieux eviter de mettre ca en clair ;o))
__________________
PHP : Regle n°1 : mysql_query(...), mysql_connect(...) et mysq_select_db(...) doivent EN DEBUG etre suivies de or die(mysql_error()); (mais jamais en production) Regle n°2 : Mieux encore : mysql_query($requete) or die("$requete<br/>".mysql_error()); Regle n°3 : echo '<pre>';var_dump($var);echo '</pre>'; affiche le contenu et le type d'une variable. Publiez vos textes de fantasy et de science-fiction sur http://www.cercledefaeries.com/concours/ |
|
|
00
|
|
|
#16 |
|
Membre confirmé
![]() Matthieu Étudiant Inscription : septembre 2004 Messages : 381 ![]() |
Personnellement , pour la sécurité , je script en md5 le mot de passe , et je fait une sauvegarde de ma base de donnée . ( les sauvegarde peuvent être intéressante en cas de bug , qui détruise la base de donnée )
En cas d'attaque , soit le pirate , veux détruire , donc , tu as une copie . Soit il veux usurper l'identité , une solution , si sa arrive , bloquer tout les compte qui as réussi a avoir et envoyer un mail pour réactiver .... Enfin , pour éviter les attaque de force , pour avoir le mot de passe : tu laisse un nombre limite de chance par login pour taper son mot de passe . Pour un site standard , sa suffit largement Enfin , si tu as des données fort importante .... 1 l'héberger dois être sécuriser , 2 un cryptage de la base de donnée , est nécessaire ... ( mais , le serveur prendras plus de temps pour crypter / décrypter la base de donnée ) |
|
|
00
|
|
|
#17 |
|
Membre du Club
![]() Inscription : février 2006 Messages : 99 ![]() |
ok c'etait bien interessant ton post Fladnag, je vais lire le site que tu as donné en lien il a l'air de bien renseigner sur le sujet
au niveau de mes mots de passe ils sont hashés en SHA1 avec un mot généré aléatoirement stocké dans la BDD, j'ai lu ça je sais plus où sur le site ça permet de ne pas créer des dictionnaires (2 mots de passe identiques = 2 hash SHA1 différents). au niveau de mes données à crypter oui je pensais faire avec une clé générée par le nom d'utilisateur ou un truc dans le genre, mais ca ne serait utile que dans le cas où le pirate n'a accès qu'à la BDD et non au code source (sinon il retrouve l'algorithme et hop c'est fini), mais je pense tout stocker en clair finalement. Je vais rajouter aussi une limite de connexions ratées au delà de laquelle le compte sera bloqué, merci de m'avoir donner l'idée. Sinon niveau serveur c'est un PC que j'ai moi même configuré sous Linux donc là je peux pas garantir la sécurité en tout cas merci beaucoup à tous |
|
|
00
|
Copyright © 2000-2012 - www.developpez.com