Rester connecté… ou comment garder une session active en sécurité

De nombreux sites proposent une option rester connecté ou  se souvenir de moi lors de l’identification des utilisateurs. Lorsque cette case est cochée, l’internaute n’a plus besoin de s’identifier sur le site pendant plusieurs jours, ce qui est bien pratique et qui explique que de plus en plus de sites proposent cette option (1 minute de perdue c’est autant de visiteurs en moins) pour simplifier la navigation.

Exemple de formulaire de connexion

Sur de nombreux forums la question de savoir comment reprendre une session après la fermeture du navigateur est posée et dans la grande majorité des cas la réponse est lapidaire : utilise un cookie. Ok sur le fond, mais sur la forme ? Le plus simple à partir de là (et la solution qu’on croise de temps en temps) est de stocker l’identifiant de l’utilisateur dans un cookie valable 30 jours et de reconnecter cet utilisateur automatiquement quand on trouve le cookie. Oui ça marche, mais non, ne le faites pas !

separateur

Le cookie est un simple fichier texte

Sans entrer dans les détails, le cookie n’est qu’un simple fichier texte écrit dans un répertoire prédéterminé par le navigateur. Ce fichier n’est pas crypté et peut être créé de toutes parts à l’aide de n’importe quel éditeur de texte par n’importe quelle personne plus ou moins bien intentionnée.

A partir de là, puis-je faire confiance à mon cookie ? Non, mais je n’ai pas le choix alors je considère mon cookie comme n’importe quelle entrée fournie par l’internaute (malicieuse par défaut) et je me comporte avec les données du cookie comme je le ferais avec les données d’un formulaire.

Pour la connexion de vos utilisateurs, vous ne vous contentez pas de leur demander leur login, vous ne pouvez donc pas utiliser uniquement cette information pour recréer la session de votre internaute.

separateur

Stocker le mot de passe ?

La fausse bonne idée bien entendu est de stocker le mot de passe de votre utilisateur. Si vous le stockez en clair, vous donnez la possibilité à n’importe qui ayant accès au système de fichier de l’ordinateur d’obtenir le mot de passe en question (ordinateur partagé, cybercafé…).

Vous pouvez aussi choisir de stocker un hash correspondant à ce mot de passe (md5, sha256…) mais il suffira de recopier le cookie pour pouvoir se connecter à volonté sans jamais connaître le mot de passe.

separateur

Utiliser une base de données pour  contrôler la cohérence du cookie

Vous ne pouvez pas utiliser de données « constantes » puisque trop faciles à reproduire, il va donc falloir ruser un peu et créer des données qui n’auront une utilité que dans le contexte que vous voudrez leur donner : stockez une date, une chaîne de caractères aléatoire, l’âge du capitaine… de manière générale on appellera ceci un jeton (token)

Créez donc un token plus ou moins complexe : les possibilités sont infines, vous pouvez utiliser :

  • l’identifiant de l’internaute ;
  • le user agent du navigateur utilisé ;
  • l’url de la dernière page visitée ;
  • la date et l’heure de la dernière visite ;
  • une phrase spécifique (clé secrète) au serveur ;

le tout mélangé et hashé avec art, par exemple

hash('sha256', $user_id . time() . $_SERVER['HTTP_USER_AGENT'] )

Vous noterez que la ligne ci-dessus a 2 défauts majeurs : le user_id est fixe et le user agent est plus que facilement falsifiable. Peu importe, l’heure au milieu sert de « grain de sable » qui fait que le token en question changera à chaque seconde et le user agent seul ne servira à rien à une personne mal intentionnée.

Le token est créé, stockez le dans un cookie avec une date d’expiration différente de celle du cookie et propre à la session : 01/02/2013 à 12:00 vous créez une session valable 10 jours donc jusqu’au 11/02/2013 à 12:00. Cette session va être gérée par un cookie qui expirera lui aussi das 10 jours à la première page visitée, mais à la minute d’après, le cookie expirera le 11/02/2013 à 12:01 alors que la date d’expiration de la session n’aura pas changé.

Il ne vous reste plus qu’à enregistrer les informations utiles en base de données : l’identifiant utilisateur, la date de la dernière visite, la chaîne user agent et la date d’expiration de la session.

A la prochaine visite de votre internaute, le cookie vous indiquera l’identifiant utilisateur et la date d’expiration de la session, le navigateur vous donnera son user agent et votre base de données pourra vous dire à quelle heure s’est faite la dernière connexion. Vous pourrez ainsi générer à nouveau un hash et le comparer avec celui du cookie.

separateur

Est-ce que cette méthode est vraiment sûre ?

A chaque fois qu’on utilise un algorithme de hashage,  il existe un risque de collision, c’est à dire que deux données différentes peuvent produire le même résultat mais ce risque est, disons, faible. Et puisque vous maîtrisez 100% des données à partir desquelles le hash est généré, il sera impossible à un attaquant de générer des milliards de résultats pour tenter de créer une collision.

Il est donc sûr de recréer une session à partir de ces données d’identification puisque vous contrôlez toutes les données lues et qu’il sera impossible à un attaquant de deviner de quelle façon vous générez votre hash.

separateur

Cet article touche à sa fin, il est donc temps pour moi de vous rappeler que vous pouvez utiliser les données que vous voulez pour créer votre hash mais que vous devez vous assurer qu’il change en fonction de son contexte pour ne pas être reproductible et que vous devez vous souvenir que les informations fournies par un cookie peuvent être falsifiées par n’importe qui.

Si vous avez aimé cet article, vous aimerez peut-être



Source : Algorithme SHA256 sur wikipédia

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *