Quelle est la meilleure façon d'implémenter «se souvenir de moi» pour un site Web? [fermé]

510

Je souhaite que mon site Web comporte une case à cocher sur laquelle les utilisateurs peuvent cliquer afin de ne pas avoir à se connecter à chaque fois qu'ils visitent mon site Web. Je sais que je devrai stocker un cookie sur leur ordinateur pour l'implémenter, mais que devrait contenir ce cookie?

De plus, y a-t-il des erreurs courantes à éviter pour empêcher ce cookie de présenter une vulnérabilité de sécurité, qui pourrait être évitée tout en offrant la fonctionnalité «se souvenir de moi»?

security cookies remember-me

— Vort3x
source

5

Vérifiez stackoverflow.com/questions/549/… (partie II de la première réponse)

— Frosty Z

si vous utilisez ASP.NET, consultez codeproject.com/Articles/779844/Remember-Me

— Believe2014

1

Il y a des informations très utiles dans Security SE ~ security.stackexchange.com/questions/19676/…

— b1nary.atr0phy

La réponse actuellement acceptée par splattne est trop complexe. Créez un jeton +16 octets à partir d'une source aléatoire, hachez-le et enregistrez l'ID de hachage + compte dans la base de données. Envoyez ensuite le jeton à l'utilisateur (encodé en base64) dans un cookie HTTPS + httpOnly (afin que Javascript ne puisse pas y accéder / le voler). De cette façon, personne ne peut deviner le jeton ou se déconnecter avec des suppositions invalides, mais même si votre base de données est piratée, personne ne peut utiliser les jetons dans la base de données (ils sont hachés). Ainsi, seul le client d'origine (ou quelqu'un qui vole le jeton dans la boutique du navigateur) peut l'utiliser.

— Xeoncross

536

Meilleure pratique de cookie de connexion persistante améliorée

Vous pouvez utiliser cette stratégie décrite ici comme meilleure pratique (2006) ou une stratégie mise à jour décrite ici (2015):

Lorsque l'utilisateur se connecte avec succès avec l'option Remember Me cochée, un cookie de connexion est émis en plus du cookie de gestion de session standard.
Le cookie de connexion contient un identifiant de série et un jeton . La série et le jeton sont des nombres aléatoires non devinables provenant d'un espace suffisamment grand. Les deux sont stockés ensemble dans une table de base de données, le jeton est haché (sha256 est très bien).
Lorsqu'un utilisateur non connecté visite le site et présente un cookie de connexion, l'identifiant de la série est recherché dans la base de données .
1. Si l' identifiant de série est présent et que le hachage du jeton correspond au hachage de cet identifiant de série, l'utilisateur est considéré comme authentifié . Un nouveau jeton est généré, un nouveau hachage pour le jeton est stocké sur l'ancien enregistrement et un nouveau cookie de connexion est émis pour l'utilisateur (il est correct de réutiliser l' identifiant de série ).
2. Si la série est présente mais que le jeton ne correspond pas, un vol est supposé. L'utilisateur reçoit un avertissement fortement formulé et toutes les sessions mémorisées de l'utilisateur sont supprimées.
3. Si le nom d'utilisateur et la série ne sont pas présents, le cookie de connexion est ignoré .

Cette approche offre une défense en profondeur. Si quelqu'un parvient à divulguer la table de base de données, cela ne donne pas à un attaquant une porte ouverte pour usurper l'identité d'utilisateurs.

— splattne
source

20

voir aussi: stackoverflow.com/questions/549/… vous ne devriez PAS lire la version 'améliorée'

— Jacco

8

Le problème avec cela est que vous exposez le nom d'utilisateur dans le cookie, bien que c'est ce que fait Gmail. Pourquoi avez-vous besoin à la fois d'un ID de série et d'un jeton? Un plus gros jeton ne conviendrait-il pas?

— Dan Rosenstark

10

De plus, concernant ce modèle, qu'est-ce que pour empêcher un attaquant de voler et de placer le cookie sur son ordinateur et de supprimer le cookie de l'ordinateur piraté. Son ordinateur serait alors authentifié et mis à jour au besoin sans que l'ordinateur piraté ne le sache jamais? Le seul changement serait que l'utilisateur des ordinateurs piratés devrait se reconnecter et se souvenir de moi. Que l'utilisateur piraté le reconnaisse ou non serait incertain.

24

@HiroProtagonist L'identifiant de série est destiné à empêcher une attaque DoS. Sans cela, je pourrais rapidement écrire un script frappant votre site avec chaque nom d'utilisateur et un jeton invalide, déconnectant tout le monde sur votre site.

— Chris Moschini

6

Cette solution est erronée, elle ne gère pas la monnaie simultanée: si deux demandes d'authentification Remember-me arrivent en même temps, avec le même cookie Remember-me, la première réussit et modifie le jeton, la seconde provoque une authentification peu réussie, et une fausse alarme (car le jeton a déjà été modifié lors de la première demande). (Cette situation peut se produire lorsque le navigateur démarre et que le site est restauré dans deux onglets de navigateur.)

— slobo

9

Je voudrais stocker un ID utilisateur et un jeton. Lorsque l'utilisateur revient sur le site, comparez ces deux informations à quelque chose de persistant comme une entrée de base de données.

En ce qui concerne la sécurité, ne mettez rien là-dedans qui permettra à quelqu'un de modifier le cookie pour obtenir des avantages supplémentaires. Par exemple, ne stockez pas leurs groupes d'utilisateurs ou leur mot de passe. Tout ce qui peut être modifié pour contourner votre sécurité ne doit pas être stocké dans le cookie.

— dragonmantank
source

8

Stockez leur UserId et un RememberMeToken. Lorsqu'ils se connectent avec l'option Se souvenir de moi cochée, générez un nouveau RememberMeToken (qui invalide toutes les autres machines qui sont marquées se souviennent de moi).

Quand ils reviennent, recherchez-les par le jeton Remember me et assurez-vous que UserId correspond.

— jonnii
source

Cela peut être forcé brutalement en quelques secondes. Je vais juste mettre mon user_id à 1 et forcer brutalement tous les jetons. Cela me donnera accès en quelques secondes

— Un ami

4

En enquêtant moi-même sur les sessions persistantes, j'ai constaté que cela ne valait tout simplement pas le risque pour la sécurité. Utilisez-le si vous en avez absolument besoin, mais vous devriez considérer une telle session comme faiblement authentifiée et forcer une nouvelle connexion pour tout ce qui pourrait être utile à un attaquant.

La raison en est bien sûr que vos cookies contenant votre session persistante sont si facilement volés.

4 façons de voler vos cookies (d'après un commentaire de Jens Roland sur la page @splattnebasée sur sa réponse):

En l'interceptant sur une ligne non sécurisée (reniflage de paquets / détournement de session)
En accédant directement au navigateur de l'utilisateur (via un malware ou un accès physique à la box)
En le lisant dans la base de données du serveur (probablement SQL Injection, mais pourrait être n'importe quoi)
Par un hack XSS (ou un exploit similaire côté client)

— Jarl
source

104

1. HTTPS est conçu pour empêcher cela. 2. Restez connecté n'est pas le problème de sécurité ici, vous avez de plus gros problèmes. 3. Identique à 2. 4. Cela peut être évité par une politique de contrôle d'accès et un bon assainissement des intrants; si vous ne suivez pas ces étapes, vous rencontrez à nouveau des problèmes plus importants que Rester connecté.

— Chris Moschini