Je me demandais quel est le moyen le plus sûr d'une connexion à cookie? Si vous stockez simplement la passe (crypté avec du sel) et notre nom d'utilisateur dans le cookie et validez-le contre la table utilisateur, un attaquant potentiel peut voler un cookie et sa connexion. Les gens ne vérifient normalement pas là «la dernière fois en ligne».
Y a-t-il un meilleur moyen pour le "souvenir de moi cookie"? IP n'est pas une bonne option, n'est-ce pas? (Certaines machines changent IP tout le temps).
3 Réponses :
façons les plus populaires:
De nombreux scripts utilisent une sorte de suivi de session. Lorsque l'utilisateur visite d'abord le site Web, il génère un identifiant aléatoire unique pour l'utilisateur et les les informations de session Store sur le serveur et l'ID dans le cookie . Le serveur identifie ensuite l'utilisateur à l'aide de l'identifiant unique (appelé Session ID). Les informations associées à l'ID de session ne peuvent être visibles que par le serveur. php utilise ceci par défaut,
Certains stockent les données utilisateur dans le cookie lui-même, mais avec une signature HMAC utilisant une chaîne secrète en tant que clé. Le script rejette le cookie si la signature ne correspond pas. De cette façon, le serveur n'a pas à conserver les données de session sur le serveur . L'utilisateur voit ce qui se trouve dans la session en regardant le cookie, vous ne devez donc pas stocker de données sensibles. Juste l'ID utilisateur (et éventuellement l'heure de connexion et l'expiration de la cookie) devrait suffire. Bien que l'utilisateur puisse voir ce qui est dans l'information de session, la signature dans la cookie veille à ce que l'utilisateur ne puisse modifier lui-même les données de session.
Ces moyens fournissent une certaine sécurité, que l'utilisateur ne puisse pas altérer les données de session, mais cela ne protège pas l'utilisateur de l'oreilledropper. Ils peuvent toujours utiliser un sniffer de paquet et voler une session à partir de tout réseau Wifi ouvert. Certaines applications s'appuient sur l'IP de l'utilisateur, mais peu importe si l'attaquant est dans le même réseau. Certaines applications s'appuient sur l'utilisateur utilisateur, mais il y aura des problèmes lorsque l'utilisateur met à jour leur navigateur ou importer des données d'un autre navigateur.
Si vous êtes vraiment préoccupé par la sécurité, alors Utilisez https .
a également lu Cet article , en particulier la section appelée Comment les opérateurs de sites Web résoudre le problème?
Texte long et pas un seul mot sur la succursale. Et un uppote d'un qui n'a pas lu mais simplement impressionné par la taille du texte.
Le sujet ne concerne pas les cookies de connexion et sa sécurité? C'est ce dont je parle dans la réponse.
C'est totalement sur le sujet et cela m'a donné d'autres idées sur les identifiants de session et les choses HTTPS. J'ai fait avancé.
Je pense avoir trouvé une solution intelligente!
Avantages de ce script (compliqué?):
J'ai fait une table dans la base de données avec les informations suivantes: Le souvenir de moi Cookie aura cette configuration: < Pré> xxx Le script: Avantages du script: référence: http://jaspan.com/improved_persistent_login_cookie_best_practice
session sera une chaîne de 40 (SHA1)
caractères.
jeton sera une chaîne de 32 (MD5)
caractères.
userhash dans le cookie sera un
chaîne de 32 (MD5 de nom d'utilisateur)
caractères.
nom d'utilisateur dans la base de données sera le
Nom d'utilisateur normal.
expire sera maintenant de + 60 jours.
Je ne vois pas de seins dans cette solution. Quel est le but du champ de session dans ce tableau? Pourquoi une table dédiée du tout? Pourquoi ne pas stocker qu'un hash est-il fait de données de certains utilisateurs?
Toute autre solution vous permettra de disposer de plusieurs sessions, sans table supplémentaire, sans trop compliquer votre script
Cela limite le temps de l'attaquant pouvant utiliser votre compte.
Avez-vous même lu le Col de script? Tu punies déjà moi = s
Cela ressemble beaucoup à cette technique: Jaspan.com/imProved_Persistent_Login_cookie_Best_Praxtice
C'est ce que j'ai utilisé en effet =) mais la chose que Thay n'ajoutait pas, c'est que l'utilisateur a besoin de revoir (et du code réel). La faille de son script est qu'un attaquant qui attend jusqu'à ce que la victime ait une nouvelle jeton, peut détruire toute sa session en essayant d'authentifier avec le vieux jeton.
J'aime la détection de détournement de la session implicite intégrée à ce schéma de validation. Cependant, le détournement de la session ne sera en fait détecté que si une personne utilisait la fonctionnalité de souvenir de moi. J'aimerais l'avoir facultatif, mais je pense que je vais toujours utiliser une détection similaire à ce que vous avez proposé ici.
Donc, vous allez créer un cookie sans demander la permission?
Une telle fonctionnalité "Nott Me" est toujours un risque de sécurité supplémentaire.
Parce que comme dans une session, vous n'avez qu'un identifiant qui suffit à non seulement identifier un utilisateur ( qui est-ce? ) mais aussi pour authentifier cet utilisateur ( est-ce vraiment lui / elle? ) Sans faire une authentification réelle.
Mais à l'opposé d'une session qui a (ou devrait avoir) juste une durée de vie courte (surtout moins d'une heure) et que l'identifiant est (ou devrait être) modifié périodiquement (en fonction de la nécessité et de la nécessité due à l'authenticité / autorité Changements d'état), un identifiant "Se souvenir de moi" est valable pour des jours, sinon même pendant des mois ou des années! Et cette longue période de validité pose un risque de sécurité supplémentaire.
Donc avant de demander comment mettre en œuvre une fonctionnalité de "souvenir de moi", vous devez vous demander si vous voulez vraiment un risque de sécurité supplémentaire. Cela dépend principalement des actifs que votre candidature a et que l'authentification a l'authentification et si vous souhaitez prendre le risque d'impersonnations / vols d'identité que la fonction "mémoriser moi" pose.
Si tel est le cas, assurez-vous de fournir une sécurité de base à l'aide de HTTPS et définissez le drapeau httponly et le Secure Drapeau dans vos cookies . Ensuite, vous pouvez faire ce qui suit pour construire une fonctionnalité de "souvenir de moi":
demande d'authentification toute autre demande
Avec cela, l'authentification est sécurisée via HTTPS, à la fois l'authentification initiale et l'authentification "Souvenez-vous de moi". Et l'utilisateur n'est authentique que pendant la session en cours; Si elle expire, l'utilisateur doit authentifier soit à l'aide de la Souvenez-vous de moi jeton ou en fournissant ses informations d'identification de connexion. Et comme les se souviennent de moi les jetons sont stockés dans la base de données, l'utilisateur peut invalider tout se souvenir de moi jeton.
Si l'utilisateur authentifié via https et définit l'option "mémoriser moi", génère un jeton aléatoire me souvenir de moi , stockez-le sur le côté serveur dans une base de données "Souvenez-vous de moi" et définissez le N'oubliez pas Moi Cookie avec le drapeau sécurisé avec cette valeur. Ensuite, commencez une nouvelle session et définissez un Souvenez-vous de moi drapeau.
«Si vous voulez vraiment que le risque de sécurité supplémentaire, je puisse limiter l'utilisateur authentifié par le cookie afin d'éviter tout dommage. Consultez mon script ci-dessous, vous n'obtiendrez jamais un jeton aléatoire chanceux car si les jetons sont identiques, l'utilisateur doit être identique deux. Je tiens à me souvenir de moi plus permanent, mais simplement à la fixation de la session expirer à une valeur supérieure.
C'est une réponse, mais (pour moi) pas la réponse.
S'il vous plaît dites-nous quelque chose à propos de votre application qui utiliserait cette fonctionnalité. Quel serait l'impact potentiel d'un vol d'impersonnation / d'identité?
La plupart des machines changent IP tout le temps ...
La fonctionnalité "SENSED ME" est insécurité par définition. Donc, c'est à vous de choisir entre la convivialité et la paranoïaie.
Ce n'est pas un cas de colonie, je peux limiter les options de l'utilisateur lors de la connexion via un cookie (il doit revalider lorsqu'il voulait modifier les détails, etc.) et je peux limiter la fenêtre d'un attaquant.
La fonctionnalité "Se souvenir de moi" est pas insécurité, techniquement. Il peut être sûr d'être sûr car l'utilisateur partage son appareil avec d'autres personnes ou parce qu'ils risquent de perdre leur appareil. Vous devez réutiliser un cadre d'authentification existant chaque fois que possible, car, vraiment complexe. Par exemple, jetez un coup d'oeil à github.com/delight-im/php-auth