Запомнить меня Cookie лучшая практика?

Question

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

Те же данные cookie сохраняются в БД при создании cookie, и когда пользователи получают cookie, они сравниваются (данные cookie, данные БД).

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

У злоумышленника, который крадет куки, есть тот же куки, что и у исходного пользователя: |

Забыли какой-то шаг? : P

Answer 1

Вы НИКОГДА не должны хранить пароль пользователя в куки, даже если он хеширован !!

Посмотрите на это сообщение в блоге:

• Improved PersistentЛучшая практика использования файлов cookie для входа в систему (ноябрь 2006 г .; bjaspan) ( orignal )

Цитата:

1. Когда пользователь успешновходит в систему, если установлен флажок «Запомнить меня», в дополнение к стандартному файлу управления сеансом выдается файл cookie для входа. [2]
2. Файл cookie для входа в систему содержит имя пользователя, идентификатор серии и токен.Ряд и маркер - это неопровержимые случайные числа из достаточно большого пространства.Все три хранятся вместе в таблице базы данных.
3. Когда незарегистрированный пользователь посещает сайт и представляет файл cookie для входа, имя пользователя, серия и токен ищутся в базе данных.
4. Если триплет присутствует, пользователь считается аутентифицированным.Использованный токен удаляется из базы данных.Создается новый токен, который сохраняется в базе данных с именем пользователя и идентичным идентификатором серии, и новый файл cookie для входа в систему, содержащий все три, выдается пользователю.
5. Если имя пользователя и серия присутствуют, но токена нетматч, кража предполагается.Пользователь получает строго сформулированное предупреждение, и все запомненные сеансы пользователя удаляются.
6. Если имя пользователя и серии отсутствуют, cookie-файл для входа игнорируется.

Answer 2

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

Это важно, если cookie был захвачен.Он будет признан недействительным, если пользователь обнаружит угон, и, кроме того, поскольку токен не связан с паролем, угонщик не сможет получить и затем изменить пароль учетной записи пользователя и «владеть» учетной записью (при условии, что вам требуется существующий парольдо смены паролей угонщик не владеет учетной записью электронной почты, поэтому он не может использовать «Забыли мой пароль» и т. д.)случайные данные, например, из CRNG).

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

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

Answer 3

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

Answer 4

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

Answer 5

Мой подход заключается в следующем:

1. Хеширование user_id
2. Создание уникального ключа для пользователя - md5(current_timestamp)
3. Сохранение ключа вDB
4. Закодируйте все так, чтобы это выглядело как BS - base64
5. Сохраните его в cookie

Пока что это прекрасно работает для меня :)

Answer 6

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

РЕДАКТИРОВАТЬ:

Вот несколько вещей, которые вы можете сделать, чтобы защитить своих пользователей от атак, связанных с кражей файлов cookie:

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

ps Файлы cookie должны содержать (случайные) токены, а не хеши паролей (см. Хэши или токены для файлов cookie "Запомнить меня"? ).

Answer 7

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

И да, если злоумышленник получает cookie, он может выдать себя за пользователя.Но это всегда верно и не имеет ничего общего с «запомни меня».