Позже я спрашивал, как правильно выйти из системы, теперь я вижу, что использование только файлов cookie для входа пользователя в систему не является безопасным вообще.
Сохранять пароль в файле cookie не является безопасным способом для этого, поэтому мой вопрос: каков правильный способ сделать (войти / оставить пользователя вошедшим в систему) на моем веб-сайте?
В настоящее время я сохраняю идентификатор пользователя, который является тем же самым, что и url, для отображения профиля пользователя X, а также пароля и пароля, зашифрованного в MD5.
Setcookie – единственная функция, которую я использую при успешном входе в систему. Я использую сеансы для хранения случайных чисел, чтобы избежать повторных представлений формы. скрытые поля.
• Можете ли вы показать мне, как правильно и безопасно это сделать?
• Как вы это делаете?
Только PHP. Два месяца в php, все узнали из ваших ответов. благодаря
Во-первых, позвольте мне рассказать вам об этом. Ничто не защищено на 100%. Ничто не является воздушным, и ничто не является священным. Если он достаточно мотивирован, злоумышленник разорвет любую защиту на стороне сервера, которую вы можете поставить (если вы не используете HTTPS, это другая история).
Вы можете использовать файлы cookie, но файлы cookie очень подвержены действию и легко изменяются. Никогда не храните личные данные или уровни доступа в cookie. Так как он легко украден / изменен злоумышленником.
Сессии также не на 100% безопасны. Идентификатор сеанса, который сервер использует для идентификации клиента, отправляется одним из двух способов. переменная $ _GET (плохая) или cookie (лучше, но все же довольно плохо). Смысл, если вы вошли в систему как администратор, через незащищенный WiFi, квалифицированный злоумышленник (и квалифицированным я имею в виду pr0 haxx0r, который загрузил простой сниффер HTTP), может легко украсть ваш идентификатор SESSION. И, не получая ваш пароль, сервер неправильно идентифицирует злоумышленника, как вы, и предоставит ему любой доступ, который у вас есть / имел.
Так что делать? Сессии в большинстве случаев безопасны. Советуйте своим пользователям не входить в систему в незащищенной сети (автобусы, интернет-кафе и т. Д.). Если вы хотите, чтобы ваше разрешение пользователя сохранялось с течением времени, требуется файл cookie. Обычно я использую 2 системы cookie, если мне это нужно:
userid=12345 hash=$userid . $password . $user_specific_random_pregenerated_salt Тогда у меня есть что-то, что можно было бы противопоставить, и детали пользователя не были раскрыты.
Но, как я уже сказал, в конце дня, если вы действительно ДЕЙСТВИТЕЛЬНО захотите защитить своих пользователей, выше всех остальных, написанных в этом ответе, получите HTTPS.
Я бы использовал сеанс.
Чтобы немного помочь в безопасности, после проверки учетных данных пользователей используйте session_regenerate_id – поскольку идентификатор сеанса – это то, что передается в cookie, это важно, если кто-то обнюхивает во время обработки входа в систему.
НЕ ЗАПУСКАЙТЕ любую информацию в сеансе, относящуюся к учетным данным доступа – часто бывает достаточно идентификатора пользователя; лично я создаю пользовательский объект, который я храню в сеансе (они автоматически сериализуются / неэтериализируются между запросами, но вы можете читать об этом независимо).
Если вы хотите установить cookie, чтобы пользователь не мог войти в следующий визит, возможно, сохраните userId и автогенерированный токен, который можно проверить в базе данных (или аналогичной) – я бы добавил дополнительные функции для проверки – например, хранить последний ipaddress с токеном, чтобы проверить, если они не совпадают, а затем попросить логин еще раз.
Существует множество подходов, которые можно предпринять – я не предлагаю всех / «лучших» – узнайте, как ваш код просматривается людьми в сообществе php – вы узнаете больше.
Если у человека есть логин и пароль, это может быть установлено как файл cookie в браузере, поэтому им не нужно повторно заходить на ваш сайт каждый раз, когда они посещают. Вы можете хранить почти все в cookie браузера. Проблема в том, что пользователь может заблокировать файлы cookie или удалить их в любое время. Если, например, в корзине покупок вашего веб-сайта использовались файлы cookie, и у человека был установлен их браузер, чтобы блокировать их, тогда они не могли делать покупки на вашем сайте.
Когда вы храните данные в файлах cookie, вы должны быть абсолютно уверены, что пользователи не могут каким-либо образом изменять данные. Невозможно заставить пользователей изменять данные в файле cookie; это абсурдно легко. Таким образом, чтобы ваш веб-сайт не принимал файлы cookie, содержащие измененные данные, вам необходимо либо зашифровать значения cookie, либо подписать их хешем, который позволяет проверить их целостность.
Поскольку @Madara заявила, что ничего не на 100% безопасно и правильно, но как точка зрения разработчика, я бы сказал, что каждый способ сохранения данных сеанса пользователя имеет свои собственные преимущества и недостатки, например.
Данные пользователя в файлах cookie vs Session
Если вы сохраняете данные сеанса пользователя в файлах cookie, они будут потреблять меньше памяти и обработки ОЗУ сервера, потому что вам не нужно записывать информацию пользователя в оперативную память. также если пользователь увеличивается, то рекомендуется сохранить данные сеанса пользователя в файлах cookie, а не в сеансе, потому что сохранение в сеансе потребует ресурсов сервера, и ваше приложение может быть медленнее и не реагировать когда-нибудь. где, как если бы вы сохраняли данные пользователя во время сеанса, он был бы безопасен, чем файлы cookie, но он потреблял бы больше ресурсов сервера.
В заключение : оба пути правильны в своей собственной реализации, также если ваше приложение использует протокол HTTPS, то безопасность не должна быть проблемой. поэтому я бы предложил использовать методы хранения данных сеанса пользователя в соответствии с требованиями приложения и бизнес-модели.
Лучшей практикой является использование сеансов PHP.
Сессия PHP поддерживается тем, что браузер возвращает криптографически безопасную (то есть не догадывающуюся о следующей допустимой величине) строку, известную как идентификатор сеанса, каждый раз, когда он делает запрос во время этого сеанса. Лучший и безопасный способ сделать это – предоставить браузеру cookie сеанса , который затем будет отправляться с каждым запросом.
Альтернативным методом использования cookie сеанса является включение идентификатора сеанса PHP в URL-адрес запроса как переменной GET. Пример URL-адреса может выглядеть примерно так:
https://www.example.com/mypage.php?PHPSESSID=cteekbf64igp5vdjjkktvoeb97
Это не так безопасно, как использование файла cookie, потому что URL-адрес может случайно получить общий или украденный с помощью других средств.
Безопасность многослойна, как лук (как показывает общий пример). Чем безопаснее вы что-то делаете, тем больше усилий требуется для обеспечения безопасности и тем менее удобно использовать. Это компромисс. Поэтому вы должны спросить, насколько важны ваши данные, конфиденциальность и безопасность вашего пользователя и т. Д.
Для меня базовым уровнем будет использование сеансов PHP с идентификатором сеанса, который должен быть включен в файлы cookie (блокировать пользователей, которые отключают файлы cookie), SSL-шифрование все время, как по данным, так и по файлам cookie, и следить за тем, чтобы различные настройки PHP, которые влияют на безопасность сеансов, настроены на самые лучшие, самые безопасные настройки. Вы захотите прочитать все на этих страницах и дочерних страницах: