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

Question

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

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

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

Answer 1

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

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

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

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

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

хеширование

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

Answer 2

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

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

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

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

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

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

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

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

Answer 3

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

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

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

Answer 4

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

Answer 5

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

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

Answer 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 в вашей странице выхода из системы

<?php

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

?>

вот и все