Сохранение идентификатора пользователя и пароля в файле cookie для автоматического входа? Является ли аутентификация типа vBulletin приемлемой?

Question

Я настраиваю систему учетных записей пользователей на своем веб-сайте. Консенсус SO, похоже, отражен в этом вопросе / статье SO . Он рекомендует этот подход Чарльза Миллера для хранения имени пользователя и большого случайного числа 1) в файле cookie и 2) в отдельной таблице в БД. Пользователь может проходить повторную проверку подлинности в каждом последующем сеансе, запрашивая эту таблицу с помощью файла cookie (если он существует). Если совпадение найдено, то для этого сеанса устанавливается новый $_SESSION. Поддерживает одновременный вход с разных компьютеров.

Мой вопрос ...

До прочтения вопросов безопасности в SO я думал о том, чтобы хранить информацию о пользователе способом, подобным тому, как это делает vBulletin. Насколько я понимаю, они хранят идентификатор пользователя и хешированный пароль в отдельных файлах cookie в браузере пользователя.

После входа в систему пользователь использует переменную $_SESSION (например, что-то вроде $_SESSION['user_hash']), чтобы поддерживать аутентификацию для каждого запроса страницы. У меня нет доступа к программному обеспечению vBulletin, но я предполагаю, что $_SESSION['user_hash'] поддерживается в отдельной таблице MySQL вместе с другой частью идентифицирующей информации - например, идентификатор пользователя / хэш пароля / другое - для включения входа с разных компьютеров.

Я думал о создании хеша, выполняя это:

$_SESSION['user_hash'] = $random_hash = sha1(uniqid(rand(), true));

Для будущих сеансов, если $_SESSION['user_hash'] не существует, эти два файла cookie можно использовать для автоматического входа этого человека в новый сеанс. Я планирую реализовать меры безопасности $_SESSION, изложенные в этом SO вопросе .

Является ли подход vBulletin приемлемым с точки зрения безопасности? Если хранение идентификатора пользователя и хешированного пароля в файле cookie является проблематичным, поможет ли их шифрование устранить некоторые проблемы безопасности? Или что-то еще можно сделать, чтобы обезопасить куки?

Спасибо за любые предложения.

Answer 1

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

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