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

Question

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

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

И на каждой странице веб-сайта, я бы преформ простой проверки

isset($_SESSION['uid']); 

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

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

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

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

Спасибо.

Answer 1

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

---

Я имел дело с системами Войти/аутентификации ранее, и я нахожу некоторые недостатки в этом методе:

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

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

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

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

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

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

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

Answer 2

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

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

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

Вот несколько ресурсов, чтобы посмотреть на

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

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

Answer 3

Там нет ничего плохого делать это

isset($_SESSION['uid']); 

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

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

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

Answer 4

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

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