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

Вопрос 1 из 30

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

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

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

Вопрос 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
);

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

Вопрос 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 слаб для паролей?

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

Вопрос 6 из 30

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

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

hash_equals($password,$hash) password_verify($password, $hash) decrypt($hash)===$password $hash === password_hash($password, PASSWORD_DEFAULT) md5($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_hash Удалить соль из старого хеша перед переходом на новый алгоритм Понять, что после успешной проверки хеш стоит пересоздать с новыми параметрами Проверить пароль без password_verify, сравнив параметры хеша вручную

Вопрос 8 из 30

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

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

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

Вопрос 9 из 30

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

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

Вопрос 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 Сравнить строку хеша оператором ===, затем вызвать password_verify для журнала Сделать rehash каждого сохранённого пароля при запуске приложения без входа пользователя Найти пользователя, verify, проверить статус, regenerate session ID, при нужде 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, затем отдельным запросом пометить использованным без условия Удалить токен после отправки ответа, не проверяя результат конкурентного UPDATE Разрешить оба запроса и считать последний записанный пароль итоговым Атомарно обновить запись только если unused и expires_at>now, затем проверить число изменённых строк

Вопрос 14 из 30

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

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

Вопрос 15 из 30

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

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

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

Вопрос 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],
];

Верный, неверный, пустой, длинный и Unicode — без реальных пользовательских секретов Реальный пароль администратора в закрытом наборе интеграционных тестов Только один популярный пароль, чтобы тест не зависел от кодировки Пустое значение и null, не проверяя длинные строки и 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_needs_rehash, не выполняя verify до и после обновления Старый хеш проходит verify, needs_rehash true, новый проходит verify и больше не требует обновления Проверить лишь изменение длины строки хеша после password_hash

Вопрос 23 из 30

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

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

Вопрос 24 из 30

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

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

Вопрос 25 из 30

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

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

Вопрос 26 из 30

Что даёт MFA?

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

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

Вопрос 27 из 30

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

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

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

Вопрос 28 из 30

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

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

Вопрос 29 из 30

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

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

Вопрос 30 из 30

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

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