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

Question

La page d'accueil de mon application web comporte un RememberMe case à cocher. Si l'utilisateur la coche, je stocke l'adresse 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 procéder ?
• Quelles sont les meilleures pratiques pour fixer le temps d'un cookie ?

Answer 1

Il n'est PAS sûr de stocker les mots de passe dans les cookies car ils sont disponibles en texte clair.

Un bon endroit pour trouver des réponses sur les cookies est le suivant Cookie Central. Pour l'adhésion, on utilise généralement un cookie contenant une longue chaîne de caractères appelée "jeton" qui est émis par le site web lorsque vous fournissez votre nom d'utilisateur et votre mot de passe. Pour en savoir plus sur le processus, consultez le site suivant article . Lorsque vous utilisez l'authentification par formulaire en ASP.NET, vous pouvez définir le cookie d'authentification comme suit :

FormsAuthentication.SetAuthCookie(userName, isPersistanceCookie);

Le deuxième paramètre est utilisé pour la fonctionnalité "Se souvenir de moi" - si elle est activée, elle créera des cookies persistants qui dureront après que vous aurez quitté le site. Vous pouvez également manipuler le cookie de manière programmatique comme ceci :

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

Answer 2

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

En 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 remember me).

Answer 3

Non, pas du tout. Vous n'avez aucune garantie que les cookies ne sont pas stockés en texte clair (et en fait, la plupart des implémentations de ces cookies ne sont pas sécurisées). faire les stocker en texte brut).

Il faut savoir que la fonction "remember me" est intrinsèquement peu sûre, car quiconque intercepte le cookie a accès à l'application. Mais exposer le mot de passe d'un utilisateur fait descendre encore plus bas dans l'échelle de l'insécurité :-) Et rend probablement l'utilisateur très furieux, s'il le découvre.

J'utilise une chaîne de cookies cryptés qui comprend le nom du compte de l'utilisateur combiné à un jeton qui n'est associé d'aucune façon (autre) au compte de l'utilisateur, sauf dans une table sur mon serveur. Lorsque l'utilisateur revient sur le site, nous décryptons le cookie et vérifions si ce jeton est effectivement associé à ce compte. Le jeton (et donc le cookie) change à chaque auto-login, et invalide celui utilisé pour cet auto-login. (Il y a une relation multiple entre les jetons et le compte, pour permettre l'auto-login à partir de plusieurs endroits. Vous pouvez limiter cela si vous le souhaitez). Les jetons expirent s'ils ne sont pas utilisés dans un délai de X jours. (Cela ne se fait pas seulement en limitant la durée du cookie, mais aussi côté serveur). Il y a quelques autres choses que j'ai ajoutées pour rendre la vie plus facile. bit difficile pour quelqu'un qui essaierait 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 est inutile d'en faire trop (encore une fois, "remember me" 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 dynamique, et donc je n'essaie pas de le verrouiller à une IP. Mais même le fait de le verrouiller sur une IP ne le rend pas sûr, cela réduit juste un peu la surface d'attaque.

Vous vous demandez peut-être pourquoi j'ai le nom d'utilisateur dans le cookie. Pour des raisons de "mémorisation", je ne recommanderais pas de l'y placer, même s'il est crypté (après tout, c'est la moitié de la paire d'authentification dans un système de nom d'utilisateur et de 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 cela pour cette question ; mais ensuite j'ai vu les commentaires expliquant pourquoi il est là et il y a des raisons sans rapport avec le "remember me" (pas nécessairement persuasif des raisons, a posteriori, mais des raisons).

Enfin, le fait que la fonction "se souvenir de moi" soit intrinsèquement peu sûre est l'une des nombreuses raisons pour lesquelles les journaux de site sont très importants, et pourquoi vous devriez exiger la revérification du mot de passe dans le processus d'autorisation des modifications des informations importantes du compte (pour qu'il soit plus difficile pour une personne ayant volé le cookie de s'approprier le compte).

Answer 4

C'est ce que vous ne devriez jamais faire, car il est très facile de modifier la valeur d'un cookie et de la renvoyer au serveur. Même stocker "l'utilisateur est connecté en tant que 'naivists'" dans un cookie est une erreur, car je pourrais ensuite le changer en "l'utilisateur est connecté en tant que 'Pandiya Chendur'".

Ce que vous pouvez faire avec les cookies, c'est donner des informations aux clients qui, même si elles sont modifiées, n'ont pas de sens pour le serveur. Par exemple, la couleur préférée, la mise en page de la première page, etc.

Vous pouvez leur donner un identifiant 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 quelque chose d'autre (à moins qu'ils ne connaissent un identifiant de session valide provenant d'une autre session).

Ce que le MSDN de Microsoft dit à propos de l'utilisation des cookies :

Les problèmes de sécurité liés aux cookies sont les suivants similaires à ceux de l'obtention de données à partir de le client. Dans votre application, les cookies sont une autre forme d'entrée utilisateur et sont donc sujets à l'examen et d'usurpation. Un utilisateur peut au minimum voir les données que vous stockez dans un cookie, puisque le cookie est disponible sur l'ordinateur de l'utilisateur. 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, comme les noms d'utilisateur, les mots de passe, les numéros de carte de crédit, etc. etc. Ne mettez 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 obtenez d'un cookie. Ne supposez pas que les données sont sont les mêmes que lorsque vous les avez écrites. les mêmes précautions pour travailler avec les que vous le feriez avec des données qu'un données qu'un utilisateur a saisies dans une page Web. Le site exemples présentés plus haut dans cette rubrique montraient le codage le codage HTML du contenu d'un cookie avant d'afficher la valeur dans une page, comme vous le feriez avant d'afficher toute informations que vous recevez des utilisateurs.

Les cookies sont envoyés entre le navigateur et serveur en texte clair, et toute personne qui peut intercepter votre trafic Web peut lire le cookie. Vous pouvez définir une propriété cookie qui fait en sorte que le cookie soit transmis uniquement si la connexion utilise le protocole SSL (Secure Sockets Layer). SSL ne protège pas le cookie contre être lu ou manipulé lorsqu'il se trouve sur l'ordinateur de l'utilisateur, mais il empêche mais il empêche la lecture du cookie pendant son transit, car le cookie est crypté. Pour plus d'informations, voir Pratiques de sécurité de base pour les applications Web.

Answer 5

Je pense que vous devez créer un jeton avec le nom d'utilisateur et une chaîne d'authentification cryptée que vous obtenez de Windows Identity. Il n'est pas nécessaire de stocker le mot de passe dans le cookie. Nous avons notre application qui stocke le nom d'utilisateur et la chaîne d'authentification.