PHP Login System

Question

Я создаю систему входа для веб-приложения с использованием PHP. Мой вопрос: безопасно ли хранить только данные входа пользователя в текущий сеанс? Например, если пользователь с именем John регистрируется успешно на моем сайте, могу ли я просто сохранить $ _SESSION ['Username'] = 'John' и $ _SESSION ['LoggedIn'] = 1, а затем проверить, что $ _SESSION ['LoggedIn'] равна 1 на каждой странице, чтобы убедиться, что пользователь действительно зарегистрирован? Или есть лучший способ сделать это? Я не знаю о каких-либо проблемах, которые могут возникнуть у меня на голове, но я хотел убедиться, что я не оставляю большую дыру на моем сайте, что может вызвать проблемы в будущем.

Кроме того, я сохраняю хэш-адрес md5 пароля пользователя + соль в базе данных, а не их фактический строковый пароль, так что это меньше всего беспокоит.

Сообщите мне, если вам нужна дополнительная информация или если это неясно. Благодаря!

Answer 1

Это вполне разумный подход. Ваши посетители никогда не смогут редактировать данные сеанса на вашем сервере (если только сам сервер небезопасен, и в этом случае что-то справедливое), поэтому значение LoggedIn = 1 в сеансе совершенно безопасно.

Однако помните о том, что один посетитель захватывает сеанс другого (путем кражи ключа сеанса). Один из способов защиты от этого - также хранить IP-адрес посетителя (от $_SERVER['REMOTE_ADDR']) в сеансе, а затем в последующих запросах подтвердить, что он не изменился.

Answer 2

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

Answer 3

Рассмотрите SHA1 или еще более сильный хэш вместо MD5. Но ты это соляришь, это хорошо.

На ваш вопрос: да, это нормально. Однако примите меры, чтобы убедиться, что сеансы не захвачены. Википедия actually has a fairly good article on it.

В большинстве систем, которые я написал, я включил логику для проверки того, что удаленный IP-адрес не изменился. Вы также можете сохранить это в сеансе, поскольку сеанс vars не передается пользователю (только идентификатор сеанса). Если вы действительно хотите стать творческим, вы можете добавить другие проверки - user-agent, а что нет.

Вы также должны учитывать сеансовые атаки. Проверьте источники. Если у вас есть катастрофическая операция, давайте назовем ее POST для DeleteMyAccount, я могу написать отправку формы плюс javascript, чтобы нажать DeleteMyAccount в сообщении форума на несвязанном сайте, рассчитывая, что этот сеанс будет присутствовать в информации пользователя.

Answer 4

Есть целый ряд рисков для рассмотрения:

1. Сессия угон: это когда кто-то ворует куки пользователя и притворяется их. Некоторые будут предлагать фильтрацию IP для борьбы с этим, но это может иметь неприятные побочные эффекты. Люди используют веб-сайты с мобильных устройств или на ноутбуках, которые используются на работе, дома и в горячих точках Wi-Fi, и есть другие случаи, когда IP-адреса могут меняться. Поэтому мой совет делает это только для высоко чувствительных веб-сайтов (например, онлайн-банкинг);
2. Ваш сайт подвержен компрометации:, в этом случае у пользователя будет доступ к вашей базе данных в любом случае, поэтому нет никакого риска с сохранением информации аутентификации в сеансе.Они могут так же легко изменить, кто они, выпуская инструкции UPDATE в вашу базу данных;
3. Совместно размещенный сайт скомпрометирован: Если вы используете общий хостинг, совершенно несвязанный сайт может поставить вас под угрозу (с этой схемой или без этой схемы), потому что все узлы работают на одном экземпляре Apache и могут таким образом, доступ к файлам друг друга (хотя может быть сложно определить, на каком месте они принадлежат). Поэтому, если сайт, о котором вы никогда не слышали, взломан, он может повлиять на ваш сайт;
4. Со-Hosted сайт злонамерен: похоже на (3), за исключением того, что угроза внутренняя, но в остальном аналогична.

Поэтому я бы сказал, что это нормально (с учетом (2)), но просто знайте о рисках. Следуйте, как минимум, этим передовым методам:

1. Никогда не храните незашифрованные пароли;
2. Использовать сильный алгоритм хэширования (предпочтительнее SHA1 или MD5);
3. Убедитесь, что аутентификационные файлы cookie истекают в какой-то момент. Как долго зависит ваш сайт. Это может быть неделя или два или час или два бездействия или и то, и другое.

Answer 5

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

Кроме того, md5 больше не считается достаточно сильным для хэширования паролей: он слишком быстр для хэша, и вы не хотите, чтобы в проверке, что злоумышленнику нужно будет работать снова и снова (пока только реальный пользователь нужно сделать это один раз). Хотелось бы, чтобы я мог найти ссылку, но передовая мудрость заключается в том, чтобы делать много раундов алгоритма хэширования переднего края, например sha512.

Answer 6

Вы можете использовать COOKIE вместо переменной SESSION. вы можете установить COOKIE следующим образом:

setcookie ('ID', $ variable, time() + 8 * 60 * 60);

Вы должны знать о SQL-инъекции. Когда вы вставляете или обновляете свою базу данных, где связано текстовое поле пользователя, будьте в курсе SQL Injection. Вставьте/обновите свои значения функцией htmlentities().