Est-il sûr de stocker les mots de passe dans les cookies?

https://stackoverflow.com/questions/2100356

21-09-2019
|

Question

Ma page d'application Web à la maison a un RememberMe case à cocher. Si l'utilisateur vérifie, je willl magasins email-id et mot de passe dans les cookies. Ceci est mon code:

if (this.ChkRememberme != null && this.ChkRememberme.Checked == true)
   {
     HttpCookie cookie = new HttpCookie(TxtUserName.Text, TxtPassword.Text);
     cookie.Expires.AddYears(1);
     Response.Cookies.Add(cookie);
   }

Ce que je veux savoir est:

Est-il sûr de stocker les mots de passe dans les cookies?
Quelle est bonne façon de faire la même chose?
Quelles sont les meilleures pratiques en matière de mise à l'heure pour un cookie?

La solution

Il est sûr de ne pas stocker les mots de passe dans les cookies car ils sont disponibles en texte brut.

Un bon endroit pour trouver des réponses sur les cookies est Pour l'adhésion est habituellement utilisé un cookie avec une longue chaîne appelé « jeton » qui est émis à partir du site Web lorsque vous fournissez votre nom d'utilisateur et mot de passe. En savoir plus sur le processus que vous pouvez trouver dans cette article . Lorsque vous utilisez l'authentification des formulaires dans ASP.NET, vous pouvez définir le cookie d'authentification comme ceci:

FormsAuthentication.SetAuthCookie(userName, isPersistanceCookie);

Le second paramètre est utilisé pour la fonctionnalité « Remember Me » - si cela est vrai, il va créer des cookies persistants qui va durer après avoir quitté le site. Vous pouvez également manipuler programatically le cookie comme ceci:

HttpCookie authCookie =
  HttpContext.Current.Request.Cookies[FormsAuthentication.FormsCookieName];

Autres conseils

Non! Ne pas stocker les mots de passe dans les cookies!

Dans ASP.NET, utilisez

FormsAuthentication.SetAuthCookie(username, true);

La valeur du deuxième argument détermine si le cookie est persistant (la me rappeler la valeur de case à cocher).

Non, pas à distance sûr. Vous avez aucune garantie que les cookies ne sont pas stockés dans le texte brut (et en fait, la plupart des implémentations faire les stocker sous forme de texte).

Rappelez-vous, « souvenez de moi » est intrinsèquement précaire, comme tout le monde l'interception du cookie obtient l'accès à l'application. Mais exposer le mot de passe d'un utilisateur prend un pas de plus vers le bas de l'échelle de l'insécurité. :-) Et fait sans doute l'utilisateur vraiment fou, s'ils trouvent.

J'utilise une chaîne de cookie crypté qui intègre le nom du compte de l'utilisateur associé à un jeton qui est en aucun (autre) façon associée au compte de l'utilisateur, sauf dans une table sur mon serveur. Lorsque l'utilisateur retourne sur le site, nous décryptons le cookie et rechercher si ce jeton est en fait associé à ce compte. Le jeton (et donc cookies) change tous les auto-connexion, et entraîne l'extinction de celui utilisé pour cette connexion automatique. (Il y a beaucoup à une relation entre les jetons et le compte, pour permettre la connexion automatique à partir de plusieurs endroits. Vous pouvez limiter que si vous le souhaitez.) Pions temps si elles ne sont pas utilisés dans les X jours. (Ceci est non seulement fait en limitant la durée du cookie, il est fait côté serveur ainsi.) Il y a quelques autres choses que je jette là-dedans pour rendre la vie bits difficile pour quelqu'un qui essaie de décoder le cookie (ayant déchiffré avec succès) ou bien utilisez un cookie volé (qui ne nécessite pas le déchiffrement), mais il ne sert à rien d'aller surpuissant (encore une fois, « se souvenir de moi » est intrinsèquement non sécurisé).

Je l'utilise que sur un site où la sécurité robuste n'est pas vraiment nécessaire (évidemment) et qui a un grand nombre de clients IP dynamiques, et donc je ne pas essayer de le verrouiller à une adresse IP. Mais même le blocage jusqu'à une adresse IP ne permet pas sécurisé, il réduit juste la surface d'attaque un peu.

Vous demandez peut-être pourquoi j'ai le nom d'utilisateur dans le cookie. Pour droites « me rappeler » le but, je ne recommanderais pas l'avoir là, même si elle est cryptée (après tout, il est la moitié de la paire d'authentification dans un système de nom d'utilisateur + mot de passe). J'étais un peu surpris de trouver dans notre cookie lorsque je regardais le format quand me rappeler comment nous avons fait pour cette question; mais j'ai vu les commentaires expliquant pourquoi il est là et il y a des raisons sans rapport avec « remember me » (pas nécessairement persuasif raisons, avec le recul, mais des raisons).

Sur une note finale, le fait que « remember me » est en soi l'insécurité est l'une des nombreuses raisons pour lesquelles les journaux du site sont très importants, et pourquoi vous devriez exiger un mot de passe revérification dans le processus de permettre des modifications aux informations importantes sur votre compte (pour faire il est plus difficile pour quelqu'un qui a volé le cookie de prendre possession du compte).

est ce que vous ne devriez jamais faire, car il est très facile de changer la valeur d'un cookie et renvoyer au serveur. Même le stockage « utilisateur est looged en tant que « naivists » » dans un cookie est faux, parce que je pourrais alors changer pour « l'utilisateur est connecté en tant que« Pandiya Chendur ».

Qu'est-ce que vous pouvez faire dans les cookies est de donner des informations aux clients que, même si changé, n'a pas de sens au serveur. Par exemple - couleur préférée, la première mise en page et ainsi de suite.

Vous pouvez leur donner l'ID de session qui est stockée dans un cookie, parce qu'ils ne peuvent pas faire quelque chose de mieux pour eux-mêmes, si elles changent la valeur à autre chose (à moins qu'ils ne connaissent un ID de session valide d'une autre session).

Qu'est-ce que MSDN Microsoft dit sur l'utilisation des cookies :

Les problèmes de sécurité avec les cookies sont   semblables à ceux d'obtenir des données de   le client. Dans votre application,   les cookies sont une autre forme d'entrée de l'utilisateur   et sont donc soumis à l'examen   et l'usurpation d'identité. Un utilisateur peut au minimum   voir les données que vous stockez dans un   biscuit, puisque le cookie est disponible   sur l'ordinateur de l'utilisateur. L'utilisateur   peut également modifier le cookie avant la   navigateur envoie à.

Vous ne devriez jamais stocker des données sensibles   dans un cookie, tels que les noms d'utilisateur,   les mots de passe, numéros de carte de crédit, etc.   sur. Ne mettez rien dans un cookie   cela ne devrait pas être dans les mains d'un   utilisateur ou d'une personne qui pourrait en quelque sorte   voler le cookie.

De même, méfiez-vous des   informations que vous obtenez un cookie.   Ne présumez pas que les données sont les   même que lorsque vous l'avez écrit sur; Utilisez le   mêmes garanties dans le travail avec cookies   valeurs que vous le feriez avec des données qu'un   l'utilisateur a tapé dans une page Web. le   exemples précédemment dans cette rubrique ont montré   HTML codant pour le contenu d'un cookie   avant d'afficher la valeur dans une page,   comme vous le feriez avant d'afficher une   informations que vous obtenez des utilisateurs.

Les cookies sont envoyés entre le navigateur et   serveur en texte brut, et tous ceux qui   peut intercepter votre trafic Web peut   lire le cookie. Vous pouvez définir un cookie   propriété qui cause le cookie être   transmis uniquement si la connexion   utilise le Secure Sockets Layer (SSL).   SSL ne protège pas le cookie de   être lu ou manipulé pendant qu'il est   sur l'ordinateur de l'utilisateur, mais il   empêcher le cookie d'être lu   en transit parce que le cookie est   crypté. Pour plus d'informations, voir   Pratiques de sécurité de base pour le Web   Applications.

Il est sûr de ne pas stocker les mots de passe dans les cookies car ils sont disponibles en texte brut. mais si votre critère préféré est de le faire ou toute exigence utilisateur est là, vous pouvez le faire en chiffrant les chaînes. qui peut faire ce assez sûr.

mais il est pas recommandé,

Je pense que vous devez créer un jeton avec nom d'utilisateur et une chaîne d'authentification cryptée que vous obtenez des fenêtres d'identité. Pas besoin de stocker le mot de passe sur cookie. Nous avons notre application qui stocke le nom d'utilisateur et chaîne authentifiée

BTW, les mots de passe magasin est pas sécurisé partout, à la fois client et côté serveur.

Vous n'êtes pas obligé de le faire.

Qu'est-ce que Branislav dit, et ...

En plus de ne pas mettre des données sensibles dans vos cookies, vous devez également les fixer en plaçant au moins les éléments suivants dans votre web.config:

<httpCookies httpOnlyCookies="true" />

Pour plus de détails: Comment configurer exactement vous httpOnlyCookies dans ASP.NET?

Il est pas du tout sûr. Les cookies sont stockés dans l'ordinateur client, qui peut être trafiqué.

Si vous utilisez SSL que vous devriez si vous transmettre toute information sécurisée, qui élimine un tiers d'écouter votre trafic web. Ce serait la même question quel que soit le stockage d'une des informations d'identification des utilisateurs dans un cookie parce que lorsqu'ils se connectent votre envoi leur nom d'utilisateur et mot de passe au serveur de toute façon, où je suppose que le serveur hash et il compare contre le mot de passe haché que vous avez pour cet utilisateur.
D'autres domaines ne seront jamais en mesure de lire votre cookie à cause de croix d'origine de sorte que n'est pas un problème.
Alors, vraiment le seul « trou de sécurité » si vous voulez l'appeler qui est si quelqu'un gagne physiquement l'accès à leur ordinateur. Si cela se produit, ils sont le plus susceptible d'obtenir toute information qui veulent de cette personne de toute façon. Comment expliquez-vous quand auto chrome remplit les formulaires de connexion pour vous, est-ce sûr? Je suis sûr qu'ils ne stockent pas dans le texte brut mais qui n'a même pas d'importance. Si vous allez à une page qui chrome auto vous pouvez remplir simplement copier le mot de passe de la forme et regardez ce que vous avez maintenant ce mot de passe de personnes.
Il est vraiment à la façon dont « sécuriser » vous avez besoin d'être. Je suis d'accord que le cryptage des informations d'utilisateurs avec une expiration comme jeton est la meilleure façon d'authentifier les appels de service et il offre une flexibilité. Je ne vois pas le problème avec le stockage des informations de connexion dans un cookie.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow