Est-il sûr de stocker des mots de passe dans des cookies?
La page d'accueil de mon application Web comporte une case à cocher RememberMe. Si l'utilisateur le vérifie, je stocke l'identifiant e-mail et le mot de passe dans les cookies. Voici 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 c'est:
- Est-il sûr de stocker des mots de passe dans des cookies?
- Quelle est la bonne façon de faire de même?
- Quelles sont les meilleures pratiques pour définir l'heure d'un cookie?
Ce n'est PAS sûr de 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 Cookie Central. Pour l'adhésion est généralement 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 votre mot de passe. Plus d'informations sur le processus que vous pouvez trouver dans ce article . Lorsque vous utilisez l'authentification par formulaire dans ASP.NET, vous pouvez définir le cookie d'authentification comme ceci:
FormsAuthentication.SetAuthCookie(userName, isPersistanceCookie);
Le deuxième paramètre est utilisé pour la fonctionnalité "Se souvenir de moi" - s'il est vrai, il créera des cookies persistants qui dureront après que vous ayez quitté le site. Vous pouvez également manipuler par programme le cookie comme ceci:
HttpCookie authCookie =
HttpContext.Current.Request.Cookies[FormsAuthentication.FormsCookieName];
Non! Ne stockez pas de 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 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 brut (et en fait, la plupart des implémentations do les stockent en texte brut).
Attention, "souvenez-vous de moi" est intrinsèquement peu sûr, car toute personne interceptant le cookie a accès à l'application. Mais exposer le mot de passe d'un utilisateur va un peu plus loin dans l'échelle d'insécurité. :-) Et rend probablement l'utilisateur vraiment fou, s'il le découvre.
J'utilise une chaîne de cookies cryptée qui incorpore le nom de compte de l'utilisateur combiné à un jeton qui n'est en aucune manière (autre) associé au compte de l'utilisateur, sauf dans un tableau sur mon serveur. Lorsque l'utilisateur revient sur le site, nous déchiffrons le cookie et recherchons si ce jeton est effectivement associé à ce compte. Le jeton (et donc le cookie) modifie chaque connexion automatique et invalide celui utilisé pour cette connexion automatique. (Il existe une relation plusieurs à un entre les jetons et le compte, pour permettre la connexion automatique à partir de plusieurs emplacements. Vous pouvez limiter cela si vous le souhaitez.) Les jetons expirent s'ils ne sont pas utilisés dans les X jours. (Cela ne se fait pas seulement en limitant la durée du cookie; cela se fait également côté serveur.) Il y a quelques autres choses que j'y ajoute pour rendre la vie un peu difficile pour quelqu'un qui essaie de décoder le cookie (après l'avoir décrypté avec succès) ou d'utiliser un cookie volé (qui ne nécessite pas de décryptage), mais il ne sert à rien de surpasser (encore une fois, "souvenez-vous de moi" est intrinsèquement peu sûr).
Je l'utilise sur un site où une sécurité robuste n'est pas vraiment nécessaire (évidemment) et qui a un grand nombre de clients IP dynamiques, et donc je n'essaie pas de le verrouiller sur une IP. Mais même le verrouiller sur une adresse IP ne le rend pas sécurisé, il réduit juste un peu la surface d'attaque.
Vous vous demandez peut-être pourquoi j'ai le nom d'utilisateur dans le cookie. À des fins directes de "souvenir de moi", je ne recommanderais pas de l'avoir là, même s'il est chiffré (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 l'avons fait pour cette question; mais ensuite j'ai vu les commentaires expliquant pourquoi il est là et il y a des raisons sans rapport avec "se souvenir de moi" (pas nécessairement des raisons persuasives , avec du recul, mais des raisons) .
Sur une note finale, le fait que "se souvenir de moi" est intrinsèquement non sécurisé est l'une des nombreuses raisons pour lesquelles les journaux de site sont très importants, et pourquoi vous devez exiger la revérification du mot de passe dans le processus d'autoriser les modifications des informations de compte importantes (pour le rendre plus difficile pour quelqu'un ayant volé le cookie pour devenir propriétaire du compte).
C'est ce que vous ne devriez jamais faire, car il est très facile de modifier la valeur d'un cookie et de le renvoyer au serveur. Même stocker "l'utilisateur est bloqué en tant que 'naïvistes'" dans un cookie est faux, car je pourrais alors le changer en "l'utilisateur est connecté en tant que 'Pandiya Chendur'".
Ce que vous pouvez faire dans les cookies, c'est donner des informations aux clients qui, même modifiées, n'ont pas de sens pour le serveur. Par exemple - couleur préférée, mise en page de première page et cetera.
Vous pouvez leur donner un ID de session qui est stocké dans un cookie, car ils ne peuvent rien améliorer pour eux-mêmes, s'ils changent la valeur en autre chose (à moins qu'ils ne connaissent un ID de session valide d'une autre session).
Ce que MSDN de Microsoft dit sur l'utilisation des cookies :
Les problèmes de sécurité avec les cookies sont similaires à ceux de l'obtention de données du client. Dans votre application, les cookies sont une autre forme d'entrée d'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 cookie, car le cookie est disponible sur son propre ordinateur. L'utilisateur peut également modifier le cookie avant que le navigateur ne vous l'envoie.
Vous ne devez jamais stocker de données sensibles dans un cookie, telles que les noms d'utilisateur, les mots de passe, les numéros de carte de crédit, etc. Ne placez rien dans un cookie qui ne devrait pas être entre les mains d'un utilisateur ou de quelqu'un qui pourrait en quelque sorte voler le cookie.
De même, méfiez-vous des informations que vous extrayez d'un cookie. Ne présumez pas que les données sont les mêmes que lorsque vous les avez écrites; utilisez les mêmes garanties lorsque vous travaillez avec des valeurs de cookies que vous le feriez avec des données qu'un utilisateur a saisies dans une page Web. Les exemples précédents de cette rubrique ont montré le codage HTML du contenu d'un cookie avant d'afficher la valeur dans une page, comme vous le feriez avant d'afficher les informations que vous obtenez des utilisateurs.
Les cookies sont envoyés entre le navigateur et le serveur sous forme de texte brut, et toute personne qui peut intercepter votre trafic Web peut lire le cookie. Vous pouvez définir une propriété de cookie qui provoque la transmission du cookie uniquement si la connexion utilise le Secure Sockets Layer (SSL). SSL ne protège pas le cookie de la lecture ou de la manipulation lorsqu'il se trouve sur l'ordinateur de l'utilisateur, mais il empêche la lecture du cookie pendant le transport car le cookie est crypté. Pour plus d'informations, voir Pratiques de sécurité de base pour les applications Web.
D'ailleurs, stocker les mots de passe n'est pas sécurisé partout, côté client et côté serveur.
Vous n'avez pas besoin de faire ça.
Il n'est pas sûr de 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 si n'importe quelle exigence utilisateur est là, vous pouvez le faire en chiffrant les chaînes. qui peut rendre cela assez sûr.
mais ce n'est pas recommandé,
Je pense que vous devez créer un jeton avec un nom d'utilisateur et une chaîne d'authentification cryptée que vous obtenez à partir de Windows Identity. Pas besoin de stocker le mot de passe sur le cookie. Nous avons notre application qui stocke le nom d'utilisateur et la chaîne authentifiée
Que Branislav a dit, et ...
En plus de ne pas mettre de données sensibles dans vos cookies, vous devez également les sécuriser en plaçant au moins les éléments suivants dans votre web.config:
<httpCookies httpOnlyCookies="true" />
Pour plus de détails, voir: Comment configurez-vous exactement httpOnlyCookies dans ASP.NET?
Si vous utilisez SSL, ce que vous devez faire si vous transmettez des informations sécurisées, cela empêche un tiers d'écouter votre trafic Web. Ce serait le même problème indépendamment du stockage des informations d'identification d'un utilisateur dans un cookie, car quand il se connecte, vous envoyez de toute façon son nom d'utilisateur et son mot de passe au serveur, où je suppose que le serveur le hache et le compare au mot de passe haché que vous avez pour cet utilisateur.
Les autres domaines ne pourront jamais lire votre cookie en raison de l'origine croisée, ce n'est donc pas un problème.
Donc vraiment le seul "trou de sécurité" si vous voulez l'appeler, c'est si quelqu'un a physiquement accès à son ordinateur. Si cela se produit, ils obtiendront très probablement de toute façon les informations qu'ils souhaitent. Comment expliquez-vous quand chrome remplit automatiquement les formulaires de connexion pour vous, est-ce sécurisé? Je suis sûr qu'ils ne le stockent pas en texte brut mais cela n'a même pas d'importance. Si vous allez sur une page qui chrome remplit automatiquement, vous pouvez simplement copier le mot de passe hors du formulaire et vérifier que vous avez maintenant le mot de passe de cette personne.
Cela dépend vraiment de la "sécurité" dont vous avez besoin. J'accepte que le cryptage des informations d'un utilisateur avec une expiration en tant que jeton est le meilleur moyen d'authentifier les appels de service et offre une flexibilité. Je ne vois tout simplement pas le problème du stockage des informations de connexion dans un cookie.
Ce n'est pas sûr du tout. Les cookies sont stockés dans l'ordinateur client, qui peuvent être modifiés.