Как безопасно реализовать кнопку "Запомнить меня" в PHP (постоянный логин)

сначала некоторый фон, я все еще изучаю PHP и я пытаюсь построить CMS (отказ от ответственности: только для собственного использования).

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

Итак, прямо сейчас вот как это работает:

  • пользователь входит в систему, после проверки и дезинфекции входов, я проверяю, существует ли пользователь, и я использую PHPs password_verify чтобы сравнить пароль с хэшированным, хранящимся в ДЕЦИБЕЛ.

  • если вход в систему успешен, я перенаправляю администратора на dashboard.php и создайте переменную сеанса с именем adminId и я храню идентификатор пользователя в этой переменной.

вот мой первый вопрос:

может ли злоумышленник изменить значение $_SESSION['adminId']? Например, измените с 1 на 12 и, следовательно, войдите в систему как другой администратор?

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

Итак, если я не ошибаюсь,я должен использовать cookies для постоянного входа в систему?

Ok Итак, первое, что нужно никогда не хранить идентификатор пользователя в файле cookie и использовать его для проверки входа в систему, потому что злоумышленник может легко изменить это право?

отлично, так что я мог бы создать случайный маркер (С random_bytes, а затем преобразуется в hex) и соедините его с идентификатором пользователя в logins таблица в базе данных.

так, например, у меня есть это:

token: 2413e99262bfa13d5bf349b7f4c665ae2e79e357,
userId: 2

Итак, пользователь входит в систему, создается токен, хранится в базе данных с userId. Предположим, пользователь закрывает браузер. Затем он снова открывает его и все куки с токеном: 2413e99262bfa13d5bf349b7f4c665ae2e79e357. Поэтому автоматически регистрирует пользователя с userId: 2 Правильно?

если бы он хотел войти в систему как пользователь с userId: 10, например, ему нужно было бы знать случайный токен в паре с этим пользователем.

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

ниже приведена наша предлагаемая стратегия обработки файлов cookies" remember me " в веб-приложении без утечки какой-либо полезной информации (даже информации о времени) злоумышленнику, при этом оставаясь быстрым и эффективно (для предотвращения атак типа "отказ в обслуживании").

наша предлагаемая стратегия отклоняется от вышеуказанной простой системы автоматического входа на основе токенов одним решающим способом: вместо хранения случайного token в файле cookie, мы храним selector:validator.

selector уникальный ИД для того чтобы облегчить поиски базы данных, пока предотвращающ неизбежную информацию о времени от влиять на безопасность. (Это предпочтительнее, чем просто использовать базу данных id поле, которое просачивается количество активных пользователей в приложении.)

enter image description here

на стороне базы данных вещей,validator не хранится оптом; вместо этого хэш SHA-256 validator хранится в базе данных, в то время как открытый текст хранится (с selector) в файле cookie пользователя. С этим fail-safe на месте, если как-то auth_tokens таблица просочилась, немедленное широкое олицетворение пользователя предотвращено.

автоматический вход в систему алгоритм выглядит примерно так:

  1. отдельные selector С validator.
  2. захватить строку в auth_tokens для данного селектора. Если ничего не найдено, прервать.
  3. хэш-тег validator предоставлено файлом cookie пользователя с SHA-256.
  4. сравните хэш SHA-256, который мы создали, с хэшем, хранящимся в базе данных, используя hash_equals().
  5. если проходит Шаг 4, свяжите текущий сеанс с соответствующим идентификатором пользователя.

так вот чего я не понимаю:

1) Что должен selector и validator содержать?
2) Почему эта система безопасности и как она предотвращает утечки времени?

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

я знаю, что могу использовать некоторые рамки или библиотеку, но я хочу сделать это из scracth, узнать методом проб и ошибка!

1 ответов


может ли злоумышленник изменить значение $_SESSION['adminId']? Например, измените с 1 на 12 и, следовательно, войдите в систему как другой администратор?

нет. Данные сессии хранятся только на сервере. Клиент имеет только строку, которая идентифицирует сеанс.

Я должен использовать cookies для постоянного входа в систему?

если у вас будут постоянные логины, обычно это делается так.

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

правильно, вы никогда не захотите выставить какие-либо критические данные, такие как идентификатор пользователя.

1) Что должен selector и validator содержать?

каждый будет правильно сгенерированной случайной строкой (например, используя openssl_random_pseudo_bytes). The selector должен быть уникальным.

2) Почему это система безопасности и как она предотвращает утечки времени?

он добавляет две функции безопасности, генерируя один базовый токен и просматривая его напрямую.

во-первых, если ваша база данных просочилась к злоумышленнику, они не могут генерировать свои собственные файлы cookie remember me и олицетворять каждого пользователя. The validator хранится только в базе данных в виде хэша. Куки-файл должен содержать значение нехешированной. Реверсирование хорошего хэша-это чрезвычайно время всепоглощающий.

во-вторых, сравнение хэша, созданного только на сервере, позволяет избежать временных атак. Если злоумышленник должен был отправить различные значения cookie remember me во время их поиска, он не будет предоставлять ничего полезного, потому что сравнение на сервере против хэшированного значения, а не оригинала.

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