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

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

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

FormsAuthentication.SetAuthCookie(username, true);

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

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

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

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

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

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

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

Это то, что вы никогда не должны делать, потому что это очень легко изменить значение cookie и отправить обратно на сервер. Даже хранение "пользователь looged в качестве naivists" в cookie-это неправильно, потому что я мог бы изменить его "пользователь вошел в систему как 'Pandiya Chendur'".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<httpCookies httpOnlyCookies="true" />

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

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

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

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

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

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