В настоящее время я настраиваю систему аутентификации. Мой текущий макет – получить его электронную почту от $_POST , md5 его пароль и проверить базу данных на его электронную почту и его пароль. Если он совпадает, я использую session_start , и я начинаю хранить данные в переменной $_SESSION , например:
$_SESSION['uid'] = $uid; $_SESSION['first_name'] = $first_name;
И на каждой странице веб-сайта я бы выполнил простую проверку
isset($_SESSION['uid']);
если нет, перенаправляйте на страницу индекса, если есть, загрузите страницу.
Правильно ли я делаю это? Это достаточно безопасно? Насколько легко кому-то подделывать эти данные?
Кто-то сказал мне, что я должен создать таблицу с электронной почтой пользователя и его идентификатор сеанса и использовать это для управления вещами … Я немного запутался – как это поможет?
Может ли кто-нибудь прояснить это? Каков правильный способ управления аутентификацией с помощью сеансов PHP?
Благодарю.
Обновление безопасности : по состоянию на 2017-10-23: Совет в этом ответе, хотя и имеет историческое значение, совершенно небезопасен. Нельзя использовать md5 в хешировании пароля, потому что он настолько грубо принудительно. См. Этот ответ о том, как использовать встроенный пароль_ * api для хэша и проверять пароли.
Раньше я занимался системами входа / аутентификации, и я обнаружил несколько недостатков в этом методе:
ДОБАВЛЕНИЕ (19 сентября 2015 г.) * Посмотрите на эту ссылку . В нем объясняются все основы, подходы, которые вы можете предпринять, почему вы должны использовать эти подходы, а также дает образец кода PHP. Если это слишком долго, чтобы читать, просто идите до конца, возьмите код и установите его!
ЛУЧШИЙ ПОДХОД : хранить md5 имени username+password+email+salt в базе данных, соль случайна и храниться вместе с записью пользователя.
ЛУЧШИЙ ПОДХОД : для генерации случайного сеанса, когда пользователь входит в систему успешно и сохраняет этот идентификатор сеанса в $_SESSION[] . Вам также необходимо связать sessionid с его uid (используя базу данных или memcached). Преимущества:
EDIT: Я всегда использовал файлы cookie вручную для обработки сеансов. Это помогает мне легче интегрировать javascript-компоненты моих веб-приложений. Возможно, вам понадобится то же самое в ваших приложениях, в будущем.
Нет ничего плохого в этом
isset($_SESSION['uid']);
Данные сеанса не передаются пользователю, они хранятся на сервере (или где хранитель сеанса хранит его). То, что передается пользователю, – это идентификатор сеанса, который является просто случайной строкой, генерируемой PHP, это может быть украдено, конечно, потому что оно отправлено пользователю.
Следует четко отметить, что случайное хранение строки в базе данных и сеансе пользователей, а затем ее использование для идентификации пользователя не делает сеанс более безопасным, если злоумышленник получает сеанс, он все равно будет скомпрометировать пользователя.
То, что мы обсуждаем сейчас, это захват сеанса , возможно, вы думаете, что можете просто сохранить IP-адрес в сеансе и проверить, что IP-адрес поступает из запроса и выполняется с ним. Однако часто это не так просто, я обжегся этим недавно, когда в большом веб-приложении мы хранили хэш-адрес User Agent + IP-адреса в сеансе, а затем проверяли, что они соответствуют каждому случаю, для 99% пользователей это сработало хорошо. Тем не менее, мы начали получать звонки от людей, которые обнаружили, что они постоянно выходят из системы без объяснения причин. Мы помещаем регистрацию на проверку захвата сеанса, чтобы узнать, что происходит, и обнаружили, что эти люди войдут в один IP-адрес, и их сеанс продолжится по другому, это не попытка захвата, но это было связано с тем, как их прокси-сервер в результате мы внесли поправки в код захвата сессии, чтобы узнать класс IP-адреса, а оттуда выяснить сетевую часть IP-адреса и сохранить только те части IP-адреса, это немного менее безопасно в этом захвате сеанса теоретически может возникнуть из одной сети, но все наши ложные срабатывания ушли.
Я должен добавить к этому. Если вы используете метод «MD5 пароль, затем проверьте базу данных», это говорит о том, что пароль хранится в одном хэш-файле md5. Это уже не стандартный способ хранения хэшированных паролей.
Я нашел эту ссылку очень информативной: http://www.itnewb.com/tutorial/Encrypting-Passwords-with-PHP-for-Storage-Using-the-RSA-PBKDF2-Standard
Я не на 100% на это, но я думаю, что можно подделать сессию, если кто-то действительно захотел!
Я думаю, что сохранение идентификатора сеанса в таблице является самым безопасным способом для этого.
Я изучил это немного недавно, но опять же не уверен, интересно узнать, что лучше всего!
Вот несколько ресурсов для