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

Question

Я использую asp.net mvc 2.0 и мне интересно, насколько безопасно хранить информацию в cookie-файле?

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

string encryptedTicket = FormsAuthentication.Encrypt(authTicket)
HttpCookie authCookie = new HttpCookie(FormsAuthentication.FormsCookieName, encryptedTicket);

Как будто я не храню пароль или что-то в этом роде, но я хочу сохранить UserId, потому что в настоящее время каждый раз, когда пользователь отправляет запрос на мой сайт, я должен выполнить запрос и получить для этого пользователя идентификатор пользователя, поскольку каждая таблица в БД требует, чтобы вы использовали userId, чтобы вернуть правильный ряд.

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

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

Покажите, насколько хорошо это шифрование, которое использует Аутентификация?

Answer 1

Шифрование достаточно хорошее, это не слабое звено.

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

Итак,информация в куки достаточно безопасна, но вы сами не можете защитить куки.

Answer 2

Название вашего вопроса не совсем соответствует тому, что вы спрашиваете.Здесь есть две разные вещи, которые вы спрашиваете.

1.Есть ли безопасный способ хранения данных в куки?

Ответ - да.Для безопасного хранения данных в cookie-файле вы должны зашифровать данные, которые вы хотите сохранить, а затем подписать зашифрованные данные.Шифрование защищает злоумышленников от возможности чтения данных, а его подпись не позволяет злоумышленникам изменять данные.Это обеспечит целостность данных.Вы можете использовать этот метод для хранения данных о пользователе, которого вы хотите сохранить в тайне (его адрес электронной почты, дата рождения и т. Д.). Примечание. Безопасное хранение данных в файле cookie не является безопасным способом аутентификации пользователя! Если вы сохранили идентификатор пользователя в подписанном и зашифрованном файле cookie, ничто не мешает злоумышленнику украсть весь файл cookie иотправив его обратно на сервер.Нет никакого способа узнать, был ли куки-файл аутентификации получен из того же браузера, где пользователь ввел свое имя пользователя и пароль.Что приводит нас ко второму вопросу (тот, который вы на самом деле задавали) ...

2.Существует ли безопасный способ аутентификации пользователя с помощью файла cookie?

Да.Для безопасной аутентификации пользователя вы должны объединить приемы из вопроса 1 с SSL (https).SSL гарантирует, что только браузер сможет получить доступ к файлу аутентификации (подписанный зашифрованный куки с идентификатором пользователя в нем).Это означает, что ваш процесс входа в систему (принятие имени пользователя и пароля, а также установка файла cookie аутентификации) должен происходить через SSL.Вы также должны установить для свойства HttpCookie.Secure значение true, когда вы устанавливаете куки-файл аутентификации на сервере.Это говорит браузеру, что нужно включать этот cookie только при отправке запросов на ваш сайт через SSL.Вы также должны указать время истечения срока действия в зашифрованном файле cookie для аутентификации, чтобы защитить себя от того, что кто-то забудет выйти из вашего сайта, пока он находится в библиотеке.Побочным эффектом этого подхода является то, что только страницы на вашем сайте, которые имеют SSL, смогут аутентифицировать пользователя.Что поднимает третий вопрос ...

3.Как вы надежно аутентифицируете пользователя без использования SSL?

Нет.Но у вас есть варианты.Одна из стратегий состоит в том, чтобы создать два файла cookie для аутентификации при входе в систему, один обычный файл cookie и один только для ssl (как зашифрованный, так и подписанный).При выполнении конфиденциальных операций от имени пользователя необходимо, чтобы страница была в формате SSL, и использовать файл cookie только для SSL.При выполнении нечувствительных операций (таких как просмотр магазина, настроенного в зависимости от страны, в которой находится его учетная запись), вы можете использовать обычный файл cookie авторизации.Другой вариант - разделить страницу так, чтобы информация, требующая знания того, кто пользователь, была извлечена асинхронно через AJAX или json.Например: вы возвращаете всю страницу блога по протоколу http, а затем делаете запрос SSL AJAX, чтобы получить имя текущего пользователя, адрес электронной почты, изображение профиля и т. Д. Мы используем оба эти метода на веб-сайте, на котором я работаю.

Я знаю, что этот вопрос задавали почти год назад.Я пишу это для потомков.: -)

Answer 3

Наряду с шифрованием cookie вы также должны внедрить вращающийся токен для предотвращения атак воспроизведения.

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

ОБНОВЛЕНИЕ
В одном из комментариев был задан вопрос, хочу ли я сохранить значение впеченье.Ответ - да.ВЕСЬ файл cookie должен быть зашифрован, что может быть сделано автоматически с использованием HttpModule.В зашифрованном cookie-файле находится любая ваша обычная информация + токен для изменения.

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

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

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

ОБНОВЛЕНИЕ 2
Я пытался выяснить,это лучше или хуже, чем хранить измененное значение в сеансе.Я пришел к выводу, что хранение вращающегося значения в сеансе на веб-сервере абсолютно ничего не делает для предотвращения атак воспроизведения и поэтому менее безопасно, чем помещение этого значения в cookie.

Рассмотрим этот сценарий.Браузер делает запрос.Сервер просматривает идентификатор сеанса и извлекает объекты сеанса, затем выполняется работа и ответ отправляется обратно в браузер.Тем временем BlackHat Bob записал транзакцию.

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

Так что, несмотря ни на что, для предотвращения повторного воспроизведения вы должны отправитьменяя токен в браузере после каждого запроса.

Теперь у нас возникает вопрос о том, также сохранять значения, такие как идентификатор пользователя, в зашифрованном cookie или сохранять его на стороне сервера впеременная сеанса.В сеансе у вас есть проблемы, такие как более высокая загрузка памяти и процессора, а также потенциальные проблемы с балансировкой нагрузки и т. Д. С файлами cookie у вас есть некоторый объем данных, который составляет менее 4 КБ, и, при правильном выполнении, в диапазоне 1 КБ или меньше, который добавляетсяна каждый запрос.Я полагаю, что все сводится к тому, хотите ли вы добавить больше / больше серверов и внутреннего сетевого оборудования для обработки запросов (сеанс) или заплатить за немного больший интернет-канал (cookie).

Answer 4

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

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

Как только пользователь будет идентифицирован или аутентифицирован, продолжайте и сохраните объект пользователя или ключевые свойства в Session.

Answer 5

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

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

edit: шифрование файлов cookie привело к атаке оракула ASP.NET . Этого следует избегать все вместе, используя криптографический одноразовый номер. Как я уже сказал, это грубое злоупотребление криптографией.

Answer 6

Для вашего очень специфического сценария (идентификатор пользователя) короткий ответ: NO !

. Для длинного ответа представьте себе этот гипотетический сценарий:

1. Вы переходите на stackoverflow.com;
2. Введите свое имя пользователя / пароль и отправьте форму;
3. Сервер отправляет вам файл cookie, содержащий ваш идентификатор пользователя, который будет использоваться для идентификации вас наследующие запросы;
4. Поскольку ваше соединение НЕ было защищено (HTTPS), злоумышленник прослушал его и захватил cookie.
5. Злоумышленник получает доступ к вашей учетной записи, поскольку сервер не 'Мы не можем хранить, скажем, ваш IP-адрес и, следовательно, не можем отличить ваш компьютер от компьютера злоумышленника.

По-прежнему в этом сценарии представьте, что сервер сохранил ваш IP-адрес, но вы "Вы находитесь в корпоративной локальной сети, и ваш внешний IP такой же, как у других 100 машин.Представьте, что кто-то, имеющий доступ к одному из этих компьютеров, скопировал ваш файл cookie.Вы уже получили это, верно?: -)

Мой совет: помещать конфиденциальную информацию в сеанс HTTP .

ОБНОВЛЕНИЕ: наличие сеанса подразумевает использование куки (или вкак минимум уродливый URL), что возвращает нас к той же самой проблеме: ее можно перехватить.Единственный способ избежать этого - добавить сквозное шифрование: HTTP + SSL = HTTPS .И если кто-то говорит: «О, но куки / сеансов должно быть достаточно, чтобы обескуражить большинство людей», посмотрите Firesheep .

Answer 7

Это хорошо (не отлично, но не неправильно ) с точки зрения безопасности. Однако с точки зрения производительности вам следует избегать этого.

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

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

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

Answer 8

Шифрование значения идентификатора пользователя в файле cookie не позволяет пользователю узнать, что это за значение. Это не

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

Шифрование cookie также приводит к проблеме управления ключами. Например, когда вы поворачиваете ключ шифрования, вы должны убедиться, что «живые» сеансы со старым ключом не будут сразу завершены неудачей. Вы думали об управлении ключом шифрования, верно? Что происходит, когда уходят админы? Это скомпрометировано? и т.д.

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

Объект сеанса, вероятно, будет намного проще и безопаснее для вашей заявленной озабоченности.

Answer 9

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

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

Answer 10

Использование, которое вы просматриваете, является именно той целью, которая предназначена для хранения информации в бланке Auth Auth.