Какой правильный и безопасный / безопасный способ сохранить пользователя вошел в систему? печенье? сессия? PHP && MYSQL

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

Хранить пароль в cookie-файле не является безопасным способом сделать это, поэтому мой вопрос: как правильно сделать (войти / оставить пользователя в системе) на моем веб-сайте?

В настоящее время я храню идентификатор пользователя, который соответствует URL-адресу, необходимому для отображения профиля пользователя X, а также адрес электронной почты и пароль, зашифрованные в MD5.

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

& # X2022; Можете ли вы показать мне, как правильно и безопасно это сделать?
& # X2022; Как ты это делаешь?

Только PHP Два месяца в php, все узнали из твоих ответов. Спасибо

 Flukey12 мая 2012 г., 22:05
Я не понимаю. почему вы храните пароль в куки? Используйте сеансы, а не куки. Просто сохраните логическое значение в переменной сеанса, чтобы проверить, вошел ли пользователь в систему или нет.
 Flukey13 мая 2012 г., 00:12
@ Правда - да. Я знаю это. Я не говорил ему хранить пароль в сесси
 caw21 сент. 2016 г., 04:26
Вам следует по возможности повторно использовать существующую структуру аутентификации. Например, посмотрите на Github.com / наслаждение-им / PHP-Auth
 Madara Uchiha♦12 мая 2012 г., 22:32
@ Flukey: идентификатор сессии обычно передается через cookie. Он может быть украден так же, как и файл cookie с паролем, и злоумышленник войдет в систему как вы, даже не вводя свой пароль.

Ответы на вопрос(5)

позволь мне сказать тебе это. Ничто не на 100% безопасно. Ничто не является воздухонепроницаемым, и ничто не является священным. При наличии достаточной мотивации злоумышленник сломает каждую защиту на стороне сервера, которую вы можете поставить (если только вы не используете HTTPS, а это другая история).

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

Sessions также не безопасны на 100%. Идентификатор сеанса, который сервер использует для идентификации клиента, отправляется одним из двух способов. переменная $ _GET (плохо) или cookie (лучше, но все же довольно плохо). Это означает, что если вы вошли в систему как администратор по незащищенному Wi-Fi, опытный злоумышленник (и я имею в виду pr0 haxx0r, который скачал простой сниффер HTTP) может легко украсть ваш идентификатор SESSION. И хотя ваш пароль не будет получен, сервер ошибочно идентифицирует злоумышленника как вас и предоставит ему любой доступ, который у вас может быть / бы

Так что делать? Сессии в большинстве случаев безопасны. Посоветуйте своим пользователям не входить в незащищенную сеть (автобусы, интернет-кафе и т. Д.). Если вы хотите, чтобы авторизация пользователя сохранялась в течение долгого времени, требуется файл cookie. Я обычно использую систему 2 cookie, если мне это нужно:

userid=12345
hash=password_hash($userid . $hashed_password, PASSWORD_DEFAULT)

Тогда мне есть с чем сравнивать, а данные пользователя не разглашаются.

Но, как я уже сказал, в конце дня, если вы действительно ДЕЙСТВИТЕЛЬНО хотели защитить своих пользователей, помимо всего прочего, написанного в этом ответе, получите себе HTTPS.

 Jay Jee24 янв. 2019 г., 16:17
Я исследую ту же тему, что и выше. Что-то, что я нахожу очень важным, это то, что идентификатор сессии хранится в незащищенном файле cookie браузера. Идентификатор сеанса можно изменить с помощью session_name () (полезно для отключения хакеров), и этот файл cookie можно сделать безопасным файлом cookie через HTTPS только с помощью session_set_cookie_params ().
 Madara Uchiha♦16 дек. 2016 г., 10:04
@ RishirajPurohit Смотрите Letsencrypt.org
 Rishiraj Purohit10 нояб. 2015 г., 16:32
очень хороший ответ, не могли бы вы сказать что-то подобное выше для https. Я хотел бы прочитать это. Вы только что научили меня многому в одном ответе. если только я могу получить некоторую информацию о https, я буду очень благодарен. ссылка возможно. ?

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

НЕ ХРАНИТЕ какую-либо информацию в сеансе, касающуюся доступа к учетным данным - идентификатор пользователя часто бывает достаточным; лично я создаю пользовательский объект, который я храню в сеансе (они автоматически сериализуются / не сериализуются между запросами - но вы можете читать об этом независимо).

Если вы хотите установить cookie-файл, чтобы пользователю не приходилось входить в систему при следующем посещении, возможно, сохраните userId и автоматически сгенерированный токен, который можно проверить в базе данных (или аналогичный) - я бы тоже добавил дополнения к проверке - например, сохранить последний ipaddress с токеном, чтобы проверить, не совпадают ли они, а затем запросить логин еще раз.

Существует немало подходов, которые можно использовать - я не предлагаю все / «лучшее» - пересмотреть свой код людьми в сообществе php - вы узнаете больше таким образом.

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

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

 Thomas Williams22 сент. 2016 г., 01:26
даже если cookie-файл зашифрован, ничто не мешает кому-либо украсть cookie-файл и использовать его для входа в систему. Если у него есть доступ к компьютеру, это все равно, что оставить свой пароль на компьютере

что ничто не является на 100% безопасным и правильным, но, с точки зрения разработчика, я бы сказал, что каждый метод хранения данных сеанса пользователя имеет свои преимущества и недостатки, например.

Данные пользователя в файлах cookie и сессии

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

На последнем замечании: Оба способа верны в своей собственной реализации, также, если ваше приложение использует протокол HTTPS, безопасность не должна быть проблемой. поэтому я бы предложил использовать методы сохранения данных сеанса пользователя в соответствии с требованиями приложения и бизнес-модели.

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

Альтернативный метод использования сессия печенья означает включение идентификатора сеанса PHP в URL-адрес запроса как переменную GET. Пример URL может выглядеть примерно так:

https://www.example.com/mypage.php?PHPSESSID=cteekbf64igp5vdjjkktvoeb97

Это не так безопасно, как использование куки, потому что URL может случайно быть передан или украден другими способами.

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

Для меня базовый уровень будет состоять в том, чтобы использовать сеансы PHP с идентификатором сеанса, который должен быть в файлах cookie (блокировать пользователей, которые отключают файлы cookie), шифрование SSL все время, как для данных, так и для файлов cookie, и проверять различные настройки PHP. которые влияют на безопасность сеансов, устанавливаются на самые лучшие и самые безопасные параметры. Вы хотите прочитать все на этих страницах и дочерних страницах:

http: //php.net/manual/en/intro.session.phhttp: //php.net/manual/en/session.security.ph

Ваш ответ на вопрос