Безопасно ли хранить пароли в куки?

Домашняя страница моего веб-приложения имеет RememberMe. Если пользователь проверяет его, я буду хранить email-id и пароль в cookies. Это мой код:

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

то, что я хочу знать:

  • безопасно ли хранить пароли в куки?
  • Как правильно делать то же самое?
  • каковы наилучшие методы установки времени для файла cookie?
10 56
c# asp.net-mvc passwords remember-me

10 ответов:

хранить пароли в файлах cookie небезопасно, поскольку они доступны в виде обычного текста.

хорошее место, чтобы найти некоторые ответы о печенье Cookie Central. для членства обычно используется файл cookie с длинной строкой под названием "токен", который выдается с веб-сайта, когда вы предоставляете свое имя пользователя и пароль. Подробнее о процессе вы можете узнать в этом статьи. При использовании проверки подлинности с помощью форм в ASP.NET вы можете установить аутентификацию печенье, как это:

FormsAuthentication.SetAuthCookie(userName, isPersistanceCookie);

второй параметр используется для функции "Запомнить меня" - если true, он будет создавать постоянные куки, которые будут длиться после того, как вы покинете сайт. Вы также можете программно управлять cookie следующим образом:

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

нет! Не храните пароли в файлах cookies!

In ASP.NET, используйте 

FormsAuthentication.SetAuthCookie(username, true);

значение второго аргумента определяет, является ли файл cookie постоянным (значение флажка remember me).

25

нет, не совсем безопасно. У вас нет гарантии, что файлы cookie не хранятся в виде обычного текста (и на самом деле, большинство реализаций do хранить их в виде обычного текста).

имейте в виду, что" помните меня " по своей сути небезопасно, так как любой, кто перехватывает cookie, получает доступ к приложению. Но разоблачение пароля пользователя делает его еще одним шагом вниз по лестнице безопасности. :- ) И, вероятно, делает пользователя действительно безумным, если они узнают.

Я использую зашифрованный файл cookie строка, которая включает имя учетной записи Пользователя в сочетании с токеном, который никаким (другим) образом не связан с учетной записью пользователя, кроме как в таблице на моем сервере. Когда пользователь возвращается на сайт, мы расшифровываем файл cookie и ищем, действительно ли этот токен связан с этой учетной записью. Маркер (и, следовательно, cookie) изменяет каждый автоматический вход и делает недействительным тот, который используется для этого автоматического входа. (Существует отношение "многие к одному" между токенами и учетной записью, чтобы разрешить автоматический вход из нескольких мест. Вы можете ограничить это, если хотите.) Токены тайм-аут, если они не используются в течение X дней. (Это делается не только путем ограничения продолжительности файла cookie, но и на стороне сервера.) Есть несколько других вещей, которые я бросаю туда, чтобы сделать жизнь немного трудно для кого-то, кто пытается декодировать куки (успешно расшифровав его) или использовать украденный куки (который не требует расшифровки), но нет смысла идти на излишек (опять же, " помните меня по своей сути небезопасно).

Я использую это на сайте, где надежная безопасность на самом деле не нужна (очевидно) и у которого есть большое количество динамических IP-клиентов, и поэтому я не пытаюсь заблокировать его до IP. Но даже блокировка его до IP не делает его безопасным, он просто немного уменьшает поверхность атаки.

вам может быть интересно, почему у меня есть имя пользователя в файле cookie. Для прямых целей "Запомнить меня" я бы не рекомендовал иметь его там, даже если он зашифрован (после все, это половина пары аутентификации в системе имя пользователя+пароль). Я был немного удивлен, обнаружив его в нашем файле cookie, когда я посмотрел на формат, напоминая себе, как мы это сделали для этого вопроса; но затем я увидел комментарии, объясняющие, почему он есть, и есть причины, не связанные с " Запомнить меня "(не обязательно убеждения причины, оглядываясь назад, но причины).

на заключительной ноте, тот факт, что "помните меня" по своей сути небезопасно является одной из многих причин почему журналы сайта очень важны, и почему вы должны требовать изменения пароля в процессе разрешения изменений важной информации об учетной записи (чтобы затруднить кому-то, кто украл куки, чтобы стать владельцем учетной записи).

15

Это то, что вы никогда не должны делать, потому что это очень легко изменить значение cookie и отправить обратно на сервер. Даже хранение "пользователь looged в качестве" наивистов "в файле cookie неправильно, потому что я мог бы изменить его на"пользователь вошел в систему как "Пандия Чендур"".

то, что вы можете сделать в cookies, - это предоставить клиентам информацию, которая, даже если она изменена, не имеет смысла для сервера. Например-любимый цвет, макет первой страницы и так далее.

вы можете дать их идентификатор сеанса, который хранится в файле cookie, потому что они не могут сделать ничего лучше для себя, если они изменяют значение на что-то другое (если они не знают действительный идентификатор сеанса из другого сеанса).

Что такое Microsoft MSDN говорит об использовании cookies:

проблемы безопасности с куки являются аналогично получению данных из клиент. В вашем приложении, cookies-это еще одна форма входа пользователей и поэтому подлежат рассматривающий и спуфинг. Пользователь может как минимум увидеть данные, которые вы храните в печенье, так как печенье доступно на собственном компьютере пользователя. Пользователь можно также изменить куки перед началом браузер отправляет его вам.

вы никогда не должны хранить конфиденциальные сведения в файле cookie, например имена пользователей, пароли, номера кредитных карт и т. на. Не кладите ничего в печенье это не должно быть в руках пользователь или кто-то, кто может как-то украсть печенье.

точно так же, будьте подозрительны информацию вы получаете из печенья. Не предполагайте, что данные являются так же, как когда вы написали его; используйте же гарантии в работе с cookie значения, которые вы бы с данными, что пользователь ввел в веб-страницу. Этот примеры ранее в этом разделе показали HTML-кодирование содержимого файла cookie перед отображением значения на странице, как вы бы перед отображением любого информацию вы получаете от пользователей.

куки отправляются между браузером и сервер как обычный текст, так и любой, кто может перехватывать ваш веб-трафик может почитай печенье. Вы можете установить куки свойство, которое вызывает куки-файл передается только в том случае, если соединение использует протокол SSL (Secure Sockets Layer). SSL не защищает файл cookie от читается или манипулируется, пока он есть на компьютере пользователя, но это запретить чтение файла cookie в то время как в пути, потому что куки зашифрованный. Для большего информация, см. Основные методы обеспечения безопасности в Интернете Приложения.

9

хранить пароли в файлах cookie небезопасно, поскольку они доступны в виде обычного текста. но если ваши предпочтительные критерии-это сделать это или любое требование пользователя, вы можете сделать это, зашифровав строки. это может сделать это достаточно безопасным.

но это не рекомендуется,

2

Я думаю, что вам нужно создать маркер с именем пользователя и зашифрованной строкой аутентификации, которую вы получаете от Windows Identity. Нет необходимости хранить пароль на куки. У нас есть наше приложение, которое хранит имя пользователя и аутентифицированную строку

2

кстати, хранить пароли не везде безопасно, как на стороне клиента, так и на стороне сервера.

вам не нужно этого делать.

2

что Бранислав - сказал, А...

в дополнение к тому, чтобы не помещать конфиденциальные данные в куки, вы также должны защитить их, разместив по крайней мере следующее в своем интернете.config:

<httpCookies httpOnlyCookies="true" />

Подробнее см.:как именно вы настраиваете httpOnlyCookies в ASP.NET?

1

Это совсем не безопасно. Файлы cookie хранятся на клиентском компьютере, которые могут быть изменены.

0

  • Если вы используете SSL, который вы должны, если вы передаете любую безопасную информацию, это исключает третью сторону от прослушивания вашего веб-трафика. Это будет та же проблема, независимо от хранения учетных данных пользователей в файле cookie, потому что, когда они входят в систему, вы все равно отправляете свое имя пользователя и пароль на сервер, где я предполагаю, что сервер хэширует его и сравнивает его с хэшированным паролем, который у вас есть для этого пользователя.

  • другие домены никогда не сможет прочитать ваш файл cookie из-за перекрестного происхождения, так что это не проблема.

  • Так что на самом деле единственная "дыра в безопасности", если вы хотите ее назвать, это если кто-то физически получает доступ к своему компьютеру. Если это произойдет, они, скорее всего, получат любую информацию, которую хотят от этого человека в любом случае. Как вы объясните, когда chrome автоматически заполняет формы входа для вас, это безопасно? Я уверен, что они не хранят его в обычном тексте, но это даже не имеет значения. Если вы перейдете на страницу, которую chrome автоматически заполняет, вы можете просто скопировать пароль из формы и посмотреть, что у вас теперь есть этот пароль.

  • это действительно сводится к тому, насколько "безопасно" вам это нужно. Я согласен с тем, что шифрование информации о пользователях с истечением срока действия в качестве маркера является лучшим способом аутентификации вызовов служб и обеспечивает гибкость. Я просто не вижу проблемы с хранением учетных данных в cookie.

-1