Authentification, session, Gestion des comptes utilisateurs

sgaze · 19 Août 2004

Bonjour,

Pour mettre en place un accès restreint par comptes à une partie de mon site, j'aimerais créer en PHP une gestion des utilisateurs enregistrés avec en vrac les fonctionnalités suivantes :

- authentification par nom et pass stockés en base,
- support des sessions
- administration par l'utilisateur des informations propre à son compte

Vous avez des grandes directions techniques à me conseiller ?

puis-je utiliser les sessions de PHP en me passant de sessionID dans les urls et de cookies ?

Merci d'avance.

Samuel

totoro · 19 Août 2004

Salut,
Je te conseille d'utiliser des cookies, c'est aussi simple à utiliser que des session, et ca évite les apparitions en URL justement.

tu fais un fichier login.php (par exemple) avec ton formulaire d'entrée
tu fais une validation de ce formulaire dans la même page (histoire de pas faire 15.000 fichiers). Si les données sont validées, tu rediriges vers la page sécurisée.

Dans toutes les pages "sécurisées" tu fais un test de présence de ton cookies avec check des valeurs, si c'est pas bon, au revoir, et retour en premiere page.

Vala, j'espere que j'ai été clair, si c'est pas le cas, n'hésite pas à répondre.
Bonne chance.

sgaze · 19 Août 2004

Oui c'est clair, merci !

Quand tu parles de cookie, c'est en mémoire sur le serveur le temps de la session ou sur le poste client à plus long terme ?

Oubah · 19 Août 2004

personne n'a de problemes avec les cookies et ie 6 ?
Je suis obligé d'utiliser les sessions de mon côté car impossible de récupérer le cookie :/

Oubah · 19 Août 2004

samgaz a dit:
Oui c'est clair, merci !

Quand tu parles de cookie, c'est en mémoire sur le serveur le temps de la session ou sur le poste client à plus long terme ?

Les cookies sont stockés chez le client le temps que tu veux, contrairement aux sessions qui sont stockées sur le serveur et sont automatiquement détruits dans un laps de temps déterminé.

sgaze · 19 Août 2004

Oubah a dit:
personne n'a de problemes avec les cookies et ie 6 ?

IE6 et son célèbre onglet confidentialité a une gestion variable des cookies.

As tu testé si à certains niveaux du réglage de confidentialité tu n'arrives plus à récupérer les infos ?

Oncle Tom · 20 Août 2004

En PHP, l'utilisation du setcookie() est assez particulière et faut remplir au maximum les paramètres pour que les cookies soient créés sans encombre sur la majorité des navigateurs.

De mon côté, j'utilise un système de session EXTERIEUR à celui des sessions PHP (en utilisant une table MySQL de sessions) car j'ai intégré mon forum à mon site. C'est à peine plus lourd mais t'es tranquille dans la mesure où tu n'es pas obligé de pourrir tes URL.
C'est assez technique à faire par contre.

Se baser que sur les cookies, c'est un choix (que j'aurais pu faire) mais tant qu'à le faire, autant essayer au départ de le faire bien et pour un maximum de personnes.

Oubah · 20 Août 2004

De mon côté, j'ai justement testé à plusieurs niveaux de sécurité pour les cookies mais en vain.
Pour ce qui est d'envoyer les cookies, je n'ai aucun problème c'est simplement pour les récupérer.
Mais j'ai entendu dire que les sessions PHP pouvaient parfois poser problème aussi ?

Bool · 20 Août 2004

The Jedi a dit:
En PHP, l'utilisation du setcookie() est assez particulière et faut remplir au maximum les paramètres pour que les cookies soient créés sans encombre sur la majorité des navigateurs.

Je ne pense pas que ce soit une contrainte de PHP, mais plutot d'IE 6 et son filtre assez restrictif sur les cookies. Non ?

The Jedi a dit:
De mon côté, j'utilise un système de session EXTERIEUR à celui des sessions PHP (en utilisant une table MySQL de sessions) car j'ai intégré mon forum à mon site. C'est à peine plus lourd mais t'es tranquille dans la mesure où tu n'es pas obligé de pourrir tes URL.
C'est assez technique à faire par contre.

Se baser que sur les cookies, c'est un choix (que j'aurais pu faire) mais tant qu'à le faire, autant essayer au départ de le faire bien et pour un maximum de personnes.

euh.... En utilisant MySQL, tu ne fais que changer la méthode de stockage des sessions. Ca ne change absolument rien sur la méthode de transmission de l'ID de session.

Tu peux bien évidement aussi modifier cette méthode de transmission, mais cela n'a rien à voir avec le fait de stocker en base de données.

sgaze · 20 Août 2004

J'envisage le fonctionnement suivant pour authentifier et maintenir la session de l'utilisateur :

L'utilisateur s'authentifie avec son couple (login, pass) par un formulaire
Une fois posté, je vérifie que son compte existe en base et que le mot de passe correspond à ce compte.

Je stocke alors son login dans une variable de session $_session. Je vérifie dans toutes les pages "sécurisées" que la variable de session n'est pas vide et qu'elle correspond à un compte existant en base.

Voyez vous des inconvénients ou des failles de sécurité ?

Bool · 20 Août 2004

C'est la méthode que beaucoup de sites / scripts utilisent. Cette méthode est aussi est aussi "sûre" que les sessions elles mêmes... donc pas fiable à 100%, mais largement suffisant dans la plupart des cas.

PS : par contre, si ce n'est pas le cas, je te conseille très fortement de crypter tes mots de passe en base

sgaze · 20 Août 2004

Bool a dit:
PS : par contre, si ce n'est pas le cas, je te conseille très fortement de crypter tes mots de passe en base

Tu as raison, ne serait-ce que par respect du visiteur.

Quel mécanisme de cryptage-décryptage tu me conseilles ?

Bool · 20 Août 2004

J'ai longtemps fait la bétise d'utiliser la fonction md5() de PHP pour ça... mais depuis peu j'ai changé pour crypt(), comme indiqué dans l'excellent ouvrage "PHP 5 Avancé".

D'ailleurs, avec crypt() j'utilise également le chiffrage md5(), mais avec le salt en plus.

Oubah · 20 Août 2004

Bool a dit:
J'ai longtemps fait la bétise d'utiliser la fonction md5() de PHP pour ça... mais depuis peu j'ai changé pour crypt(), comme indiqué dans l'excellent ouvrage "PHP 5 Avancé".

D'ailleurs, avec crypt() j'utilise également le chiffrage md5(), mais avec le salt en plus.

Elle a de quoi de particulier la fonction md5 ?

Bobez · 20 Août 2004

Oui, quel est le problème, car perso j'utilise md5() pour crypter mes pass (tout comme phpBB si je me souviens bien)...

Bool · 20 Août 2004

Elle ne resiste pas à une attaque par dictionnaire : il existe des listes de mots de passe les plus connus, pour chacun de mots de passe, un md5 précalculé est fourni. Ainsi si quelqu'un accède à votre base de données, il pourra très rapidement faire la correspondance "md5 => mot de passe". Tandis qu'avec crypt(), comme un "grain de sel" est inséré dans l'algorythme, il est impossible de prédire le résultat, et il lui faudra donc recalculer tout son dictionnaire, pour chacun des mots de passe qu'il voudra retrouver.

Bobez · 20 Août 2004

Donc si je comprend bien, en utilisant cette méthode, on va en quelque sorte utiliser à chaque fois un cryptage différent pour chaque mot de passe ? Dans ce cas, comment va-t-on faire pour vérifier après-coup la correspondance entre le mot de passe tapé par l'utilisateur et le mot de passe crypté ?

Oncle Tom · 20 Août 2004

D'après ce que j'ai compris, en utilisant le même algorithme (mais qui peut être différent selon l'utilisateur).
Par contre, à partir du moment où tu connais le "grain de sel", la fonction crypt() n'offre rien de plus par rapport à md5() non ?

Bool · 20 Août 2004

The Jedi a dit:
D'après ce que j'ai compris, en utilisant le même algorithme (mais qui peut être différent selon l'utilisateur).

En fait le grain de sel est indiqué au début du mot de passe généré. donc si tu fais un crypt('mot de passe', '$1$toto') tu auras en résultat quelque chose du genre "$1$toto$kdshqjklzhkdshfjksdh".

Ainsi, pour tester un mot de passe, tu ferais comme ça :

Code:

if( crypt( $mot_de_passe_fourni , $mot_de_passe_crypte ) === $mot_de_passe_crypte ) {
    // mot de passe valide

The Jedi a dit:
Par contre, à partir du moment où tu connais le "grain de sel", la fonction crypt() n'offre rien de plus par rapport à md5() non ?

si si : cela veut dire qu'il faudrait que le gars reconstruise tout son (énorme) dictionnaire, avec CE grain de sel.
Et sachant que chaque utilisateur aura un grain de sel différent, il faudra qu'il recommence cette opération systématiquement.

Et crypt a d'autres avantages : si vous decidé un jour de changer d'algo car l'actuel ne vous semble pas assez sûr, vous n'avez qu'à changer votre fonction générant le grain de sel (le format dépend du grain de sel), et automatiquement à chaque fois qu'un utilisateur changera de mot de passe, ce sera le nouveau cryptage qui sera pris en compte.

Sans compter le fait que toutes (ou presque) les applications sous Unix utilisent cette méthode.... donc coté interfaçage avec d'autres outils, c'est tout bénéf.

Oncle Tom · 20 Août 2004

Intéressant en effet mais bon, je suis contraint et forcé de conserver le md5 à cause de mes forums

Merci pour ces infos en tous cas.

Bool · 20 Août 2004

The Jedi a dit:
Intéressant en effet mais bon, je suis contraint et forcé de conserver le md5 à cause de mes forums
Merci pour ces infos en tous cas.

De rien, remerci Ganf pour avoir pris le temps de m'expliquer tout ça

Bobez · 21 Août 2004

Oui intéressant, je serais tenté de passer à ce système ! Mais comment vais-je faire pour changer le cryptage des pass existants ? Y-a-t-il un moyen de décrypter md5() ? J'avais entendu des choses à ce sujet comme quoi c'était possible...

Bool · 21 Août 2004

C'est un hashage, et c'est indécryptable ; ce qui est un des gros avantages de ce genre de "cryptage".

milkiway · 22 Août 2004

PS : par contre, si ce n'est pas le cas, je te conseille très fortement de crypter tes mots de passe en base

Ce n'est pas un conseil mais une obligation. Le md5() est ton ami, voire le sha() si tu fais une concaténation mot de passe + login (au moins 12 caractères)

Sinon utilise les sessions c'est très facile et passes le sess_id en URL

Bool · 22 Août 2004

milkiway a dit:
Ce n'est pas un conseil mais une obligation. Le md5() est ton ami, voire le sha() si tu fais une concaténation mot de passe + login (au moins 12 caractères)

toi, tu n'as pas lu les 10 posts d'après

milkiway a dit:
Sinon utilise les sessions c'est très facile et passes le sess_id en URL

euh... en URL... pouah c'est moche, chiant pour le référencement, et pas sécurisé (si tu vas sur un autre site, l'ID de session sera quand visible dans le REFERER et donc le webmaster de ce site pourra se faire passer pour toi sur le précédent site...)

Oubah · 22 Août 2004

Bool a dit:
euh... en URL... pouah c'est moche, chiant pour le référencement, et pas sécurisé (si tu vas sur un autre site, l'ID de session sera quand visible dans le REFERER et donc le webmaster de ce site pourra se faire passer pour toi sur le précédent site...)

Pour protéger l'accès à certaines pages, le référencement n'a plus besoin d'être optimisé.
De toute façon, les sessions peuvent être transmises sans l'identifiant dans l'URL, sauf si le visiteur a tout désactivé dans son navigateur mais bon.

milkiway · 22 Août 2004

Bool : exact je n'avais vu qu'une page désolé

mais preuve que ça ne te pénalise pas de le passer en url : http://www.en1heure.com/itseasy/0admin_ ... 68689d48bd

Bool · 23 Août 2004

Oubah a dit:
Pour protéger l'accès à certaines pages, le référencement n'a plus besoin d'être optimisé.

Les sessions, ce n'est pas forcément sur les pages "protégées". Si tu fais un session_start() dès que l'utilisateur, peu importe la page, le systeme "tran_sid" risque de te saloper les liens.

De toute façon, les sessions peuvent être transmises sans l'identifiant dans l'URL, sauf si le visiteur a tout désactivé dans son navigateur mais bon.

Vous vous êtes passés le mot pour lire un mot sur deux ?

Oui l'ID peut très bien être passé sans ça, mais là je répondait justement à la phrase "Sinon utilise les sessions c'est très facile et passes le sess_id en URL".

milkiway a dit:
Bool : exact je n'avais vu qu'une page désolé

pas grave, ça arrive à tout le monde

milkiway a dit:
mais preuve que ça ne te pénalise pas de le passer en url : http://www.en1heure.com/itseasy/0admin_ ... 68689d48bd

C'est un autre débat

Perso je trouve ça moche, suivant le nombre de parametre total de ton url ça peut coincer niveau référencement, et coté sécurité ce n'est pas brillant du tout.

totoro · 23 Août 2004

Juste pour revenir sur le md5/crypt, rien n'empêche de faire "soi-même" une salt avec md5 : il suffit d'encoder le mot de pass avec qqch d'autre genre le login *2, la date en seconde, etc. de mélanger un peu tout ça à sa propre sauce pour éviter les dicos et autre.

milkiway · 23 Août 2004

Bool : moche mais comme dit plus haut ce sont des pages admin donc non référencées. Et je te met au défi de rentrer dans mon admin alors même que tu as mon sid

totoro · 23 Août 2004

mmm... ca sent le défi

Bool · 23 Août 2004

totoro a dit:
Juste pour revenir sur le md5/crypt, rien n'empêche de faire "soi-même" une salt avec md5 : il suffit d'encoder le mot de pass avec qqch d'autre genre le login *2, la date en seconde, etc. de mélanger un peu tout ça à sa propre sauce pour éviter les dicos et autre.

Evidement que tu peux toujours faire autrement, mais pourquoi ré-inventer la roue ? De plus, tu perds la compatibilité avec les autres applis, et l'évolutivité/souplesse fournie par crypt.

milkiway a dit:
Bool : moche mais comme dit plus haut ce sont des pages admin donc non référencées. Et je te met au défi de rentrer dans mon admin alors même que tu as mon sid

Comme dit plus haut, les sessions il n'y a pas que pour les pages admins qu'elles sont utilisées (beaucoup de gestionnaires de pub les utilisent pour gèrer le capping par exemple).
Sinon pour TON admin, je suppose que tu fais des tests également de ton coté (genre IP), mais bien que cela soit une petite sécurité supplémentaire, ce n'est pas fiable à 100% (cas d'un admin passant par un proxy par exemple, ou carrément IP spoofing). Et surtout, ce genre de test est loin de faire l'unanimité (certains utilisateurs changent d'IP à chaque "hit").

cyruss · 12 Septembre 2004

Vol de session

milkiway a dit:
Bool : moche mais comme dit plus haut ce sont des pages admin donc non référencées. Et je te met au défi de rentrer dans mon admin alors même que tu as mon sid

Si tu veux gagner le pari bool il te faudra utiliser la technique dite du vol de session mais qui est difficile à mettre en place.
Toutes les infos sur cette technique et sur la manière de s'en proteger sont sur :
[url=http://www.eyrolles.com/Info...w.eyrolles.com/Informatique/Li ... avance.php[/url]

On les trouve aussi sur le net bien sur

++

cyruss

jdelprat2000 · 19 Octobre 2005

que pensez-vous des methodes SQL AES_encrypt et AES_DECRYPT ?

Merci d'avance,

Julien