User authentification / session timeout?

[Recif]

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

 

[dmathieu]

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).

 

[spout]

+1, cookie de session ou ?PHPSESSID (berk)

 

[Recif]

Ok, donc je suis obligé de stocker le mot de passe dans le cookie... Je croyais que c'était absolument à éviter.

 

[dmathieu]

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.

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.

 

[spout]

Tu n'enregistres pas le mot de passe, juste un hash avec un salt au choix.

Edit: grillé.

 

[Recif]

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.

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...

 

[dmathieu]

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.

 

[Recif]

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...

 

[dmathieu]

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.

 

[Recif]

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?

 

[dmathieu]

Oui. Sauf que l'IP, tu ne la transmet pas dans le formulaire. Tu la récupère juste côté serveur.

 

[Recif]

Oui oui, bien sûr. Mais ok pour le principe. Sinon une idée pour réduire les requêtes bdd à chaque controle?...

 

[dmathieu]

Tu ne peut pas épargner la requête à ta base de données utilisateurs à chaque chargement de page.

 

[Recif]

ok!
Merci pour ton aide en tout cas.

 

[Dan_A]

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...).

 

[spout]

Un article qui date et déjà partagé ici mais toujours très intéressant: http://shiflett.org/articles/the-truth-about-sessions

 

[Recif]

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!