Каковы риски хранения пароля пользователя в Cookie, когда соединение осуществляется через https?

Question

Примечание

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

Я прочитал и согласен с принципалами, что в cookie в любое время не должно храниться ничего, кроме идентификатора сеанса.

История

Однако ... Я унаследовал старое ржавое приложение, которое хранит имя пользователя, пароль и дополнительный идентификатор в файле cookie, который проверяется по всему сайту как проверка / авторизация.

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

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

Вопрос

Высказывая властям о том, что хранение идентификаторов / паролей своих пользователей в виде открытого текста в Cookie - крайне плохая идея, какие реальные риски связаны, учитывая, что соединение всегда инициируется и управляется через HTTPS?

Например: является ли единственный очевидный способ скомпрометировать эту информацию через Физический доступ к машине, содержащей Cookie? Какие еще существуют реальные риски?

Answer 1

HTTPS просто защищает от атаки «человек посередине», шифруя данные, передаваемые по проводам. Информация по-прежнему будет в текстовом виде на клиенте. Таким образом, все, что находится на компьютере клиента, может просмотреть информацию cookie и извлечь соответствующую информацию.

Answer 2

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

Answer 3

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

Answer 4

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

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

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

Answer 5

Люди здесь уже упоминали атаку "человек посередине". Дело в том, что даже с https это все еще возможно. Есть разные способы сделать это - некоторые из них ретранслируют физический доступ к сети, некоторые нет.

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

Браузер обнаружит проблемы с сертификатом - обычно он либо будет выдан на другое имя DNS, либо, скорее всего, он не будет проверен.

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

Какой риск это создает, зависит от среды и от того, кто (насколько обучаем) пользователи

Answer 6

Некоторые браузеры хранят файлы cookie в файле, который может отображаться на компьютере. IE6 приходит на ум. Мне кажется, что куки не ограничиваются одним сайтом. Много рекламы использует куки на нескольких сайтах. Если я пойду в NextTag и найду камеру Nikon D700, то Я вижу рекламу NextTag на slashdot.org. Это пример межсайтового cookie. Большинство пользователей используют один и тот же пароль во всей сети, поэтому, если вы сохраните пароль для одного сайта и сделаете его даже немного доступным, злоумышленники рано или поздно попадут на него.

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

Answer 7

Две две основные уязвимости - это межсайтовые скриптовые атаки и доступ к компьютеру пользователя.

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