Правильный способ управления сеансами в PHP?

В настоящее время я настраиваю систему аутентификации. Мой текущий макет - получить его электронную почту с $_POST, md5 его пароль и проверить базу данных на его электронную почту и пароль. Если он совпадает, я использую session_start, и я начинаю хранить данные в переменной $_SESSION, например:

 $_SESSION['uid'] = $uid;
 $_SESSION['first_name'] = $first_name;

И на каждой странице веб-сайта я бы выполнил простую проверку

isset($_SESSION['uid']);

если нет, перенаправляйте на страницу индекса, если есть, загрузите страницу.

Я делаю это правильно? Это достаточно безопасно? Насколько легко кому-то подделывать эти данные?

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

Может ли кто-нибудь прояснить это? Каков правильный способ управления аутентификацией с сеансами PHP?

Спасибо.

Ответ 1

Обновление безопасности: по состоянию на 2017-10-23: совет в этом ответе, хотя и имеет историческое значение, совершенно небезопасен. Нельзя использовать md5 в хешировании пароля, потому что он настолько грубо принудительно. См. этот ответ о том, как использовать встроенный пароль_ * api для хеширования и проверки паролей.

Раньше я занимался системами входа/аутентификации, и я нашел несколько недостатков в этом методе:

вы "md5 его пароль и проверьте базу данных" - это означает, что если у человека есть доступ к базе данных, он может разобраться, кто имеет те же пароли!

ДОБАВЛЕНИЕ (19 сентября 2015 г.) * Посмотрите на ссылку . В нем объясняются все основы, подходы, которые вы можете предпринять, почему вы должны использовать эти подходы, а также дает образец кода PHP. Если это слишком долго, чтобы читать, просто перейдите в конец, возьмите код и установите его!

ЛУЧШИЙ ПОДХОД: для хранения md5 из username+password+email+salt в базе данных, соль является случайной и сохраняется вместе с записью пользователя.

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

ЛУЧШИЙ ПОДХОД: для генерации случайного сеанса, когда пользователь входит в систему успешно, и сохраните этот идентификатор сеанса в массиве $_SESSION[]. Вам также необходимо связать sessionid с его uid (используя базу данных или memcached). Преимущества:

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

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

Ответ 2

Нет ничего плохого в этом.

isset($_SESSION['uid']);

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

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

Теперь мы обсуждаем захват сеанса, возможно, вы думаете, что можете просто сохранить IP-адрес в сеансе и проверить, что с IP-адресом, исходящим от запроса, и с этим делать. Однако часто это не так просто, я обжегся этим недавно, когда в большом веб-приложении мы хранили хэш-адрес User Agent + IP-адрес в сеансе, а затем проверяли, что они соответствуют каждому случаю, для 99% пользователей это сработало хорошо. Тем не менее, мы начали получать звонки от людей, которые обнаружили, что они постоянно выходят из системы без объяснения причин. Мы помещаем регистрацию на проверку захвата сеанса, чтобы узнать, что происходит, и обнаружили, что эти люди войдут в один IP-адрес, и их сеанс продолжится по другому, это не попытка захвата, но это было связано с тем, как их прокси-сервер в результате мы внесли поправки в наш код захвата сессии, чтобы узнать класс IP-адреса и оттуда вывести сетевую часть IP-адреса и хранить только те части IP-адреса, это немного менее безопасно в том, что захват сеанса может теоретически исходить из одной сети, но все наши ложные срабатывания уходят.

Ответ 3

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

Я нашел эту ссылку очень информативной: http://www.itnewb.com/tutorial/Encrypting-Passwords-with-PHP-for-Storage-Using-the-RSA-PBKDF2-Standard

Ответ 4

Я не на 100% на это, но я думаю, что можно подделать сессию, если кто-то действительно захотел!

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

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

Вот несколько ресурсов для просмотра

http://www.sitepoint.com/article/php-security-blunders/

http://www.phpeasystep.com/workshopview.php?id=6