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

Я просто написал 2 куки, 1, содержащий идентификатор пользователя, а второй - 1/2 хэш SH1 пароля (соленый). То, как это работает, самоочевидно.

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

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

ОТВЕТЫ

Ответ 1

используйте Sessions. Сохраните идентификатор сеанса в файле 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, либо выходите из системы.

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

хэширования

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

Ответ 2

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

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

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

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

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

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

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

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

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

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

Ответ 6

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

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');

?>

thats all