Est-il sûr de stocker les mots de passe dans les cookies?
la page d'accueil de mon application web a une case à cocher RememberMe . Si l'utilisateur le vérifie, Je stockerai l'e-mail-id et le mot de passe dans les cookies. C'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écurisé pour stocker les mots de passe dans les cookies?
- Quelle est la bonne façon de faire de même?
- quelles sont les meilleures pratiques pour fixer l'heure d'un témoin?
10 réponses
il n'est pas sûr de stocker les mots de passe dans les cookies parce qu'ils sont disponibles en clair.
un bon endroit pour trouver des réponses à propos des cookies est Cookie Central. pour l'adhésion est habituellement utilisé un cookie avec une longue chaîne appelée "token" qui est émis à partir du site Web lorsque vous fournissez votre nom d'utilisateur et mot de passe. Plus sur le processus vous pouvez trouver dans ce article . Lors de l'utilisation des formulaires authentification dans ASP.NET vous pouvez configurer le cookie d'authentification comme ceci:
FormsAuthentication.SetAuthCookie(userName, isPersistanceCookie);
le second paramètre est utilisé pour la fonctionnalité" Remember Me " - si elle est vraie, elle créera des cookies persistants qui dureront après que vous aurez quitté le site. Vous pouvez aussi programmer le cookie comme ceci:
HttpCookie authCookie =
HttpContext.Current.Request.Cookies[FormsAuthentication.FormsCookieName];
Non! Ne stockez pas de mots de passe dans les cookies!
In ASP.NET, utiliser
FormsAuthentication.SetAuthCookie(username, true);
la valeur du second argument détermine si le cookie est persistant (la valeur de la case à cocher "Se souvenir de moi").
non, pas sécurisé à distance. Vous n'avez aucune garantie que les cookies ne sont pas stockés en texte clair (et en fait, la plupart des implémentations do les stockent en texte clair).
rappelez-vous, "souvenez-vous de moi" est intrinsèquement peu sûr, comme n'importe qui interceptant le cookie obtient l'accès à l'application. Mais d'exposer un mot de passe utilisateur prend un peu plus bas dans l'échelle de l'insécurité. :- ) Et rend probablement l'utilisateur vraiment fâché, s'ils le découvrent.
j'utilise une chaîne de cookies cryptée qui intègre le nom de compte de l'utilisateur combiné avec un token qui n'est d'aucune (autre) manière associé au compte de l'utilisateur sauf dans une table sur mon serveur. Lorsque l'utilisateur retourne sur le site, nous déchiffrons le cookie et vérifions si ce token est effectivement associé à ce compte. Le token (et donc le cookie) modifie chaque connexion automatique, et invalide celle utilisée pour cette connexion automatique. (Il y a une relation de plusieurs à un entre les jetons et le compte, pour permettre l'Auto-connexion à partir de plusieurs endroits. Tu peux limiter ça si tu veux.) Tokens time out s'ils ne sont pas utilisés dans les X jours. (Ceci n'est pas seulement fait en limitant la durée du cookie, c'est aussi fait Côté Serveur.) Il y a quelques autres choses que je jette là-dedans pour rendre la vie un bit difficile pour quelqu'un qui essaye de décoder le cookie (l'ayant déchiffré avec succès) ou utiliser un cookie volé (qui ne nécessite pas de déchiffrement), mais il n'y a pas point aller dans overkill (encore une fois, "se souvenir de moi" est par nature précaire).
j'utilise cela sur un site où une sécurité robuste n'est pas vraiment nécessaire (évidemment) et qui a un grand nombre de clients dynamic-IP, et donc je n'essaie pas de le verrouiller sur une IP. Mais même le verrouiller sur une IP ne le rend pas sûr, il réduit juste un peu la surface d'attaque.
Vous demandez peut-être pourquoi j'ai le nom d'utilisateur dans le cookie. Droites pour "se souvenir de moi" , Je ne recommande pas de l'avoir là, même si elle est cryptée (après tout, c'est la moitié de la paire d'authentification dans un système de nom d'utilisateur+mot de passe). J'ai été un peu surpris de le trouver dans notre cookie lorsque j'ai regardé le format en me rappelant comment nous avons fait pour cette question; mais ensuite j'ai vu les commentaires expliquant pourquoi il est là et il ya des raisons sans rapport avec "Se souvenir de moi" (pas nécessairement persuasive raisons, en rétrospective, mais les raisons).
On une dernière remarque, le fait que "remember me" est intrinsèquement peu sûr est l'une des nombreuses raisons pour lesquelles les journaux du site sont très importants, et pourquoi vous devriez exiger la revérification de mot de passe dans le processus de permettre des changements aux informations importantes du compte (pour rendre plus difficile pour quelqu'un ayant volé le cookie de prendre la propriété du compte).
c'est ce que vous ne devriez jamais faire, car il est très facile de changer la valeur d'un cookie et de le renvoyer au serveur. Même le stockage "user is looged in as' naivists '"dans un cookie est erroné, parce que je pourrais alors le changer en"user is logged in as'Pandiya Chendur'".
ce que vous pouvez faire dans les cookies est de donner des informations aux clients qui, même si elles sont modifiées, n'ont pas de sens pour le serveur. Par exemple-couleur préférée, mise en page de la première page et cetera.
vous pouvez leur donner l'ID de session qui est stocké dans un cookie, parce qu'ils ne peuvent rien faire de mieux pour eux-mêmes, s'ils changent la valeur en quelque chose d'autre (à moins qu'ils ne connaissent un ID de session valide d'une autre session).
ce que MSDN de Microsoft dit à propos de l'utilisation des cookies :
les problèmes de sécurité avec les cookies sont similaires à ceux de l'obtention de données de client. Dans votre application, cookies sont une autre forme d'entrée de l'utilisateur et sont donc soumis à l'examen de et l'usurpation d'identité. Un utilisateur peut comme un minimum voir les données que vous stockez dans un cookie, depuis le cookie est disponible sur l'ordinateur de l'utilisateur. Utilisateur peut également changer le cookie avant le le navigateur envoie vers vous.
vous ne devez jamais stocker des données sensibles dans un cookie, comme les noms d'utilisateurs, mots de passe, numéros de carte de crédit, et ainsi sur. Ne mettez rien dans un biscuit qui ne devrait pas être dans les mains d'un de l'utilisateur ou de quelqu'un qui pourrait en quelque sorte voler le cookie.
de Même, méfiez-vous de les informations que vous obtenez d'un cookie. Ne présumez pas que les données sont la comme quand vous l'avez écrit; utilisez le mêmes garanties dans le travail avec les cookies valeurs que vous feriez avec des données que l'utilisateur a tapé dans une page Web. Le des exemples plus haut dans ce sujet montre HTML-encodage du contenu d'un cookie avant d'afficher la valeur dans une page, comme vous le feriez avant d'afficher tout informations que vous obtenez des utilisateurs.
des Cookies sont envoyés entre le navigateur et serveur en texte clair, et toute personne qui peut intercepter votre trafic Web peut lis le cookie. Vous pouvez configurer un cookie propriété qui fait que le cookie est transmis uniquement si la connexion utilise la couche Secure Sockets Layer (SSL). SSL ne protège pas le cookie de être lu ou manipulé alors qu'il est sur l'ordinateur de l'utilisateur, mais il ne 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 Application.
il n'est pas sûr de stocker les mots de passe dans les cookies parce qu'ils sont disponibles en clair. mais si vos critères Préférés est de le faire ou n'importe quelle exigence d'utilisateur est là vous pouvez le faire en cryptant les chaînes. que peut faire ce assez sûr.
mais ce n'est pas recommandé,
je pense que vous devez créer un token avec un nom d'utilisateur et une chaîne d'authentification cryptée que vous obtenez à partir de l'identité de windows. Pas besoin de stocker le mot de passe sur le biscuit. Nous avons notre application qui stocké nom d'utilisateur et chaîne authentifiée
Btw, store mots de passe n'est pas sécurisé partout, à la fois côté client et Côté Serveur.
tu n'as pas besoin de faire ça.
Ce Branislav , a déclaré, et...
en plus de ne pas mettre de données sensibles dans vos cookies, vous devriez également les sécuriser en plaçant au moins les suivants dans votre web.config:
<httpCookies httpOnlyCookies="true" />
pour plus de détails voir: comment configurer exactement httpOnlyCookies dans ASP.NET je ne sais pas.
Il n'est pas du tout sécurisé. Les Cookies sont stockés dans l'ordinateur client, qui peut être altéré.
-
si vous utilisez SSL que vous devriez Si vous transmettez des informations sécurisées, qui élimine un tiers de l'écoute de votre trafic web. Ce serait le même problème indépendamment du stockage des informations d'identification d'un utilisateur dans un cookie parce que quand ils se connectent votre envoi de leur nom d'utilisateur et mot de passe au serveur de toute façon, où je suppose que le serveur le hashé et compare avec le mot de passe que vous avez pour cet utilisateur.
-
D'autres domaines ne seront jamais en mesure de lire votre cookie en raison de l'origine croisée de sorte que ce n'est pas un problème.
-
donc vraiment le seul "trou de sécurité" si vous voulez l'appeler qui est si quelqu'un obtient physiquement accès à leur ordinateur. Si cela se produit, ils vont probablement obtenir n'importe quelle information qui veulent de cette personne de toute façon. Comment expliquer que lorsque chrome auto remplit des formulaires de connexion pour vous, est-ce que c'est sécurisé? Je suis sûr qu'ils sont Je ne le stocke pas en texte clair, mais ça n'a pas d'importance. Si vous allez à une page que chrome auto remplit, vous pouvez simplement copier le mot de passe hors du formulaire et regardez que vous avez maintenant ce mot de passe personnes.
-
il s'agit vraiment de la façon dont" sûr " vous avez besoin qu'il soit. Je suis d'accord que le cryptage d'une information d'utilisateurs avec une expiration comme un jeton est le meilleur moyen d'authentifier les appels de service et il fournit la flexibilité. Je ne vois pas le problème avec stocker les identifiants de connexion dans un cookie.