Безопасно ли хранить пароли в куки? - PullRequest
57 голосов
/ 20 января 2010

Домашняя страница моего веб-приложения имеет флажок 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?

Ответы [ 10 ]

58 голосов
/ 20 января 2010

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

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

FormsAuthentication.SetAuthCookie(userName, isPersistanceCookie);

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

HttpCookie authCookie =
  HttpContext.Current.Request.Cookies[FormsAuthentication.FormsCookieName];
25 голосов
/ 20 января 2010

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

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

FormsAuthentication.SetAuthCookie(username, true);

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

15 голосов
/ 20 января 2010

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

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

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

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

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

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

10 голосов
/ 20 января 2010

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

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

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

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

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

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

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

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

2 голосов
/ 30 января 2010

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

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

2 голосов
/ 20 января 2010

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

2 голосов
/ 20 января 2010

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

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

1 голос
/ 10 апреля 2013

Что Бранислав сказал, и ...

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

<httpCookies httpOnlyCookies="true" />

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

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

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

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

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

0 голосов
/ 20 января 2010

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

...