Les redoutés 'gardez-moi connecté' et vérification de session

Question

Donc, je sais que cela a été fait à la mort, mais toutes les réponses que j'ai rencontré ont été très confus/se contredire les uns les autres ou de leurs explications ont été incomplètes et j'essaie de la garder et de faire ce que mon auto à l'aide de toutes les ressources disponibles, mais je pense que je l'ai perdu quelque part. Je tiens à préciser une fois pour toutes. Je vous remercie pour votre patience à l'avance que ce sera peut-être un peu longue haleine.

J'ai une petite boîte de connexion en haut de ma page qui restera constante si l'utilisateur n'est pas connecté. Si ils sont connectés, alors, au lieu d'une boîte de connexion, ils vont voir un message d'accueil avec leur nom.

Session De Vérification

Alors tout d'abord, voici un schéma de l' (à ma connaissance à ce jour) comment vérifier l'utilisateur peut accéder 'membres' contenu. (ce code va en haut de la page pour vérifier et définir les variables telles que l' $loggedin = true;)

Comme il est, mon $_SESSION['loggedin'] est juste le nom des utilisateurs. C'est ma compréhension que les sessions peuvent être falsifiées ou détournés à partir du même domaine, et je sais que c'est très dangereux (par exemple, un attaquant pourrait en quelque sorte de faire une séance contenant un autre nom d'utilisateurs et voilà - un accès instantané à des utilisateurs de trucs) Mais je ne sais pas comment je devrais vérifier la session. La seule façon que je peux imaginer pour ce faire est de se connecter à la base de données chaque fois qu'une page est chargée et vérifier un hachage MD5 ou quelque chose à partir de la base de données (Et de le renouveler) mais j'imagine que ce serait de générer un grand nombre de inutile de trafic sur le serveur et je suis presque sûr qu'il y a une meilleure manière de le faire.

L'exploitation forestière dans

Voici un schéma de ce qui se passe lorsqu'un utilisateur se connecte (Et l'affichage du message d'accueil ou la boîte de connexion.)

Pour la plupart, je suis assez solide sur cette partie (j'espère), mais je ne sais pas ce que mon hachage MD5 doit contenir afin de pouvoir plus tard re-vérifier le hash avec celui de la base de données, l'un dans le cookie et un nouvellement généré de hachage pour vous assurer un cookie n'a pas été évoqué par un attaquant.. en outre, comme indiqué dans les commentaires ci-dessous, Je vais probablement à la ferraille de l'utilisation de l'adresse IP dans la table de hachage pour permettre aux utilisateurs de rester connectés à partir de plusieurs endroits (par exemple, son téléphone et son ordinateur portable.)

Donc mes questions sont:

• comment dois-je vérifier mes séances ne sont pas de faux?
• comment dois-je vérifier mes cookies ne sont pas de faux?
• mon journal dans la méthode être assez sûr, après la vérification est en place?
• est-il quelque chose d'important, j'ai laissé de côté?

Si il ya quelque chose que vous aimeriez poser, s'il vous plaît laissez-moi savoir dans un commentaire et je serai heureux de le modifier à ma question avec autant d'informations que je peux donner.

Answer 1

Vous ne pouvez pas détourner le contenu d'une session. Si vous êtes l'homme dans le milieu, alors vous pouvez agir en tant que l'utilisateur en utilisant le même ID de session. Ce problème, toutefois, est encore valable pour tout type de session.

Si vous souhaitez empêcher l'homme au milieu attaque, vous devez utiliser le protocole HTTPS.

À l'aide de HTTPS garantit que:

• les sessions ne sont pas faux, car il n'y a pratiquement aucun moyen d'un attaquant peut voler quelqu'un ID de session et de l'utiliser comme leur propre
• vos cookies ne sont pas faux, pour la même raison
• votre journal dans la méthode est sécurisé, car tout ce qui est envoyé et reçu crypté, ce qui serait pratiquement impossible pour un attaquant, soit de voir, de modifier ou d'intercepter les données envoyées et reçues à partir du serveur

Les principaux inconvénients de l'HTTPS, sont:

• vous aurez besoin d'acheter un certificat
• le chiffrement d'ajouter un peu de surcharge, à la fois dans le trafic réseau et l'utilisation des ressources
• les données envoyées via le protocole HTTPS ne sera pas mis en cache

Answer 2

Très joliment illustré question!

La chose à noter à propos de PHP session de soutien, c'est qu'il s'appuie sur les cookies. PHP définit automatiquement un cookie avec un IDENTIFIANT la session PHP ayants droit. Puis, il lit automatiquement le cookie et charges de la session.

Maintenant, les cookies peuvent être détournés (voir Firesheep par exemple) par "man in the middle attaques". L'attaquant simplement des copies d'une autre personne cookies (qui sont transmis avec chaque demande), et les ajoute à son propre navigateur. Et puisque les séances sont identifiés par le biais de cookies, vous pouvez détourner une session de cette façon (l'attaquant sera simplement d'utiliser le site avec la même session en tant qu'utilisateur). Ou vous pouvez détourner l'option "se souvenir de moi" cookie pour une utilisation ultérieure.

La seule vraie garantie contre de tels détournements est d'avoir une connexion cryptée, c'est à dire "https" de connexion. Ensuite, les données du cookie va-et-vient va être codé pour chaque demande, de sorte que quelqu'un d'autre ne pouvez pas copier son contenu réel.

Sinon, vous avez eu la bonne idée de la façon de faire correspondre une persistance de cookie de connexion d'un utilisateur (c'est à dire de hachage dans le cookie doit correspondre à celui de la base de données). Pour la session de vérification, vous n'avez pas besoin de hachage, comme les données de la session elle-même ne quitte jamais le serveur. Donc, il vous suffit de créer $_SESSION['logged_in_user_id'] à l'UID ou false/null, s'ils ne sont pas connectés. C'est, si le témoin check-out, ou le nom d'utilisateur/mot de passe est vérifié, puis définissez l'id de l'utilisateur dans la session comme un simple int.

Comme pour le "manuel" du journal, où l'utilisateur envoie son nom d'utilisateur et le mot de passe, vous êtes de nouveau exposé à l'homme dans le milieu de l'attaque. Comme avant, c'est simplement une question d'intercepter les données qui sont envoyées au serveur. Sauf si vous utilisez une connexion chiffrée, les cookies et le nom d'utilisateur/mot de passe (et tout le reste) seront tous en texte clair, et clairement lisible à un attaquant.

Points mineurs:
Pour l'algorithme de hachage, j'irais avec sha1 plutôt que les anciennes md5. Et pour le nom d'utilisateur/mot de passe dans la base de données, il n'est jamais une bonne idée de stocker le mot de passe en clair dans la base de données. Si votre base de données obtenez violée, les attaquants pourraient viens de lire tout ce qu'il ya quel que soit le degré de sécurité de votre serveur sinon communique avec vos utilisateurs.

Vous le savez probablement déjà tout cela, mais juste au cas où: Pour la table des utilisateurs, de stocker le nom d'utilisateur en texte clair, mais aussi de générer un sel (par exemple, de hachage à l'heure actuelle, plus aléatoire, mais constante! - chaîne de définir, de hachage et de manière répétée plusieurs fois). Stocker le sel dans la base de données, et de l'utiliser lorsque le hachage du mot de passe. Et encore une fois, de hachage à plusieurs reprises de nombreuses fois. Enfin, stocker le mot de passe haché dans la DB. Vous ne serez pas en mesure d'envoyer des gens à leurs mots de passe, parce que tu ne sais pas non plus (vous savez juste la valeur de hachage), mais vous pouvez mettre en œuvre un "réinitialiser le mot de passe", qui génère un nouveau sel, et une chaîne de caractères aléatoires, ce qui permet ensuite de hachage comme n'importe quel autre mot de passe. N'oubliez pas de garder la nouvelle de l'onu-hachage de mot de passe suffisamment longtemps pour envoyer à l'utilisateur. La raison pour laquelle vous voulez de hachage à plusieurs reprises, c'est qu'il fait il fait qu'il est impossible d'utiliser un arc-en-ciel de la table de "renverser" le hachage, même si vous savez que le sel(s). Si vous venez de hachage d'un mot de passe une fois, avec md5 et pas de sel, il serait trivial de regarder le hachage et voir ce que le unhashed mot de passe (à moins que vos utilisateurs sont tous assez intelligent pour utiliser vraiment long, des mots de passe aléatoires qui ne sont pas disponibles dans tous les rainbow tables).

Longue histoire courte: La session, les cookies, et le nom d'utilisateur/mot de passe sont tous vulnérables à la même genre d'attaque. La plupart des pratiques de sauvegarde contre c'est à l'aide de SSL (puisque, comme vous le notez, les adresses IP changent).

Voir également les autres réponses. Plus d'infos le mieux :)

Answer 3

comment dois-je vérifier mes séances ne sont pas de faux?

Par définition d'une variable sur la création.

session_start();
if(empty($_SESSION) || !isset($_SESSION['notfake']){
   $_SESSION = array();
   session_regenerate_id();
   $_SESSION['notfake']=1;
}

comment dois-je vérifier mes cookies ne sont pas de faux?

En les cochant dans la base de données. Connaitre l'identifiant long. Pas beaucoup de choses que vous pouvez faire, outre le blocage des IPs qui ont "trop de" non-valide les cookies dans un court laps de temps.

mon journal dans la méthode être assez sûr, après la vérification est en place?

Dépend, vous ne l'utilisation de HTTPS pour tout? Aussi, définir le cookie de session https uniquement.

est-il quelque chose d'important, j'ai laissé de côté?

Pour les actes importants (changement de mot de passe/email/etc.), demander à l'utilisateur de réapprovisionnement leur mot de passe. Aussi, n'utilisez pas une plaine de hachage, ajouter un peu de chaîne fixe (= sel) pour les valeurs avant de hachage pour éviter l'utilisation directe de rainbow tables.