olivierPa Posté 3 Mai 2009 Partager Posté 3 Mai 2009 (modifié) Bonjour a tous, Je cherche a monter un site web securise. Il doit etre accessible a certains membres. Les membres identifies doivent pouvoir effectuer certaines manipulations (lecture/ecritue) sur une base de donnees. Je veux minimiser les requetes a la base mysql pour que cela soit assez rapide et utiliser le + possible javascript pour la partie dynamique. Je voudrais donc faire la chose suivante: 1/ un membre se connecte a l'aide de son login/ password sur une page https 2/ il arrive sur son espace membre lui permettant de modifier les donnees le concernant. Les donnees en question ne sont pas sensibles: je me moque de savoir si qqun peut les lire. Par contre, lorsqu'une requete est envoyee pour modification des donnees sur la base mysql, je veux m'assurer que c'est bien le membre concerne qui effectue la requete. Comme les donnees ne sont pas sensibles, il me semble naturel d'utiliser le protocole http (et non https qui est plus lourd a gere a cause du codage des donnees transmises). Par contre, il m'importe que le membre soit identifie de maniere assez certaine par le serveur. Evidemment, je pourrais stocker le pwd du membre dans un cookie (j'ai egalement entendu parler de variable de session) et le transmettre au serveur a chaque requete qui verifie que le pwd correspond qu membre en question. Mais comme je ne veux plus utiliser de protocole https a ce stade, le pwd est transmis en clair du client au serveur, ce qui n'est pas terrible en terme de securite (et dans ce cas, utiliser une page https pour l'authentification est idiot). Ceci dit, il doit exister des solutions qui tiennent la route: On peut imaginer un systeme de ce type: - le membre se connecte sur une page https. Une fois identifie, il echange une cle (bon c'est ce que fait https d'ailleurs, mais la cle en question, je veux l'utiliser par la suite). On sort de la zone https pour rentrer dans une zone http. - le membre peut lire dans la base mysql, il modifie ses donnees puis envoie une requete au serveur pour sauver les modifications apportees. Afin de verifier l'identite du membre, on peut imaginer un processus de ce type: Avant chaque requete, le client fait une demande au serveur qui lui renvoie une chaine de caracteres aleatoires (appelons la x) Le client renvoie alors T(x) + les donnees necessaires pour la modification de la base de donnees. ou T(x) est le chiffrement de x a l aide de la cle commune echangee lors de la session https Le serveur recoit y + des donnees il verifie si y=T(x) (il connait la cle transmise a l'utilisateur lors de l'identification et la chaine x) si y=T(x) il modifie la base en consequence. Sinon, il ne fait rien. Je pense qu'un tel systeme serait "relativement sur" cependant, le systeme de chiffrement doit etre tel que si qqun interecepte (x,T(x)) pour un nombre relativement important de x, il ne puisse retrouver la cle. Quel algo utiliser pour le chiffrement ? Comment stocker la cle sur le navigateur du membre (cookie ? ou autre) ? Est-ce que vous avez un script (ou exemple de scirpt) qui fait ca ? Est-ce qu'il y a des outils tout pret prevus a cet effet ? Est-ce qu'il y a un autre moyen de s'assurer de l'identite d'un membre apres connection sur une page securisee https ? Desole, c'est un peu long, mais comme c'est mon premier site comportant un espace membre... et que je ne veux pas faire n'importe quoi. Olivier. PS: J'ai modifié mon message initial (dans mon precedent message, je proposais de generer la chaine x cote client ... alors qu'il faut evidemment la genere sur le serveur). Modifié 3 Mai 2009 par olivierPa Lien vers le commentaire Partager sur d’autres sites More sharing options...
Patrick Posté 3 Mai 2009 Partager Posté 3 Mai 2009 hum ... Tu te prends la tête pour pas grand chose ! Je ne comprends pas en quoi le protocole https est plus compliqué pour un webmaster que le protocole http ! Quelque soit le protocole utilisé le codage est le même (il faut juste penser à mettre tout tes liens en absolu avec https), donc en quoi c'est plus lourd ? Le https est la meilleure solution. Tu parles d'une identification sous https puis passage en http pour modifier les données. Cela me semble idiot, pourquoi ne pas rester en https tout le temps ? Comme ça tu évites tout risque de vol d'id de session et tu peux ainsi sécuriser tes pages avec une (ou plusieurs) variable de session. Bien sur il faut que tu sécurises un minimum tes formulaires de connexion et que tes pages soient correctement codées et là tu ne risques absolument rien. ++ Patrick Lien vers le commentaire Partager sur d’autres sites More sharing options...
olivierPa Posté 3 Mai 2009 Auteur Partager Posté 3 Mai 2009 Bonjour Patrick, Si je veux utiliser http plutot que https une fois l'identification effectuee c'est pour ecnomiser des ressources cote client et surtout serveur: Le https implique le cryptage de toutes les donnees echangee entre le client et le serveur.... et cela concomme du temps cpu. Du coup, cela peut avoir une influence sur la fluidie de la navigation et si j'ai bcp de connections simultannees sur mon serveur, il pourrait se retrouver surcharger. Comme les donnees que je transmets sont public, je n'ai absolument aucune raison de les crypter. Par contre je veux m'assurer de l'identite de l'utilisateur (identifie par son login et password. Je suppose evidemment que l'utilisateur ne va pas laisser trainer son login et password sur un post it sur son clavier, et sinon, tant pis pour ses pieds, de toute facon c'est pas le site de la banque de france que je veux monter non plus). Donc je nev eux pas transmettre le pwd du client en clair sur le reseau - je veux qu'il puisse ecrire sur la base de donnees (selon ses droits) sans qu'il ait a taper son login+pwd a chaque fois, d' ou l'idee de proceder comme decrit dans mon premier post. voila... Sinon je suis d'accord avec toi, tout faire en https est a priori le plus sur (un peu trop meme ). Olivier. Lien vers le commentaire Partager sur d’autres sites More sharing options...
Patrick Posté 3 Mai 2009 Partager Posté 3 Mai 2009 Entre la sécurité des utilisateurs (tout en https) et changer de serveur il n'y a pas photo ! Si tu penses que ton serveur ne tiendra pas la charge change le ! Je te rappelle que tu es responsable de la sécurité des données personnelles de tes clients. Faire des économies sur la sécurité n'est jamais, jamais une bonne solution ! Il existe des Core2Duo à la location pour moins de 100 / mois ou des Bi Xéon QuadCore pour moins de 150 / mois et ceux là avant de les mettre à genoux tu peux y aller ! Et puis si cela ne te suffit toujours pas il te reste le clustering. ++ Patrick Lien vers le commentaire Partager sur d’autres sites More sharing options...
olivierPa Posté 3 Mai 2009 Auteur Partager Posté 3 Mai 2009 Bon, j'ai compris, tu es pour le tout https. OK, si on lache 150 euros par moi, on peut louer une bete de course qui plantera jamais. Mais pourquoi chercher a faire souffrir un serveur pour rien ? Encore une fois, les donner des membres sont publics ! Seuls les droits de modifications de ces donnees sont a proteger. Si je peux obtenir ce que je veux pour moins cher et plus performant qu'une option tout https, je ne vois vraiment pas de raison de me priver.... olivier. Lien vers le commentaire Partager sur d’autres sites More sharing options...
Patrick Posté 3 Mai 2009 Partager Posté 3 Mai 2009 Les donnees en question ne sont pas sensibles: je me moque de savoir si qqun peut les lire. Encore une fois, les donner des membres sont publics ! Ce n'est pas tout à fait pareil ! Maintenant une bonne identification par session reste une solution très protégée si c'est bien fait. Il est totalement superflus de faire du chiffrement quelconque. Le https assure une sécurité supplémentaire, mais vu le faible niveau de sécurité de tes informations la solution de l'id de session est largement suffisante. Par curiosité, quelle est l'url de ce site à si fort trafic ? Patrick [Mode plaisanterie] Mais pourquoi chercher a faire souffrir un serveur pour rien ? La pauvre bête ! Il faut prévenir la SPSD ! [/Mode plaisanterie] Lien vers le commentaire Partager sur d’autres sites More sharing options...
olivierPa Posté 3 Mai 2009 Auteur Partager Posté 3 Mai 2009 Bon, pour le site a fort trafic en question, il n'existe pas encore. Si ca se trouve, il n'aura aucun membre ! Mais je prefere me pencher maintenant sur les problemes potentiels avant d'avoir a les resoudre par la suite. Pour l'identification, tu dis qu'il est totalement superflus de faire un chiffrement quelconque... Cela me semble un peu etrange: a priori, on peut intercepter tes paquets non chiffres transitant sur le web et ainsi recuperer login et pwd s'ils ne sont pas cryptés. Je ne suis pas certain qu'une identification par session soit tres sure d'apres ce que j'ai pu lire de ci de la (je suis novice en la matiere, c'est la premiere fois que je m'interesse a des questions de securite). Ce qui m'importe c'est juste de ne pas autoriser n'importe qui a ecrire dans les donnees associees a un membre (par contre, elles peuvent etre lues par n'importe qui). Je prefere etre prudent: je ne m'attends pas a subir une attaque quelconque, mais si cela arrivait, je serais vraiment dans la M... donc utiliser un tuc bien costaud pour l'identiification avec https (meme si c'est pas gratuit, c'est un investissement qui me semble minime pour la securite que cela apporte). En tout cas merci pour tes suggestions. Je vais reflechir a tout ca. Lien vers le commentaire Partager sur d’autres sites More sharing options...
Kioob Posté 3 Mai 2009 Partager Posté 3 Mai 2009 Bonsoir, le full HTTPS j'en suis revenu pour ma part, la navigation est en effet assez lourde, surtout de par le manque de cache coté navigateur. J'ai opté pour la même méthode que Google : je force l'HTTPS pour le formulaire de connexion et les quelques pages qui ont vraiment besoin de sécurité, mais le reste des pages/images/css/js se fait en clair. Bien sûr dans ces conditions comme l'indique Patrick le cookie de session n'est plus protégé, il faut donc avoir recours à d'autres mécanismes pour se protéger d'un vol de session. Un "bon" point de départ, à mon avis : - utiliser le mécanisme des sessions de PHP (évidement uniquement sur les parties où l'utilisateur doit être identifié) - y intégrer un contrôle d'expiration de session (PHP ne le fait pas, il possède uniquement un "garbage collector" qui se déclenche quand bon lui chante) - n'accepter les sessions que par cookie (c'est un paramètre de PHP) Cela limite déjà un peu les possibilités. Maintenant il y a d'autres méthodes à mettre en oeuvre, tout va dépendre de ton niveau de paranoïa : - https sur les formulaires et pages sensibles - "double ID" de session pour limiter les possibilités de vol de session - formulaires avec token de validité Et probablement d'autres. Lien vers le commentaire Partager sur d’autres sites More sharing options...
olivierPa Posté 3 Mai 2009 Auteur Partager Posté 3 Mai 2009 (modifié) Bonsoir Kloob, C'est pile-poil le genre de truc que je cherche (faire comme Google). Une identification sure, puis une communication en clair en s'assurant tout de fois contre le vol de session. Je me doutais que google utilisait une methode de ce genre. Merci pour les infos, je vais courrir a la peche aux infos sur la protection des sessions (je viens carrement de faire l'acquisition d'un bouquin sur la securite sur le web, bcp trop complet pour ce que je vais faire au final, mais bon, ca fait pas de mal d'apprendre des trucs). J'ai d'ailleurs decouvert sur ce bouquin que Mastercard s'etait vole plusieurs millions de numeros de cartes en 2005 a cause d'une faille de securite ! C'est assez dingue tout de meme. Modifié 3 Mai 2009 par olivierPa Lien vers le commentaire Partager sur d’autres sites More sharing options...
Sujets conseillés
Veuillez vous connecter pour commenter
Vous pourrez laisser un commentaire après vous êtes connecté.
Connectez-vous maintenant