Пароли и аутентификация — бесплатный тест онлайн

Вопрос 1 из 30

Как получить значение для хранения, которое использует текущий рекомендуемый алгоритм PHP и затем проверяется через password_verify()?

$password = $_POST['password'] ?? '';

password_hash($password, PASSWORD_DEFAULT) hash_hmac('sha256', $password, $pepper) hash('sha256', $password) base64_encode($password) openssl_encrypt($password, 'aes-256-gcm', $key)

Вопрос 2 из 30

Нужно ли хранить соль в отдельном столбце?

$first = password_hash('same password', PASSWORD_DEFAULT);
$second = password_hash('same password', PASSWORD_DEFAULT);
var_dump($first !== $second);

Да, иначе два одинаковых пароля всегда дадут одинаковый хеш Нет, потому что современный алгоритм вообще не использует соль Нет, но соль необходимо вычислять детерминированно из user_id Нет, password_hash включает случайную соль и параметры в строку хеша Да, соль нужно хранить отдельно и добавлять к паролю перед password_verify

Вопрос 3 из 30

Почему столбец хеша делают с запасом, например varchar(255)?

CREATE TABLE users (
  id BIGINT PRIMARY KEY,
  password_hash VARCHAR(255) NOT NULL
);

Потому что password_verify дописывает служебные данные при каждом входе Потому что bcrypt всегда возвращает строку ровно из 255 символов Чтобы в том же поле можно было хранить исходный пароль при восстановлении Чтобы база могла сортировать пользователей по сложности пароля Формат и длина PASSWORD_DEFAULT могут измениться при переходе на новый алгоритм

Вопрос 4 из 30

Что произойдёт для одинакового пароля при двух вызовах?

$a=password_hash('secret',PASSWORD_DEFAULT);
$b=password_hash('secret',PASSWORD_DEFAULT);
var_dump($a!==$b,password_verify('secret',$a),password_verify('secret',$b));

Получатся разные хеши из-за случайной соли, оба пройдут verify Первый хеш пройдёт verify, а второй будет считаться устаревшим Второй вызов вернёт false из-за повторного использования того же пароля Получится одинаковая строка, поскольку пароль и алгоритм не менялись Один из хешей можно будет преобразовать обратно в пароль с помощью соли

Вопрос 5 из 30

Почему быстрый SHA-256 без KDF слаб для паролей?

Перебор кандидатов выполняется слишком быстро на специализированном оборудовании SHA-256 слаб только из-за короткой длины результата, а не скорости вычисления Добавление постоянной соли полностью устраняет возможность перебора Быстрый хеш подходит, если пароль сравнивается через hash_equals Хеш становится безопасным, если применить SHA-256 два раза

Вопрос 6 из 30

Как сравнивать введённый пароль с сохранённым хешем?

if (!password_verify($password, $user->passwordHash)) {
    throw new AuthenticationFailed();
}

md5($password)===$hash $hash === password_hash($password, PASSWORD_DEFAULT) decrypt($hash)===$password password_verify($password, $hash) hash_equals($password,$hash)

Вопрос 7 из 30

Для чего password_needs_rehash?

if (password_verify($password, $hash)
    && password_needs_rehash($hash, PASSWORD_DEFAULT)) {
    $users->updatePasswordHash($userId, password_hash($password, PASSWORD_DEFAULT));
}

Удалить соль из старого хеша перед переходом на новый алгоритм Проверить пароль без password_verify, сравнив параметры хеша вручную Определить, совпадает ли введённый пароль с другим пользовательским хешем Восстановить исходный пароль и снова передать его в password_hash Понять, что после успешной проверки хеш стоит пересоздать с новыми параметрами

Вопрос 8 из 30

Почему ответ «пользователь не найден» нежелателен на форме входа?

$user = $users->findByEmail($email);
$valid = $user !== null && password_verify($password, $user->passwordHash);
if (!$valid) {
    throw new AuthenticationFailed('Неверные учётные данные');
}

Такой ответ опасен только для администраторов, но не для обычных форм входа Проблема исчезает, если адрес привести к нижнему регистру Разные ответы допустимы, если у обоих одинаковый HTTP-статус Он позволяет перечислять зарегистрированные адреса Перечисление невозможно, если запрос отправляется методом POST

Вопрос 9 из 30

Что делать для неизвестного email, чтобы не было сильной временной разницы?

Выполнить только hash_equals над адресом электронной почты Сразу вернуть ошибку до вычисления хеша, но добавить случайный sleep Всегда запускать password_hash введённого пароля вместо password_verify Выполнить password_verify против фиксированного безопасного фиктивного хеша Создать новый случайный хеш на каждом запросе и проверить пароль против него

Вопрос 10 из 30

Какой порядок корректен?

if($user && password_verify($password,$user->hash)){
 session_regenerate_id(true);
 $_SESSION['uid']=$user->id;
 if(password_needs_rehash($user->hash,PASSWORD_DEFAULT)) $repo->rehash($user->id,password_hash($password,PASSWORD_DEFAULT));
}

Проверить статус аккаунта до поиска пользователя, а rehash выполнить до verify Найти пользователя, verify, проверить статус, regenerate session ID, при нужде rehash Сравнить строку хеша оператором ===, затем вызвать password_verify для журнала Сделать rehash каждого сохранённого пароля при запуске приложения без входа пользователя Сначала создать сессию, затем проверить пароль и только после этого искать пользователя

Вопрос 11 из 30

Каким должен быть токен сброса?

$token = bin2hex(random_bytes(32));
$expiresAt = $clock->now()->modify('+30 minutes');

Коротким числовым кодом без ограничения попыток, чтобы упростить ввод Многоразовым до истечения срока, чтобы пользователь мог открыть ссылку несколько раз Криптографически случайным, одноразовым и достаточно длинным Предсказуемым из user_id и даты, чтобы токен можно было восстановить без хранения Равным текущему хешу пароля, поскольку он уже криптографически стойкий

Вопрос 12 из 30

Что хранить в базе?

$plainToken = bin2hex(random_bytes(32));
$storedHash = hash('sha256', $plainToken);
$resets->create($userId, $storedHash, $expiresAt);

Только email и время создания: токен восстановится из них детерминированно Текущий хеш пароля как значение токена сброса Только флаг active без связи с пользователем и без одноразового состояния Сам токен в открытом виде без срока, чтобы его можно было повторно отправить Хеш токена, срок жизни и состояние использования

Вопрос 13 из 30

Как обеспечить одноразовость при двух одновременных запросах?

$stmt = $pdo->prepare(
    'UPDATE password_resets SET used_at = NOW() '
    . 'WHERE token_hash = :hash AND used_at IS NULL AND expires_at > NOW()'
);
$stmt->execute(['hash' => $tokenHash]);
if ($stmt->rowCount() !== 1) throw new InvalidToken();

Сначала прочитать unused, затем отдельным запросом пометить использованным без условия Атомарно обновить запись только если unused и expires_at>now, затем проверить число изменённых строк Разрешить оба запроса и считать последний записанный пароль итоговым Удалить токен после отправки ответа, не проверяя результат конкурентного UPDATE Заблокировать только строку пользователя, но не запись конкретного токена

Вопрос 14 из 30

Почему токен не стоит передавать сторонним ресурсам через Referer?

Referer всегда содержит только домен, поэтому секрет не может утечь Достаточно применить urlencode к токену, чтобы сторонний сервер не смог его использовать Утечка неопасна, если токен ещё не был открыт самим пользователем Он является временным секретом и может дать сменить пароль Проблема существует лишь для HTTP; при HTTPS полный URL безопасно передаётся всем ресурсам

Вопрос 15 из 30

Что сделать после успешного сброса?

Отправить новый пароль пользователю в URL уведомления для подтверждения Оставить прежние сессии действительными, потому что сброс касается только пароля Сбросить только cookie текущего браузера, не меняя серверное состояние других сессий Сохранить токен до конца срока, чтобы ссылка оставалась удобной при повторном открытии Отозвать/обновить существующие сессии, отметить токен использованным и уведомить пользователя

Вопрос 16 из 30

Почему session_regenerate_id(true) нужна после входа?

session_start();
if ($auth->verify($email, $password)) {
    session_regenerate_id(true);
    $_SESSION['user_id'] = $auth->userId();
}

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

Вопрос 17 из 30

Как реализовать «выйти со всех устройств»?

$users->incrementAuthVersion($userId);
$sessions->deleteAllForUser($userId);

Хранить список устройств только на клиенте и попросить их удалить cookie самостоятельно Изменить пароль, полагаясь, что все серверные сессии исчезнут автоматически Хранить серверные сессии/версию аутентификации и инвалидировать их централизованно Сменить session_name, не проверяя прежние идентификаторы на сервере Удалить cookie только в текущем браузере и считать остальные устройства отключёнными

Вопрос 18 из 30

Зачем повторно спрашивать пароль/MFA перед сменой email?

if (!$reauth->verifiedRecently($session)) {
    return new RedirectResponse('/confirm-password');
}
$emailChanger->change($userId, $newEmail);

MFA следует спрашивать только после изменения, чтобы подтвердить уведомление Повторная проверка нужна лишь для изменения отображаемого имени, но не email Новая проверка лишняя, если запрос пришёл с того же IP-адреса Достаточно проверить наличие активной cookie без учёта возраста аутентификации Захваченная сессия не должна автоматически давать необратимое чувствительное действие

Вопрос 19 из 30

Что хранить в сессии вместо полного объекта User?

Хеш пароля, чтобы не читать пользователя из базы при каждом запросе Открытое соединение с хранилищем пользователя для ускорения последующих запросов Токен сброса и последние введённые учётные данные для повторной проверки Сериализованный объект User со всеми ролями и профилем на момент входа Минимальный идентификатор и проверяемые сведения/версию авторизации

Вопрос 20 из 30

Как сочетать абсолютный и неактивный срок?

Использовать только абсолютный срок и не обновлять время последней активности Продлевать оба срока при каждом запросе, включая абсолютный максимум Завершать сессию и после общего максимума, и после длительного бездействия Использовать только срок неактивности: активная сессия может жить бесконечно Считать срок по времени cookie, не проверяя серверную запись сессии

Вопрос 21 из 30

Какие пароли нужны в тесте?

$cases = [
    'correct' => ['correct horse', true],
    'wrong' => ['wrong', false],
    'empty' => ['', false],
    'unicode' => ['пароль🔐', true],
    'long' => [str_repeat('a', 200), false],
];

Пустое значение и null, не проверяя длинные строки и Unicode Реальный пароль администратора в закрытом наборе интеграционных тестов Только случайный хеш без известного исходного значения Верный, неверный, пустой, длинный и Unicode — без реальных пользовательских секретов Только один популярный пароль, чтобы тест не зависел от кодировки

Вопрос 22 из 30

Что проверять при rehash?

$oldHash = password_hash($password, PASSWORD_BCRYPT, ['cost' => 10]);
assert(password_verify($password, $oldHash));
assert(password_needs_rehash($oldHash, PASSWORD_BCRYPT, ['cost' => 12]));
$newHash = password_hash($password, PASSWORD_BCRYPT, ['cost' => 12]);
assert(password_verify($password, $newHash));

Проверить лишь изменение длины строки хеша после password_hash Убедиться, что новый хеш совпадает с паролем при сравнении оператором === Старый хеш проходит verify, needs_rehash true, новый проходит verify и больше не требует обновления Сравнить соли старого и нового хеша: они должны быть одинаковыми Проверить только password_needs_rehash, не выполняя verify до и после обновления

Вопрос 23 из 30

Что нельзя журналировать?

Cookie сессии безопасна в журнале, если скрыто имя пользователя Токен сброса можно журналировать после применения urlencode Введённый пароль, токен сброса и полную cookie сессии Полный введённый пароль допустимо писать при неудачном входе для расследования Секреты можно хранить без маскирования в отладочном журнале production

Вопрос 24 из 30

Как тестировать rate limit без ожидания реальных минут?

Использовать реальный sleep на каждую минуту окна, чтобы тест повторял production Отключать лимит в тестах и проверять только текст сообщения об ошибке Внедрить часы и хранилище счётчиков, управляя временем в тесте Подменять HTML формы, не контролируя время и состояние счётчика Менять системные часы среды непрерывной проверки между утверждениями

Вопрос 25 из 30

Какая ошибка важна при неизвестном пользователе?

Создать гостевую сессию с расширенной ролью, чтобы унифицировать путь Для неизвестного адреса вернуть отдельный текст, но тот же HTTP-статус Пропустить вычисление хеша для неизвестного пользователя и добавить случайную задержку Публичный ответ совпадает с неверным паролем, а внутренний журнал не раскрывает секрет Записать фиктивный хеш и адрес в публичный JSON для удобства поддержки

Вопрос 26 из 30

Что даёт MFA?

$passwordOk = password_verify($password, $user->passwordHash);
$totpOk = $totp->verify($user->totpSecret, $code);
if (!$passwordOk || !$totpOk) throw new AuthenticationFailed();

Любой второй шаг, включая повтор того же пароля, считается независимым фактором Дополнительный фактор предотвращает SQL-инъекции и XSS в форме входа После включения MFA можно отключить TLS, поскольку код подтверждает пользователя Дополнительный независимый фактор, уменьшающий ущерб от украденного пароля MFA полностью заменяет пароль и безопасное управление сессией

Вопрос 27 из 30

Как ограничивать перебор без вечной блокировки жертвы?

$key = hash('sha256', mb_strtolower($email) . '|' . $sourceNetwork);
if (!$limiter->consume($key, $clock->now())) {
    throw new TooManyAttempts(retryAfter: $limiter->retryAfter($key));
}

Ограничивать только аккаунт, позволяя атакующему блокировать выбранную жертву Навсегда блокировать аккаунт после трёх ошибок независимо от источника Комбинировать задержки/лимиты по аккаунту и источнику, риск-сигналы и восстановление Ограничивать только IP, позволяя распределённому перебору одного аккаунта Добавлять одинаковый sleep без учёта накопленного риска и возможности восстановления

Вопрос 28 из 30

База хешей утекла. Что делать?

Опубликовать соли для доказательства, что исходные пароли не хранились Оценить алгоритмы, уведомить по риску, усилить мониторинг, отозвать сессии при необходимости и ускорить rehash/сброс Удалить журналы входа, поскольку они могут содержать сведения об инциденте Считать современные хеши неограниченно безопасными и не предпринимать действий Отключить password_verify, чтобы атакующий не мог проверить украденные строки на сайте

Вопрос 29 из 30

Почему PASSWORD_DEFAULT нужно сочетать с password_needs_rehash?

needs_rehash нужен только для паролей короче восьми символов PASSWORD_DEFAULT автоматически обновляет все строки в базе при обновлении PHP Успешный verify меняет хеш на месте даже без вызова password_hash Достаточно периодически менять имя столбца, не пересчитывая сохранённые хеши Алгоритм/параметры могут улучшиться, и успешные входы постепенно обновят хеши

Вопрос 30 из 30

Какое уведомление полезно после смены пароля?

Отправить новый пароль письмом, чтобы пользователь мог сверить изменение Не уведомлять вообще, чтобы не раскрывать факт существования аккаунта его владельцу Приложить полный хеш и токен сброса как доказательство операции Сообщить о событии и дать безопасный путь сообщить о чужом действии, не отправляя сам пароль Сообщить только новый session_id, по которому можно отменить изменение