salut,
je fais appel à vous pour que vous donniez votre avis.
Je programme une application de galerie d'images en ligne (PhpWebGallery pour ceux qui connaissent ) et je revois mon système d'identification. Avant, je fonctionnais par cookie, mais ce n'était pas bien pour plusieurs raisons... donc j'ai voulu abandonner l'utilisation de cookie.
Voici comme je fonctionne maintenant :
1. l'utilisateur se entre son login + mot de passe, je teste si le couple est le même que celui de la base de données (le mot de passe est stocké en md5 dans la base)
2. si le mot de passe est bon, je créé un identifiant de session composé de 4 caractères (paramétrable) avec 62 possibilités pour chaque caractère, donc 62 puissance 4 possibilitées.
3. j'écris dans la table des sessions l'identifiant de session avec l'id de l'utilisateur, la date d'expiration (par défaut à 30 minutes) et l'adresse IP de la personne qui créé la session !
4. sur chaque page je teste si l'identifiant de session est existant, non expiré, correspondant bien à la bonne IP
 
Vous en pensez koi ? C'est une passoire comme système ?

autant stocker dans un cookie le pseudo et le mdp (en md5 éventuellement) et vérifier sur chaque page. là c sûr à 100%
 
ton système peut poser pb en cas de proxy où plusieurs utilisateurs seront derrière la même adresse ip donc en récupérant l'identifiant de session de qqun, on peut se faire passer pour lui.

je ne veux plus passer par cookie, refus absolu !
 
Oui, tu as raison pour ce que tu dis, s'ils sont plusieurs derrière le même proxy et que le second trouve l'id de session assez rapidement, il peut se logguer... en admin si le mec initial est un admin, mais bon, ça reste peu probable, non ?

C'est vrai que j'ai été confronté a ce probleme moi aussi, mais c'est peu probable...je suis resté a un systeme par les IPs.
peut etre pourrait on stocker autre chose avec l'ip qui puisse distinguer différents users derriere un proxy.
Mais je n'aime pas les cookies car souvent les gens les désactivent

moi c'est encore plus que ça... les gens peuvent installer PhpWebGallery sur n'importe kel serveur web, parfois derrière un firewall... et là, t'oublies complètement les cookies... c'est trop lourd les cookies à gérer pour PhpWebGallery.
 
Pour siewn : avant je stockait login+md5(password) dans le cookie.

Pour l'identifiant de session, crée en plutôt un de 32 octets... genre tu fais un md5 sur le retour de la fonction microtime (temps en micro seconde).
 
Et puis pour le coup du mdp en md5 dans un cookie, ce n'est pas plus ou moins sûr qu'un identifiant de session. D'ailleurs mettre le mot de passe en md5 dans le cookie implique que si quelqu'un le récupère, il aura tout son temps pour le cracker dans son coin... un id de session ayant une durée de vie limitée, ça réduit le risque.

ma fonction de création de l'identifiant de session est bien meilleure qu'un simple md5 sur microtime. Pourkoi ?
1. parce que microtime ne renvoie des chaînes ne contenant des caractères à 15 possibilités (contre 62 ! pour la mienne).
2. il suffit au cracker de savoir à quel moment la session a été créée pour trouver l'id de session, ma méthode est basée sur un md5 de microtime + motclef inconnu puis un random pour chaque caractère :

mais y'a un truc que je comprends pas.
pkoi t'utilises pas simplement le sessid crée automatiquement par php ?

je n'utilise pas le systeme standard pour cause d'incompatibilité selon les hébergeurs... mais le système standard utilise des id de session de 32 caractères je crois, contre seulement 4 par défaut pour moi !

tu crée toi même les sessions ?
pas trop la merde d'ajouter le sessid tout le temps sur chaque lien ?

add_session_id_to_url( "./diapo.php?cat=".$sub_row['id']."&expand=".$HTTP_GET_VARS['expand'] )

Mais le fait de ne sortir qu'un id de 4 caractères reste toujours faible... 65^4 reste encore 'faible' mais bon si c'est configurable

Tentacle a écrit a écrit : Mais le fait de ne sortir qu'un id de 4 caractères reste toujours faible... 65^4 reste encore 'faible' mais bon si c'est configurable

oui, je dirais que c vrai pour une application classique, mais pour une appli web, où il faut faire des requêtes sur le serveur, ça fait

 
à trouver en 1800 secondes donc 8209 clefs par secondes pour 4 caracctères (aucun serveur ne peut répondre aussi vite !)
mais c configurable, on peut s'amuser à mettre 10 minutes et une id sur 10 carctères

d'autres avis ?

z0rglub a écrit a écrit : d'autres avis ?

 
non mais une question... l'id est envoyé par méthode POST ou GET ?  
T'as raison de dire que 4 caractères, ça fait un nombre de possibilités assez grand, mais il reste toujours le problème d'une personne qui regarde ce que fait une autre (ça tombe dans la paranoia... mais bon ) et si l'id est transmis en GET, il est alors assez facile de mémoriser 4 caractères.
(je cherche la bêbête je sais, mais c'est bien pour ça que tu as posté ce message ;p

ok, tu as raison de chercher la petite bête, c'est le but du topic. Alors en effet, 4 caractères ou 50, si le "pirate" trouve l'id de session, qui passe en clair dans l'URL, alors, il peut accéder à la session de l'autre, à 2 condition :
1. être rapide, car la session a une durée limitée
2. avoir la même IP
 
Pour le 2eme point, en fait je vérifie juste $REMOTE_ADDR, est-ce que c'est mauvais, est ce que le "pirate" peut simuler $REMOTE_ADDR ? (à condition qu'il connaisse l'IP de la personne qui possède la session en question)

 
Je ne te parle pas tellement d'un pirate... mais genre un collègue de bureau mal intentionné... 4 caractères, c'est hyper facile à retenir (50 c'est tout de même moins facile) et surtout il aura la même IP. voilà  
(de toute façon on peut toujours trouver une faille... aucun système n'est sûr ... )
 
Pour le coup de simuler une IP, oui c'est possible mais il ne récupèrera pas le retour de la requête.

tu me diras, le collègue "pirate" peut toujours se mettre sur le même poste et réutiliser une adresse via l'historique dans le navigateur... par contre, le collègue qui regarde par dessus l'épaule pour voir l'id de session, j'y avais pas pensé, et c vrai que du coup, 4 caractères, c'est pas énorme ! (heureusement que c'est paramétrable !

 
un jour je m'étais imaginé regénérer l'id à chaque requête mais il ne faut pas que le client visite ton site avec plusieurs fenêtre sinon    
 
Pour le coup de réutiliser une adresse via l'historique... si l'utilisateur pense bien à se déloguer de ton site (tu effaces l'id quoi), il n'y a pas de problème.

en fait les utilisateurs ne se deloggues pas... l'id est périmé au bout d'un certain temps (30 minutes par défaut)

 
bah tu pourrais leur proposer une bouton pour se déloguer, ça évitera que quelqu'un utilise l'historique.

y'en a 1, mais je peux pas les forcer à l'utiliser...

non c'est vrai

Bonjour je vais devoir faire un site avec acces utilisateur par mdp. Je suis tombé sur votre topic et ca me concerne pas mal. J'avoue que je me suis pas encore posé le problème et la ya beaucoup d'information d'un coup.
 
Qqun pourrait me faire un resumé des problemes posés par les sessions et qques systemes pour gerer tout ca ?
 
Comme je disais j'ai pas trop réfléchi, mais pkoi pa un cookie qui s'efface a la cloture de la fenetre comme ca on se traine pas un id dans les liens et plus de trace une fois fini ?! Dites moi ce qui pose probleme, j'avoue que je ne vois pas toutes les subtilités, il doit y en avoir

les cookies, c'est chiant parce que :
- tous les surfeurs ne les acceptent pas, alors pour les identifications c moyen !
- tous les serveurs ne les font pas marcher parfaitement, par exemple si le serveur est derrière un firewall...
- de plus, on ne peut pas faire ce que tu suggère, cad supprimer le cookie à la sortie du surfeur...
 
les sessions par identifiants dans l'URL permettent de contrer les pb posés par les cookies, mais dans le même temps, la gestion est un peu plus chiante... et on voit l'identifiant de session dans l'URL.

Pour ce qui est d'effacer un cookie lorsque le navigateur se ferme, j'ai trouvé ça sur un site :
 

 
Sinon pour les methodes de transmission dans l'url, c'est quoi les problemes ? En fait quand l'utilisateur se loggue, il a un id qui est composé a partir de son pseudo et de son pass, mais il suffit de copier cet id (a partir de l'url) pour pouvoir utilisier son compte ou alors il change a chaque session ?

il est valable un temps assez court de préférence, il faut que l'utilisateur s'identifie pour en obtenir un nouveau

question stupide : mais si le gars reste en ligne pdt 30mn et que son id expire au bout de 20mn, le gars doit se re-id alors qu il surfait peinard ?

réponse : oui

mais c trop trop nul !
 
comment ils font les sites "pro" pour etre bien securises et faire beneficier le surfer d'une belle session ? il doit bien y avoir une solution qd meme !

et bien, ils utilisent des cookies... c'est une très bonne méthode qd tu es sûr que ton serveur les fera marcher, mais mon appli doit pouvoir s'installer sur n'importe quel serveur, donc ça pose parfois pb !

oki, sinon pour mon cookie qui est supprimé quand le navigateur est fermé ca marche ? ils doivent bien faire comme ca, paske tant que t sur le site c bon, et si tu fermes le nav, ben tu dois te reloger

j'avoue ne pas savoir comment le navigateur peut informer le serveur qu'il s'est fermé...

je viens de tester chez moi avec un truc vraiment bete :
 
j'ai crée un cookieavec le bout de code que je t donné, et j ai affiché sa valeur.
 
ensuite g fermé la fenetre, g lu le cookie, il  n'existait plus. Donc ca marche. Tu me diras ct obligé tous les sites fonctionnent sur la fermeture du nav.

ben je savais pas, pour moi ct juste une date d'expiration

sinon je suis allé sur ton site, t'utilise les cookies a l heure actuelle et tu veux faire un systeme par url c bien ca ?

 
avec la syntaxe que tu as donnée je confirme que le cookie est effacé une fois la fenetre fermée

oui, c ça, suite à des reports de pb par certains utilisateurs, j'ai décidé de passer à une gestion des identifications sans ccokie

et ta dja vu un site qui tournait que par id dans l url ? maniere de faire comme eux, ils doivent bien avoir un systeme qui evite la peremption de l'id a temps fixe !
 
attend je crois que g un site en tete la je v voir il me semble qu ils mettent tout dans l url

si toute les infos sont dans l'URL, il vaut mieux que la session ne dure pas trop longtemps... sinon, on pourrait voir ton identifiant et se faire passer pour toi