Slu
si je stocke dans la variable de session l id du membre ... est ce que cela est suffisant pour l identifie sur l ensemble des pages reservé aux membres ?
thx @+
Version imprimable
Slu
si je stocke dans la variable de session l id du membre ... est ce que cela est suffisant pour l identifie sur l ensemble des pages reservé aux membres ?
thx @+
:salut:
si les register_globals sont à Off, l'utilisateur ne peut pas changer la variable de session, donc ça me parait suffisant... :D
maintenant si d'autres ont vu des cas où ce n'etait pas suffisant, je suis preneur, car moi c'est ce que j'utilise comme technique... :lol:
tu peux aussi te referer à ce thread ;)
ahhh ... il faut que je mette register_globals a off pour que le visiteur du site ne puisse pas modifie les variables globales (donc la variable SESSION) ... c bien cela ??Citation:
Envoyé par torvalds17
comment est ce que je mets register_globals a off ?
thx
regarde dans ton phpinfo() si c'est le cas... souvent ça depend de l'hebergeur, et on ne peut pas y toucher...
ok ...Citation:
Envoyé par torvalds17
donc si je ne px pas modifie register_global (et si je px comment on fait) sur l hebergeur je dois a chaque accés a une page reserve au membre verifie dans la base de donnée si l utilisateur est correcte ?
Salut, tu peux jeter un oeil ici : http://matthieu.developpez.com/authentification/#L4
Bon développement ;)
thx mais ca ne reponds pas a ma question :cry:Citation:
Envoyé par Nesmontou
Je ne sais pas trop ce que font les autres mais perso dans un accès restreint je stocke user+mdp et je réidentifie de manière transparente un utilisateur sur toutes ces pages.
C'est un peu plus securiser que l'id mais sa ne réponds pas aux critères de vols d'identifiant de session.
Pour cela, il faut regenerer l'id à chaque page, et imposer une duree de vie à ces sessions.
Du moins c'est ce qu'il en ressort de ce que j'ai pu lire sur l'article proposé par Nesmontou.
une autre soluce ... donc a chaque changement de page tu verifies, ds la bdd, le login et le mdp ?Citation:
Envoyé par ePoX
le mdp en md5 biensur ?
oui, et qu'on me sorte pas que sa impacte sur la rapidité d'une applicationCitation:
une autre soluce ... donc a chaque changement de page tu verifies, ds la bdd, le login et le mdp ?
bof non pour une toute simple raison : md5 n'est pas encore reversible (tant mieux), mais cela empeche une fonction pour retrouver les mdp oubliés.Citation:
le mdp en md5 biensur ?
Ceci dit, si tu cryptes les mots de passes et que la sécurité de ta base de donnée est compromise, à quoi sa sert de les avoir crypté ???
Je veux dire, prenons le cas d'un textebox mal protéger permettant à un attaquant d'executer des requetes en lecture (cas d'école).
En quoi le fait d'avoir crypter les mdp de mes clients rends leurs informations mieux sécurisée ??????
Ou alors,
Imaginons un brute force sur mon script de connexion, en quoi le fait d'avoir crypter les mdp de mes clients rends leurs informations plus sécurisée ???
....
bye
Pour retrouver un mot de passe oublié, tu génères un nouveau mot de passe et tu l'envoies à l'utilisateur par courriel. L'utilisateur pourra ensuite modifier son mot de passe.Citation:
Envoyé par ePoX
Oue sa réponds pas vraiment àl'objectif qui était de retrouver un mdp oublié.
le register_global se configure dans le php.ini
ePoX : j'ai déjà répondu à ce point il y a quelques jours : un très grand nombre d'utilisateurs utilisent le même mot de passe partout (au boulot, pour le compte en banque, sur le PC perso, sur les sites internet, sur les boites mails, etc).
Par conséquent même si pour toi ça ne change rien (une fois le site "hacké", tu n'es plus à ça pres), pour tes visiteurs ça peut changer beaucoup de choses. Donc par simple respect pour tes utilisateurs, il me semble évident que le mot de passe stocké ne doit pas être décryptable.
Généralement tu ne stockes que la hash md5 - il me semble qu'il y a un tutos à ce propos sur le sitE.
Le mieux est de le crypter directement avec un javascript dans le formulaire de login avant de l'envoyer sur le serveur.
Dans la base tu ne stocke qu'un hash md5 que tu compares avec le hash envoyé par le client.
Je suis d'accord avec kioob - il vaut mieux rénitialisé le pass que de pouvoir le lire.
Citation:
Envoyé par ePoX
Perso je ne vois pas du tout ce que cela apporte de plus à la session : le mot de passe ne va certainement pas changer durant la durée de la session, et avant de stocker l'id en session je suppose que tu as vérifié ce fameux mot de passe...
En multipliant les lieux de stockage du mot de passe (en plus non crypté), pour moi cela ne fait qu'augmenter le risque de vol.
Je n'irais pas te dire que cela ralenti le site, je suppose que tu sais ce que tu fais. :wink:
pas seulement ; tu peux aussi le changer via un fichier .htaccess par exemple (http://fr.php.net/manual/fr/configuration.changes.php).Citation:
Envoyé par MacReiben
C'est pourtant bien pour cela.Citation:
le mot de passe ne va certainement pas changer durant la durée de la session
C'est bien la seule raison, je vais pas rétorquer sa ne ménerai pas loin, c'est chacun voit cela comme il le veut et selon ces contraintes, même si dans l'absolu ton raisonnement est plus sécure pour l'utilisateur.Citation:
ePoX : j'ai déjà répondu à ce point il y a quelques jours : un très grand nombre d'utilisateurs utilisent le même mot de passe partout (au boulot, pour le compte en banque, sur le PC perso, sur les sites internet, sur les boites mails, etc).
Par conséquent même si pour toi ça ne change rien (une fois le site "hacké", tu n'es plus à ça pres), pour tes visiteurs ça peut changer beaucoup de choses. Donc par simple respect pour tes utilisateurs, il me semble évident que le mot de passe stocké ne doit pas être décryptable.
la je ne vois pas trop à quoi ou tu veux en venir puisque la session est sauvegardée sur le serveur.Citation:
En multipliant les lieux de stockage du mot de passe (en plus non crypté), pour moi cela ne fait qu'augmenter le risque de vol.
Effectivement... mais je ne pense pas que cela en vaille le coup. Mais c'est un choix.Citation:
Envoyé par ePoX
merci :PCitation:
C'est bien la seule raison, je vais pas rétorquer sa ne ménerai pas loin, c'est chacun voit cela comme il le veut et selon ces contraintes, même si dans l'absolu ton raisonnement est plus sécure pour l'utilisateur.
Typiquement : la base de données est un lieu de stockage relativement "sécurisé" ; mais les sessions, selon l'hebergeur ne le sont pas forcément. En mutualisé elles sont malheureusement souvent accessibles aux autres clients.Citation:
la je ne vois pas trop à quoi ou tu veux en venir puisque la session est sauvegardée sur le serveur.Citation:
En multipliant les lieux de stockage du mot de passe (en plus non crypté), pour moi cela ne fait qu'augmenter le risque de vol.
En cas de faille de sécurité dans un script, il est beaucoup plus facile de faire un "print_r( $_SESSION )" que de se connecter à la base de données, et faire un SELECT dans la bonne table.
En cas de débugage : un "print_r( $_SESSION )" peut avoir été utilisé et oublié pour le débugage dans un script du site... voir même dans un script "externe". Du coup un truc aussi annodin devient un vrai danger.
=> ce n'est pas forcément fréquent, mais pour moi c'est prendre des risques inutilement.
uh ? Comment c'est possible ca ?Citation:
la base de données est un lieu de stockage relativement "sécurisé" ; mais les sessions, selon l'hebergeur ne le sont pas forcément. En mutualisé elles sont malheureusement souvent accessibles aux autres clients.
Par défaut avec PHP installé comme module Apache, tout le monde à accès aux fichiers des autres sites. La directive "open_basedir" est là pour justement empècher ça. Sauf que de trop nombreux "hebergeurs" laissent également les sessions dans le dossier "/tmp/" ; commun à tous les sites.