Как лучше всего реализовать «запомни меня» для веб-сайта? [закрыто]

510

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

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

Vort3x
источник
5
Проверьте stackoverflow.com/questions/549/… (часть II из топ ответ)
Морозный Z
если вы используете ASP.NET, ознакомьтесь с codeproject.com/Articles/779844/Remember-Me
Believe2014
1
В Security SE есть очень полезная информация: security.stackexchange.com/questions/19676/…
b1nary.atr0phy
В настоящее время принятый ответ от splattne является слишком сложным. Создайте токен +16 байт из случайного источника, хешируйте его и сохраните идентификатор учетной записи хэш + в базе данных. Затем отправьте токен пользователю (в кодировке base64) в файле cookie HTTPS + httpOnly (чтобы Javascript не мог получить к нему доступ или украсть его). Таким образом, никто не может угадать токен или выйти из системы с неверными догадками, но даже если ваша база данных взломана, никто не может использовать токены в базе данных (они хэшируются). Поэтому его может использовать только оригинальный клиент (или кто-то, кто каким-то образом украл токен из магазина браузера).
Xeoncross

Ответы:

536

Усовершенствованная практика использования файлов cookie для постоянного входа в систему

Вы можете использовать эту стратегию, описанную здесь, в качестве передового опыта (2006 г.) или обновленную стратегию, описанную здесь (2015 г.):

  1. Когда пользователь успешно входит в систему с установленным флажком Запомнить меня, в дополнение к стандартному файлу управления сеансом выдается файл cookie для входа .
  2. Файл cookie для входа в систему содержит идентификатор серии и токен . Ряд и маркер - это неопровержимые случайные числа из достаточно большого пространства. Оба хранятся вместе в таблице базы данных, токен хэширован (sha256 в порядке).
  3. Когда незарегистрированный пользователь посещает сайт и представляет файл cookie для входа, идентификатор базы данных ищется в базе данных .
    1. Если идентификатор серии присутствует и хэш токена совпадает с хешем для этого идентификатора серии, пользователь считается аутентифицированным . Создается новый токен , новый хеш для токена сохраняется поверх старой записи, и пользователю выдается новый файл cookie для входа (можно повторно использовать идентификатор серии ).
    2. Если серия присутствует, но токен не совпадает, предполагается кража . Пользователь получает строго сформулированное предупреждение, и все запомненные сеансы пользователя удаляются.
    3. Если имя пользователя и серия отсутствуют, cookie для входа в систему игнорируется .

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

сплаттне
источник
20
см. также: stackoverflow.com/questions/549/… НЕ стоит читать «улучшенную» версию
Jacco
8
Проблема в том, что вы выставляете имя пользователя в куки, хотя это то, что делает Gmail. Зачем вам нужен и серийный номер, и токен? Разве большой токен не подойдет?
Дэн Розенстарк
10
Кроме того, что касается этой модели, что нужно для предотвращения кражи злоумышленником и чем разместить куки на своем компьютере и удалить куки с взломанного компьютера. Его компьютер будет аутентифицирован и обновлен по мере необходимости без взломанного компьютера? Единственным изменением будет то, что пользователю взломанного компьютера придется снова войти в систему и установить запомнить меня. Будет ли взломанный пользователь распознает это, будет неясно.
24
@HiroProtagonist Идентификатор серии предназначен для предотвращения DoS-атаки. Без этого я мог бы быстро написать скрипт, который будет отображать ваш сайт с каждым именем пользователя и недействительным токеном, выводя всех из вашего сайта.
Крис Москини
6
Это решение НЕПРАВИЛЬНО, оно не обрабатывает cuncurrency: если два запроса аутентификации Remember-Me приходят в одно и то же время с одним и тем же cookie-файлом Remember-Me, первый завершается успешно и меняет токен, второй вызывает неудачную аутентификацию, и ложная тревога (потому что токен уже был изменен первым запросом). (Такая ситуация может возникнуть при запуске браузера и восстановлении сайта в двух вкладках браузера.)
slobo
9

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

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

dragonmantank
источник
8

Сохраните их UserId и RememberMeToken. Когда они регистрируются с пометкой «Помни меня», генерируют новый RememberMeToken (который делает недействительными любые другие машины, помеченные как «Помни меня»).

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

jonnii
источник
Это может быть грубо принудительно в считанные секунды. Я просто установлю свой user_id на 1 и перебью все токены. Это даст мне доступ в считанные секунды
Друг
4

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

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

4 способа украсть ваши куки (из комментария Дженса Роланда на странице, на котором @splattneоснован его ответ):

  1. Перехватывая его по небезопасной линии (перехват пакетов / перехват сеансов)
  2. Прямой доступ к браузеру пользователя (через вредоносное ПО или физический доступ к коробке)
  3. Читая его из базы данных сервера (возможно, SQL-инъекция, но может быть что угодно)
  4. Путем взлома XSS (или подобного эксплойта на стороне клиента)
Ярл
источник
104
1. HTTPS предназначен для предотвращения этого. 2. Оставайтесь в системе - это не проблема безопасности, у вас есть большие проблемы. 3. То же, что и 2. 4. Это можно предотвратить с помощью политики контроля доступа и надлежащей санитарии ввода; Если вы не предпримете эти шаги, у вас снова будут большие проблемы, чем оставаться в системе.
Крис Москини