Будет ли эта система cookie безопасна для хранения паролей?

Question

Я хотел бы ввести пароль для этой системы хранения пароля cookie,

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

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

Затем сервер декодирует пароль с ключом шифрования, когда это необходимо.

Answer 1

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

Лучшая защита - используйте SSL , чтобы безопасность была сквозной.Если вы работаете с серьезным коммерческим сайтом, вам следует использовать SSL, а не ifs ands или buts.Использование cookie-файлов SSL всегда будет зашифровано по проводной сети, поэтому их содержание не имеет большого значения, поскольку вектор атаки меняется с перехвата пакетов на необходимость считывания cookie-файлов с жестких дисков конечных пользователей.

Если ваш сайт не такой уж серьезный, тогда читайте дальше.

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

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

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

Answer 2

Не в обиду, но зачем тебе изобретать велосипед?

Многие уже реализовали свои собственные версии этого конкретного колеса, так почему бы не поискать SourceForge?Программное обеспечение многократного использования - можете ли вы кодировать это быстрее, чем вы можете найти приемлемое (и проверенное) решение?

Используйте строительные блоки с полки для тяжелой работы и переходите к интересным деталям; -)

Answer 3

За @caf, добавив это как ответ:

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

• Для клиента это просто случайные данные, так как он не знает ключ
• Для сервера это ничем не отличается от любых других данных, которые
  1. Уникально для клиента и
  2. Секрет на сервер
• Для злоумышленника это ни больше, ни меньше случайный (или, аналогично, трудный для грубой силы), чем случайное число равной битовой длины.

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

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

Answer 4

Как сказал Леоникс, это, вероятно, лучше оставить кому-то, кто разработал его раньше и исправил все ошибки.Особенно потому, что это связано с безопасностью.

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