Подтвердить что ты не робот

Безопасно ли хранить пароли в файлах cookie?

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

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?
  • Каков правильный способ сделать то же самое?
  • Каковы наилучшие методы настройки времени для файла cookie?
4b9b3361

ОТВЕТЫ

Ответ 1

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

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

FormsAuthentication.SetAuthCookie(userName, isPersistanceCookie);

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

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

Ответ 2

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

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

FormsAuthentication.SetAuthCookie(username, true);

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

Ответ 3

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

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

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

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

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

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

Ответ 4

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

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

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

Что Microsoft MSDN говорит об использовании файлов cookie:

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

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

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

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

Ответ 5

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

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

Ответ 6

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

Ответ 7

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

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

Ответ 8

Что Branislav сказал, и...

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

<httpCookies httpOnlyCookies="true" />

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

Ответ 9

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

Ответ 10

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

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

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

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