Je souhaite enregistrer les informations d'authentification de l'utilisateur dans le cookie de navigateur pour connaître la connexion persistante. Comme on dit, il n'est jamais sûr de stocker des informations secrètes (telles que mot de passe) dans le cookie, mais pour avoir une option telle que "mémoriser le mot de passe", je pense qu'il n'y a pas d'autre choix.
Donc, si un utilisateur veut se souvenir de ses informations de connexion, et si je stocke le nom d'utilisateur (email) + pas le mot de passe, mais d'autres informations uniques, telles que l'ID DB hachée dans le cookie. Ensuite, je devrais vérifier si l'ID hachée stocké dans des matchs de cookie avec le courrier électronique de l'utilisateur stocké dans Cookie. Comme je pense que quiconque peut très facilement voir les cookies stockés dans le navigateur (par exemple, Firefox, options -> cookies).
Cela serait-il aussi faible que pour que quelqu'un lise le cookie de l'ordinateur où sa sauvegarde, puis sur un autre ordinateur de cookie avec cette information et il serait connecté? (Lorsque le script vérifiera l'email stocké et l'identifiant haché avec la base de données et il correspondra)?
Cette approche pourrait-elle être un peu améliorée sans stocker d'autres informations dans la base de données (telles que la session ID, etc.)? Merci
7 Réponses :
Je suggérerais d'utiliser une clé unique sur le serveur pour chiffrer le nom d'utilisateur (dans ce cas, un courrier électronique) et le stocker dans le cookie d'Auth. Si le cookie est altéré, cela ne sera pas préparé et entraînera une défaillance de la connexion.
Si un cookie d'authentification est copié (en réglant manuellement le cookie ou par XSS) sur un autre ordinateur (ou un autre navigateur), l'utilisateur serait également connecté sur le nouvel ordinateur. Vous pouvez envisager d'ajouter des informations uniques sur l'ordinateur (telles que l'adresse IP) afin de réduire ce risque.
Ceci est une explication sur les cookies authentifiés dans .NET, mais je pense que le concept fonctionne également sur PHP: http://support.microsoft.com/kb/910443
Vous n'avez pas autant de choix quand il s'agit de stocker des informations utilisateur sur le côté du client ...
Vous pouvez essayer de faire un cryptage à l'aide de l'IP du client comme clé. De cette façon, même si le cookie est copié sur l'ordinateur hacker et s'il ne remarque pas que la propriété intellectuelle est la clé du cryptage, vous aurez une protection de la descente des informations de l'utilisateur.
Facebook fait quelque chose de ce moyen, la preuve est chaque fois que vous essayez de vous connecter d'un autre point de connexion que vous devez utiliser le système de vérification de l'utilisateur ...
Cherchez donc un cryptage réversible et cela devrait faire votre journée;)
La sécurité par l'obscurité n'est pas une sécurité du tout.
Il y a un bon article sur la façon de faire des cookies de "souvenir de moi" plus sécurisé: http://jaspan.com/imProved%5Fpersistent%5FLOGIN%5FCOOKIE%5FBEST%5FPRACTICE
J'ai mis en place la méthode décrite dans l'article dans une bibliothèque PHP: https://github.com/gbirke / N'oubliez-vous que , peut-être que vous pouvez l'utiliser comme référence.
La fixation de la session et le vol de cookie est un véritable problème à l'âge de pireSeep . La seule défense contre cela consiste à sécuriser votre site avec SSL et à surveiller les défauts XSS.
Un autre moyen d'améliorer votre sécurité est de vous rappeler que si un utilisateur s'est connecté à un cookie "Se souvenir de moi" et de le forcer à récidiviser lorsqu'il fait quelque chose de "dangereux", comme de commander ou de modifier les informations de connexion.
Pour plus de ressources, voir cette question: Le guide définitif de l'authentification de site Web basée sur la formation
Malheureusement, les améliorations proposées dans le premier article lié n'améliorent rien. Ils ont écrit en réaction à: FISHBOWL.PASTICHE.org/2004/01/19/ ... mais malheureusement, ils ont tort.
Il n'y a pas assez d'espace dans la zone de commentaire pour expliquer en détail. Quelques discussions à ce sujet est inférieure à l'article de la pêche à la pisciculture, ainsi que dans les commentaires à
Vous pouvez également installer un cookie avec un ID utilisateur et une sessionID avec un horodatage expirant. Ensuite, si vous liez le cookie à IP ou nom d'hôte (ou de préférence), vous êtes assez à l'abri des biscuits et d'autres choses.
Je pense qu'il n'y a pas d'autre choix
pense encore.
Vous n'avez pas besoin de stocker le mot de passe Clientside afin de conserver une session. L'opération «STÉMUT ME» est simplement la même - utilisez une valeur aléatoire qui est une clé de recherche sur les données contenues sur votre serveur.
À court d'utilisation de certificats latéraux clients avec des phrases de passe, tout ce que vous faites pour compliquer les choses n'améliorera pas la sécurité et ne sera plus susceptible d'exposer les données privées de votre client.
Il y a une autre option.
Pour chaque utilisateur, lors de la connexion et de la demande à vous rappeler, créez une longue chaîne aléatoire.
Stockez cette chaîne, ainsi que l'ID utilisateur, dans le cookie que vous donnez à l'utilisateur.
Stockez un hachage de chaîne correctement salé dans votre dB.
Si l'utilisateur présente un cookie de mémoire-moi, faites correspondre à la chaîne aléatoire au vérificateur hachée que vous avez dans votre base de données (comme s'il s'agit d'un mot de passe).
Si cela correspond -> enregistrer l'utilisateur dans et créer un nouveau souvenir de souvenir de moi pour eux.
Si vous ne correspondez pas -> Demandez le nom d'utilisateur et le mot de passe.
Et si un pirate informatique copie ce cookie sur son navigateur et essaie de se connecter avant le vrai utilisateur?
J'ai écrit une réponse à la même question dans Comment améliorer mon système de connexion utilisateur - regarde là-bas.
Une approche que vous souhaiterez peut-être envisager consiste simplement à stocker l'ID de l'utilisateur dans le cookie, mais également d'un cookie authentifié non persistant. Un utilisateur avec un cookie ID mais aucun cookie authentifié ne peut parcourir votre système, mais sera invitée à un mot de passe la première fois qu'ils essaient de changer. Si le mot de passe est correct, le cookie authentifié est défini et l'utilisateur ne sera pas demandé à nouveau. Comme le cookie est non persistant, l'authentification ne durera que jusqu'à la fin de la session.
@Gordonm, merci, je pense que Amazon.com a la même approche. Je suis intéressé de savoir que si vous accédez au cookie, disons par courrier électronique + et certaines info hachées, à quel point il vous sera difficile pour vous de définir ces cookies dans votre navigateur?
Je stockais très peu dans les cookies du tout. Le cookie d'identification persistante n'utiliserait que l'identifiant de l'utilisateur en question et le cookie authentifiant non persistant serait vrai ou faux. Essayez d'éviter de stocker plus dans un biscuit que ce n'est absolument nécessaire pour accomplir une tâche, comme si vous envoyez une carte d'identité, tout ce qu'un pirate pirate de Snooping doit continuer, alors que si vous envoyez des informations supplémentaires pouvant donner au piratage plus d'indices sur la manière dont attaquer votre système.