Каков наилучший способ сделать аутентификацию пользователя в php?

использовать сеансы . Сохраните идентификатор сеанса в файле cookie и сохраните состояние пользователя на стороне сервера (loggedIn, userId, IP).

Чтобы выяснить, что вам нужно сохранить в массиве сеанса:

• loggedIn: Логическая переменная о том, вошел ли пользователь в систему или нет. Вы повторно используете один и тот же файл cookie для нескольких сеансов, поэтому вы помните имя пользователя в следующий раз, когда приходят на ваш сайт и т. Д.
• userId: идентификатор uniqe пользователя в базе данных. Используйте это, чтобы получить больше информации о пользователе, например, имя пользователя, адрес электронной почты и т. Д. Это также можно сохранить в массиве сеансов после выхода пользователя из системы.
• IP: Чтобы кто-то не украл идентификатор сеанса и не использовал его, вы также храните IP-адрес пользователя. Это необязательно, поскольку иногда вы хотите разрешить пользователю перемещаться (например, stackoverflow позволяет мне перемещаться с моим ноутбуком, не выбирая меня, когда меняется IP-адрес).
• lastPing: отметка времени, в которой пользователь был в последний раз замечен. Это можно использовать вместо даты истечения срока действия файла cookie. Если вы также сохраняете время жизни сеанса, вы можете вывести пользователя из системы из-за неактивности. Это означает, что cookie идентификатора сеанса может храниться на компьютере пользователя в течение очень долгого времени.

Когда пользователь выходит из системы или выходит из системы из-за неактивности, вы просто устанавливаете loggedIn в false. Когда пользователь входит в систему с правильным именем пользователя и паролем, вы устанавливаете loggedIn в true и обновляете другие поля (userId, IP, lifetime). Когда пользователь загружает страницу, вы проверяете lastPing на текущее время и время lifetime , а также обновляете lastPing или lastPing из системы пользователем.

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

хеширования

повторное использование значения несколько раз не является хорошей идеей, потому что вы уменьшаете безопасность . Вместо этого используйте соль, комбинируя статическую соль (имя страницы, например) и имя пользователя пользователя вместе с паролем. Хэш, который занимает много времени, не лучше, чем быстрый хеш, хэш, который приводит к большому дайджесту, лучше, чем хэш, что приводит к краткому перевариванию (из-за грубой силы). Использование SHA1 должно быть достаточно хорошим для обычного сайта (IE, а не банка или секретной военной организации).

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

Лучшим решением является использование механизма сеанса PHP и вызов session_regenerate_id по каждому запросу для постоянного обновления токена. Это делает захват сеанса практически невозможным, особенно по SSL-соединению с ограничением IP-адреса / диапазона.

В настоящее время я делаю 0 вызовов БД (за исключением логинов или когда что-то меняется) для зарегистрированных пользователей. Я хотел, чтобы это было так … – Егор 7 мин назад

Данные сеанса PHP хранятся в файловой системе по умолчанию, поэтому вы не будете делать дополнительные вызовы БД с помощью встроенного механизма сеанса.

Кроме того, есть ли смысл использовать «трудно вычислить хэши»? Под этим я подразумеваю, используя bcrypt или хэшируя каждый элемент в 10 000 раз с помощью вихря, чтобы сделать его (относительно) медленной хэш-функцией (200 мс против менее 1 мс только простой SHA1)?

Хеширование строки 10 000 раз не делает ее в 10 000 раз более безопасной, чем хэширование ее один раз. Хеш один раз с хорошим односторонним шифрованием, таким как SHA1 или Whirlpool.

Я имею в виду, что если кто-то нарушает вашу БД и получает хэши … что остается, чтобы защитить, так как все ваши данные находятся в одной и той же БД (если у вас нет какой-то децентрализованной установки, которой я не занимаюсь).

Хеши паролей солей защищают их от атак с радужным столом . В настоящее время очень сложно, если не невозможно взломать соленые пароли с радужным столом.

Если вы хотите реализовать функциональность «помнить меня» для вашего сайта, допустим сохранение идентификатора пользователя в cookie.

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

Спросите себя, насколько строги ваши требования безопасности, чтобы определить, насколько это будет сложно или нет. Я использую Zend_Auth & Zend_Acl для обработки аутентификации / авторизации в своих php-приложениях. Если вы в настоящее время используете фреймворк, вы можете найти его для рекомендуемых рекомендаций. Даже если вы не используете фреймворк, вы можете искать другие сайты / приложения, чтобы почувствовать его. Это связано с чем-то большим, чем когда речь заходит об использовании https для входа / всего и всего входа в сеансы, только для файлов cookie и т. Д.

Есть несколько способов сделать это. Я не собираюсь углубляться, потому что на эту тему много литературы.

• Прежде всего, лучше использовать что-то вроде SHA256 чтобы уменьшить вероятность столкновения.
• Вы также должны использовать соление или двойное соление с одной переменной солью (например, IP – для предотвращения сеансов кражи). Строка файла cookie будет выглядеть как YOURSALT123.123.123.123USERNAMEPASSWORD перед тем, как быть хэшированной.
• Используйте сеансы в сочетании с вашими собственными файлами cookie.
• В зависимости от ваших требований безопасности используйте SSL.

Все зависит от того, насколько вы безопасны. Веб-сайт сообщества о lolcats имеет разные требования безопасности по сравнению с банковским сайтом.

это лучший способ и самый простой способ

step1 на странице входа / индекса введите этот код

 <?php if(check if username and password is correct) { header('location:home.php'); $_SESSION['logged']=true; } else { header('location:index.php'); } ?> 

шаг 2 на вашей странице, которую вы хотите аутентифицировать

 <?php if(isset($_SESSION['logged'])) { ?> your page content here <?php } else { header('location:index.php'); ?> 

step3 в вашей logoutpage

 <?php session_start(); session_destroy(); header('Location:index.php'); ?> 

это все