Хранение регистрационной информации в Cookies - PullRequest
7 голосов
/ 14 июня 2011

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

Итак, если пользователь хочет запомнить свою регистрационную информацию, и если я храню имя пользователя (электронная почта) + не пароль, а некоторую другую уникальную информацию, такую ​​как HASHED DB ID в cookie. Затем я должен проверить, совпадает ли хешированный идентификатор, сохраненный в cookie, с электронной почтой пользователя, которая хранится в Cookie. Как я думаю, любой может очень легко увидеть файлы cookie, хранящиеся в браузере (например, в Firefox, «Настройки» -> «Файлы cookie»).

Так будет ли это настолько же слабым, как если бы кто-то прочитал файл cookie с компьютера, на котором он был сохранен, а затем на другом компьютере установил файл cookie с этой информацией, и он вошел бы в систему? (Как скрипт проверит сохраненную почту и хешированный идентификатор с базой данных и будет совпадать)?

Можно ли немного улучшить этот подход, не сохраняя в базе данных другую информацию (например, идентификатор сеанса и т. Д.)? Спасибо

Ответы [ 7 ]

12 голосов
/ 14 июня 2011

Есть еще один вариант.

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

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

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

Если он совпадает -> войдите в систему пользователя и создайте для него новый cookie-файл запомнить.
Если не совпадают -> запросить имя пользователя и пароль.

1 голос
/ 14 июня 2011

Я написал ответ на тот же вопрос в Как улучшить мою схему входа пользователя - посмотрите там.

0 голосов
/ 14 июня 2011

я думаю, что нет другого выбора

Подумай еще раз.

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

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

0 голосов
/ 14 июня 2011

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

0 голосов
/ 14 июня 2011

Есть хорошая статья о том, как сделать куки "запомнить меня" более безопасными: http://jaspan.com/improved%5Fpersistent%5Flogin%5Fcookie%5Fbest%5Fpractice

Я реализовал метод, описанный в статье, в библиотеке PHP: https://github.com/gbirke/rememberme, возможно, вы можете использовать его в качестве ссылки.

Фиксация сессии и кража файлов cookie - реальная проблема в возрасте Firesheep . Единственная защита от этого - защита вашего сайта с помощью SSL и отслеживание ошибок XSS.

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

Дополнительные ресурсы см. В этом вопросе: Полное руководство по аутентификации веб-сайтов на основе форм

0 голосов
/ 14 июня 2011

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

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

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

Так что ищите какое-нибудь обратимое шифрование, и это должно сделать ваш день;)

0 голосов
/ 14 июня 2011

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

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

Это объяснение об аутентичных куки в .NET, но я думаю, что концепция работает и на php: http://support.microsoft.com/kb/910443

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...