Что лучший метод должен защитить cookie-данные входа в систему в PHP?

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

Заранее спасибо.

5
задан Aaron Harun 23 July 2010 в 18:42
поделиться

5 ответов

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

23
ответ дан 18 December 2019 в 05:48
поделиться

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

  1. Файлы cookie - это в основном текстовые файлы, которые может открывать любой пользователь компьютера с помощью любого текстового редактора.
  2. Файлы cookie хранятся на компьютере пользователя, это означает, что у него нет ограничений по времени, без ограничений на количество подключений, без ограничений на обработку, поэтому он может пытаться грубо форсировать любые данные в любом количестве, не беспокоясь о запрете IP-адреса / kicked ...

Вы должны хранить только такие вещи, как имя пользователя, которое нужно запомнить, или идентификатор сеанса.

2
ответ дан 18 December 2019 в 05:48
поделиться

Если вы абсолютно ДОЛЖНЫ хранить информацию в cookie вместо сессии пользователя, рассмотрите возможность подписания ее с помощью HMAC. Функция hash_hmac является встроенной в современные версии PHP.

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

0
ответ дан 18 December 2019 в 05:48
поделиться

Вы получаете сеансы бесплатно! Это данные, хранящиеся на стороне сервера, которые автоматически обрабатываются PHP / выбранной вами структурой. Вы просто помещаете данные в сеанс, который связан со случайным UID, хранящимся в сеансах клиентов. На стороне клиентов это файл cookie сеанса. Этот идентификатор создается автоматически, вы можете настроить поведение вручную .

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

0
ответ дан 18 December 2019 в 05:48
поделиться

У Аарона Харуна есть правильный ответ. По сути, нет необходимости шифровать такие данные, пока вы храните их в сеансе, потому что эти данные никогда не достигают клиента / браузера / пользователя, поскольку все они находятся на стороне сервера. Когда вы создаете сеанс на PHP, он обрабатывает файлы cookie за вас, поэтому вам не о чем беспокоиться. В большинстве случаев иметь дело с файлами cookie не нужно. С точки зрения безопасности работа с файлами cookie вредна.

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

Если вы действительно думаете, что разработать самодельную систему аутентификации - хорошая идея, вам нужно сперва спроектировать базу данных. Не храните пароли в виде обычного текста, вместо этого храните хеш (например, md5, sha-1 и т. Д.), И в этот момент нет вреда в создании соли для каждого пароля (случайная строка, которую вы добавляете к паролю пользователя перед его хешированием, и сохраните эту соль с хешем пароля, потому что он вам понадобится позже - это предотвращает атаки хеш-словаря, то есть радужные таблицы).

4
ответ дан 18 December 2019 в 05:48
поделиться
Другие вопросы по тегам:

Похожие вопросы: