Действительно ли опасно сохранять хешированный пароль в куки?

Question

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

По понятной причине вместо пароля следует отправить временный GUIDВ любом случае, я считаю, что ограничение доступа к зарегистрированному IP-адресу может закрыть возможности для злоумышленников использовать локально сохраненный GUID.Конечно, это ограничит продолжительность регистрируемого периода, так как IP обычно динамичен и регулярно меняется;но я думаю, что это стоит своей заметной безопасности.Есть идеи?

Answer 1

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

Здесь есть два риска:

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

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

Answer 2

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

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

Answer 3

Время, когда вы должны попросить пользователя повторно ввести свой пароль:

1. Когда они пытаются изменить свой пароль.
2. Когда они пытаются изменить свой адрес электронной почты.
3. Когда они пытаются изменить свою информацию о безопасности (все, что можно использовать для восстановления своего пароля, включая имя пользователя, адрес электронной почты, контрольный вопрос и т. Д.).
4. Когда они пытаются получить безопасный доступданные учетной записи и не вводили свой пароль более 15 минут или около того (если вся информация надежно защищена, вам следует вместо этого вывести их из системы на предмет бездействия).Amazon много делает.

Сохранение хешированного пароля делает это менее эффективным.

Кроме того, вы уже должны использовать файлы cookie, которые являются безопасными (не будут передаваться по HTTP).), HttpOnly (недоступно через JavaScript) для защиты от атак XSS.Конечно, если кто-то полностью взломает компьютер этого человека, он просто установит кейлоггер.

Answer 4

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

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

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

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

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

Но если это то, что вы спрашиваете, то это уже другая тема.
Т.е. как лучше всего управлять сессиями по HTTP-соединениям