J'utilise 2 variables dans Cookie (expiration de 7 jours) qui est l'ID utilisateur et le hachage. Le hachage est un encode SHA1 de l'agent utilisateur et de l'ID utilisateur. Dans ce cas, certains pirates informatiques peuvent se connecter à savoir le navigateur de cookie volé. De quelle manière dois-je suivre ou quelle pratique est la meilleure pour me souvenir des problèmes de sécurité?
5 Réponses :
Personnellement, je crée un hasch aléatoire et stockez-le dans une table "Souvenez-vous de moi". Le tableau a également l'agent utilisateur, l'ID utilisateur et l'adresse IP. Je vérifie tous les deux chaque fois que je me connecte à l'utilisateur de la fonction mémorisée. Et si l'utilisateur se déconnecte manuellement, je supprimai simplement cette ligne de la table. Ensuite, s'ils se connectent à nouveau, il crée un nouveau hash aléatoire. Il n'y a vraiment aucun moyen de lutter contre quelqu'un reniflant des paquets avec un système de souvenir de moi (sauf si vous utilisez des cookies sécurisés avec le jeu de drapeau HTTPS uniquement). Utilisez donc une connexion sécurisée avec des cookies HTTPS uniquement. Si vous ne pouvez pas, au moins, faites au moins le hasch aléatoire, donc s'il est découvert, vous pouvez au moins générer un nouveau hachage à tuer ce login ...
N'était-ce pas moi, mais je me méfie toujours de la mise en œuvre comme celle-ci, car elle suppose que des variables telles que l'agent utilisateur et la propriété intellectuelle sont des constantes quand elles ne le sont souvent pas. Je ne définirais pas cela comme une solution mais plus d'une solution de contournement
Assez juste. Mais en l'absence d'un cookie HTTPS uniquement, existe-t-il de meilleurs moyens de tenter de vérifier la source?
Je n'ai pas vu ou entendu parler d'un encore malheureusement, je pense que si vous voulez un souvenir de moi, il devrait être que d'accéder à des domaines peu importants en tant que mal utilisée, souvenez-vous que ME Fonction a une myraid de préoccupations de sécurité telles que les ordinateurs partagés, etc. Sur le téléphone tellement appologiste pour la grammaire.
Vous pouvez éventuellement utiliser des sessions pour stocker l'état de l'utilisateur. Mais holding session si longtemps cause un même problème, lorsque l'ID de session sera volé. Vous pouvez rejoindre les informations sur les cookies avec un autre navigateur ou une adresse IP, mais cela entraînerait un problème, lorsque l'utilisateur n'a pas d'adresse IP statique.
Quoi qu'il en soit, Holding Un ID de session est plus sûr que je ne fais que mettre le mot de passe SHA1 SHA1 de l'utilisateur aux cookies.
Heureusement, l'OP n'a pas parlé de mot de passe du tout :) Mais oui, une pièce d'identité de session pourrait être utile ici.
Les longues sessions de course sont presque toujours une mauvaise idée. Ils ouvrent la porte à des attaques spécifiques à DOS, car vous pouvez manger une quantité non insignifiante d'espace de stockage depuis que PHP ne peut pas gc des sessions tant que le timelimit n'est pas atteint. Il y a quelques cas où il est nécessaire, mais pour la plupart, ce n'est pas une bonne idée ...
hmac
Je fais habituellement cela ainsi, alors je n'ai rien à stocker sur le côté serveur sur les bases de données ou similaire.
Vous devez générer une chaîne aléatoire qui devient votre "clé secrète" et que Vous devez stocker du côté serveur (probablement dans un script de config Php comme une constante) et vous n'avez jamais à dire à personne. Je vais appeler cette clé secrète Alors votre cookie doit définir deux valeurs: Donc, votre cookie final pourrait être: Alors, quand vous devez vérifier si un cookie est un cookie de souvenir de moi doit le faire: Le point est que vous pouvez générer un hasch qui transmet ce chèque car le hachage a besoin non seulement du Comme indiqué dans les commentaires que vous pouvez le faire en utilisant la fonction secrète_key .
user_id : ID utilisateur de l'utilisateur qui obtiendra la connexion automatique
hachage : un hachage cryptographique sécurisé de user_id et secret_key . Donc, par exemple, MD5 (user_id. "-". Secret_key) . (Quelque chose de différent que MD5, tel que SHA1 ou SHA256, est préféré).
user_id: hachage . user_id mais Aussi le secrets_key hash_hmac dans php> = 5.1.2: http://us.php.net/manual/fr/function.hash-hmac.php
Dommage que la déséroferience ne fonctionne pas encore dans PHP (elle est mise en œuvre dans le coffre uniquement). Donc, vous pouvez plutôt faire la liste ($ valeur, $ hash) = exploser (':', $ cookie_value, 2); . Et cela peut être meilleur pour la sécurité si vous implémentez un "secret" différent pour chaque utilisateur (depuis lors, un compromis unique d'un secret n'ouvre pas la porte pour chaque utilisateur). OH, et PHP a un HASH_HMAC fonction pour faire cette chose même ...
@ircaxell, +1 pour votre commentaire (je commence à oublier ces choses ... Je n'écris plus php :)). J'intègre tes conseils. Je ne suis pas d'accord avec l'idée de créer différents secrets pour chaque utilisateur. Bien qu'il soit évident plus sûr, l'avantage est minimal à mon avis dans ce cas.
Pendant que vous pouvez hacher un utilisateur_id et secret_key, quiconque intercepte ce cookie peut se connecter à votre application. En plus de cela, vous pouvez le faire pour que votre souvenir de moi des cookies soit escaladé très rapidement. Personne n'aime bien un biscuit mortel.
Vous pouvez stocker l'horodatage de la dernière visite de chaque utilisateur dans votre base de données et dans le cookie. Chaque fois que vous lisez le cookie pour vous connecter à l'utilisateur, vous vérifiez que les deux horodataires correspondent. S'ils ne le font pas, nient l'utilisateur. S'ils le font, mettez à jour les horodatages.
Utilisation de cette méthode, à tout moment, votre utilisateur revient sur votre site, tous les vieux cookies vont faire obstacle. Un pirate informatique qui a intercepté un cookie a maintenant un biscuit mort sans valeur, car il ne connaît pas l'horodatage exact dans le cookie actuel. Bien sûr, le pirate informatique peut utiliser un cookie frais autant qu'il souhaite jusqu'à ce que l'utilisateur se connecte à. Cette méthode offre une petite quantité de sécurité et devrait certainement être utilisé le long des méthodes latérales proposées dans d'autres réponses. Une clé hachée doit être stockée dans le cookie. Un souvenir de Me Me Cookie ne peut pas être parfaitement sécurisé, une nouvelle inscription de mot de passe doit être nécessaire pour tout accès supplémentaire à des données de données ou d'applications hautement sensibles. Je vous recommande également de nommer votre cookie quelque chose à plus de "Remember_Me" pour le faire un peu plus difficile à trouver. Bien qu'il n'ajoute pas beaucoup de sécurité, le cas échéant, nommer votre cookie 'HT33424' prend juste aussi longtemps que de nommer le "souvenir_me" ou "hack_me".
Désolé mais je ne pense pas que j'aime cette réponse, à moins que je comprenne mal la logique, cela s'appuie sur l'utilisateur charger une nouvelle page avant que le pirate informatique ait le temps de copier et d'exécuter la page de leur côté. À la fin d'une session d'utilisateurs authentique, il y a une grande fenêtre pour le détournement et même pendant une session, il ne devrait pas être trop difficile de glisser entre les charges de la page. Cela créerait un comportement inhabituel de page pour l'utilisateur authentique. Renommer des noms de variables Cookie est la sécurité par l'obscurité et une perte de temps. (A continué)
... C'est probablement une autre couche qui aidera, mais un pirate informé déterminé ne sera pas dissuadé par celui-ci. En outre, ce n'est pas 100% de faibles sur les raisons que j'ai mentionnées ci-dessus. Pour l'accès sensible et potentiellement dommageable à des informations sensibles et à des fonctionnalités, je ne recommanderais pas cette méthode sous forme de solution 100% sécurisée, seule une amélioration marginale.
À un pirate informatique déterminé, aucune méthode n'est 100% sécurisée. Comme vous l'avez dit, il s'agit vraiment d'une couche de plus pour essayer de nous rapprocher de 100%. Ceci est censé être utilisé avec d'autres méthodes, dont beaucoup sont fournis dans d'autres réponses. Une clé hachée doit certainement être stockée dans la cookie et la rentrée de mot de passe doit être nécessaire pour un accès supplémentaire aux informations et aux fonctionnalités sensibles.
Sans cette méthode, un pirate informatique pourrait toujours glisser entre les charges de la page, créer un comportement inhabituel de page pour l'utilisateur authentique. Cette méthode oblige un pirate informatique à réinsertionner un cookie chaque fois que l'utilisateur véritable se connecte. Puisque cela peut ne pas être un problème pour un pirate informatique déterminé, cette méthode ajoute uniquement un petit niveau de sécurité à d'autres méthodes discutées ici.
Vous pouvez simuler la date d'expiration de la date d'expiration de plus d'une année sur le cookie, mais ensuite avoir un champ de mot de passe Entrée dans toutes les zones sensibles, un peu comme l'implémentation d'Amazon utilise. Un cookie détourné permettra d'accéder à l'accès, mais d'acheter ou de modifier quelque chose de personnel exige que le mot de passe soit ré-entré.
Le problème avec les tables "souvenir de moi" est que si un pirate informatique peut accéder à cette table, il peut créer et se connecter à autant de comptes qu'il le souhaite. Vous pouvez soutenir que cela renforce la sécurité d'une fonctionnalité de souvenir de moi, mais elle doit être pesée avec les risques de ramollissement des zones de sécurité des genoux.
Connexes: Stackoverflow.com/search?q=php+Session+Hijacking
Vous devez réutiliser un cadre d'authentification existant chaque fois que possible, car, vraiment complexe. Par exemple, jetez un coup d'œil à github.com/delight-im/php-auth