User authentification / session timeout?

  • Auteur de la discussion Auteur de la discussion Recif
  • Date de début Date de début
WRInaute impliqué
Bonjour,

J'aimerai m'affranchir des cookies pour l'authentification utilisateur, je suis en train d'étudier les solution avec les sessions (php). Comment faites vous pour maintenir un login utilisateur actif après que l'utilisateur ait fermé son navigateur? ^Je ne souhaiterai pas que l'utilisateur se reconnecte à chaque fois qu'il réouvre son navigateur...
Merci
 
WRInaute accro
Ce n'est pas possible. Concrètement, les "sessions" sont des cookies.
Leur durée de vie est simplement limitée à la session du navigateur.

Pour conserver l'utilisateur enregistré, il faut forcément utiliser les cookies (ou le local storage, mais le problème reste le même).
 
WRInaute impliqué
Ok, donc je suis obligé de stocker le mot de passe dans le cookie... Je croyais que c'était absolument à éviter. :(
 
WRInaute accro
Non tu n'es pas obligé de stocker le mot de passe dans le cookie, loin de la.
Il te faut stocker un paramètre qui te permettra de reconnaitre l'utilisateur à partir de son cookie. Cela ne doit pas être le mot de passe.

L'idée est de crypter une chaine de caractères et de la mettre dans le cookie.

Code:
string_to_encrypt = "#{user.username}#{user.password}#{user.private_key}"
cookie = ::BCrypt::Password.create(string_to_encrypt)
Le code ci-dessus est du ruby. Cherche un peu si tu as besoin d'avoir cela dans un autre langage

Ici, j'ai mis le username, le mot de passe et une "clé privée". Cette clé privée est une valeur unique générée aléatoirement par toi pour chaque utilisateur.
Ainsi, même en connaissant le nom d'utilisateur et le mot de passe, on ne peut pas obtenir de token correct.

Par la suite, pour identifier ton utilisateur, tu génère la chaine cryptée avec les valeurs que tu as dans ta base de données, et si les deux sont similaires, tu as le bon utilisateur.
A côté de cela, personne ne peut mettre de fausse chaine.

Une solution pas mal serait de mettre l'adresse ip de l'utilisateur dans le token. Ainsi, si quelqu'un obtient la valeur du cookie, il est inutilisable sur une autre connexion.
 
WRInaute accro
Tu n'enregistres pas le mot de passe, juste un hash avec un salt au choix.

Edit: grillé.
 
WRInaute impliqué
dmathieu a dit:
Non tu n'es pas obligé de stocker le mot de passe dans le cookie, loin de la.
Il te faut stocker un paramètre qui te permettra de reconnaitre l'utilisateur à partir de son cookie. Cela ne doit pas être le mot de passe.

L'idée est de crypter une chaine de caractères et de la mettre dans le cookie.

Code:
string_to_encrypt = "#{user.username}#{user.password}#{user.private_key}"
cookie = ::BCrypt::Password.create(string_to_encrypt)
Le code ci-dessus est du ruby. Cherche un peu si tu as besoin d'avoir cela dans un autre langage

Ici, j'ai mis le username, le mot de passe et une "clé privée". Cette clé privée est une valeur unique générée aléatoirement par toi pour chaque utilisateur.
Ainsi, même en connaissant le nom d'utilisateur et le mot de passe, on ne peut pas obtenir de token correct.

Par la suite, pour identifier ton utilisateur, tu génère la chaine cryptée avec les valeurs que tu as dans ta base de données, et si les deux sont similaires, tu as le bon utilisateur.
A côté de cela, personne ne peut mettre de fausse chaine.

Une solution pas mal serait de mettre l'adresse ip de l'utilisateur dans le token. Ainsi, si quelqu'un obtient la valeur du cookie, il est inutilisable sur une autre connexion.

Ok, en fait c'est un peu comme mettre un second mot de passe quoi... Actuellement j'ai généré un mot de passe à partir d'une classe d'encryption basée sur 2 clés. Ca peut également coller alors? Car même en récupérant la chaine encryptée du mot de passe dans le cookie, personne ne pourra rien en faire normalement...
 
WRInaute accro
Personne ne pourra obtenir le mot de passe en effet. Par contre, la personne pourra réinjecter cette chaine dans un cookie.
D'ou ma suggestion de mettre l'adresse ip de l'utilisateur dans ton salt. Cela réduit les risques.
 
WRInaute impliqué
Ah oui, en effet... Par contre je ne comprends pas bien, si l'ip de l'utilisateur légitime change il ne pourra plus non plus se connecter? Je ne saisi pas trop le fonctionnement...
 
WRInaute accro
Si l'ip de l'utilisateur change, il devra se reconnecter avec son nom d'utilisateur et son mot de passe en effet.
Cependant, aujourd'hui en France, tous les FAI fournissent des IP qui restent les mêmes pour un client donné.
L'adresse IP de l'utilisateur changera donc très rarement.
 
WRInaute impliqué
Donc si je résume: je récupère via le formulaire de login son nom d'utilisateur, son mot de passe et son ip. je valide l'association user/mot de passe et je fais un hash que j'intègre dans les infos utilisateur dans ma bdd. Je fais mon cookie avec tout ça. A chaque page où je veux contrôler si c'est bien l’utilisateur légitime, je récupère les infos du cookie et je contrôle user/mot de passe/hash dans l'enregistrement utilisateur. C'est bien ça?
 
WRInaute impliqué
Oui oui, bien sûr. Mais ok pour le principe. Sinon une idée pour réduire les requêtes bdd à chaque controle?...
 
WRInaute discret
Je ne suis pas sûr que l'IP soit fixe pour tous les visiteurs en France. J'ai entre 1% (le plus souvent) et 10% (aujourd'hui par exemple) d'utilisateurs qui changent d'IP d'une requête à l'autre (souvent des mobiles ou des utilisateurs de mairie, lycée, grosses entreprises...).
 
WRInaute impliqué
Dan_A a dit:
Je ne suis pas sûr que l'IP soit fixe pour tous les visiteurs en France. J'ai entre 1% (le plus souvent) et 10% (aujourd'hui par exemple) d'utilisateurs qui changent d'IP d'une requête à l'autre (souvent des mobiles ou des utilisateurs de mairie, lycée, grosses entreprises...).

Oui, mais ce que disais dmathieu c'est que l'ip attribuée reste attribuée un bon moment avant de changer.
Sinon pour info j'ai mis en place le système de login/cookie etc. et tout fonctionne à merveille!
 
Discussions similaires
Haut