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

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

Сохранять пароль в cookie не является безопасным способом для этого, так что мой вопрос: Каков правильный способ сделать (войти/оставить пользователя вошедшим в систему) на моем веб-сайте?

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

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

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

Только PHP. Два месяца в php, все узнали из ваших ответов. Благодаря

Ответ 1

Во-первых, позвольте мне рассказать вам об этом. Ничто не защищено на 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.

Ответ 2

Я бы использовал сеанс.

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

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

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

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

Ответ 3

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

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

Ответ 4

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

Пользовательские данные в файлах cookie vs Session

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

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

Ответ 5

Лучшей практикой является использование сеансов PHP.

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

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

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

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

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

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