Пароли, выработка и управление ключами

Пароль — самый распространённый и самый слабый секрет в любой системе. Он выбирается человеком, а значит имеет низкую энтропию, повторяется на разных сайтах и попадает в утечки. Задача криптографии здесь не «зашифровать пароль», а сделать так, чтобы украденная база не превратилась в список открытых паролей: проверка должна быть достаточно дорогой, чтобы массовый перебор стал невыгодным, и достаточно быстрой, чтобы вход занимал десятые доли секунды.

Отсюда два разных класса функций. Быстрые хеш-функции (SHA-256) хороши для целостности, но непригодны для паролей: современная видеокарта считает миллиарды SHA-256 в секунду, и база из миллиона хешей вскрывается за минуты. Медленные функции (PBKDF2, bcrypt, scrypt, Argon2) специально спроектированы так, чтобы каждая попытка стоила дорого — по времени или по памяти. Именно память оказалась решающим ресурсом: видеокарта имеет тысячи параллельных потоков, но ограниченный объём быстрой памяти, поэтому функция, требующая мегабайт на вычисление, снижает преимущество GPU на порядки.

Вторая половина темы — выработка ключей из уже готового секрета. Здесь задача обратная: нужно из одного случайного секрета получить несколько независимых ключей для разных целей, не потеряв стойкости. Для этого служит HKDF с его двумя шагами — извлечением и расширением, — и разделение по назначению (доменная сепарация), без которого ключ шифрования и ключ MAC могут случайно совпасть.

Третья часть — управление ключами: иерархия, шифрование конвертом, обёртывание ключей, ротация, уничтожение, HSM. Это наименее «математическая» и наиболее часто проваливаемая часть: большинство инцидентов с ключами происходит не из-за взлома алгоритма, а из-за того, что ключ лежал в конфигурации, репозитории или логе.

Паспорт темы. Нужно знать: темы 0, 3, 9. Освоите: объяснять, почему пароли — особая задача; подбирать параметры PBKDF2, scrypt и Argon2id; оценивать энтропию пароля; строить HKDF с разделением ключей; описывать обёртывание ключей, конверт и иерархию KMS. Проверяет: ЛР 10. Минимум: разделы 1–4. Углубление: разделы 5–6.

Почему пароли — особая задача

Утечки и их последствия

Крупные утечки паролей происходят регулярно, и их последствия выходят далеко за пределы одного сайта. RockYou (2009) — 32 миллиона паролей в открытом виде, ставших учебным набором для всех, кто занимается подбором. LinkedIn (2012) — около 6,5 миллиона хешей SHA-1 без соли, значительная часть которых была восстановлена за дни. Adobe (2013) — десятки миллионов записей с обратимым «шифрованием» и подсказками к паролям.

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

Практическое следствие для разработчика: хранение паролей — не «ещё одно поле в базе», а отдельная задача с собственными требованиями, и ошибка здесь не компенсируется ничем: ни HTTPS, ни двухфакторной аутентификацией, ни политикой сложности.

Перебор, словари и правила

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

К словарю применяются правила мутаций (англ. mutation rules): заглавная первая буква, замена a → @, o → 0, добавление 1, !, 2024 в конец. Правила увеличивают словарь в десятки раз, но всё равно остаются на много порядков меньше полного пространства. Именно поэтому пароль P@ssw0rd2024 не лучше password: он входит в стандартный набор мутаций.

Скорость перебора зависит от функции хранения:

Числа зависят от оборудования и меняются каждый год, но соотношение устойчиво: медленная функция с памятью даёт выигрыш в тысячи раз против быстрой хеш-функции.

Радужные таблицы и почему нужна соль

Радужная таблица (англ. rainbow table) — компромисс между временем и памятью для обращения хешей. Идея восходит к Хеллману (1980) ⁹: вместо хранения всех пар «пароль — хеш» строятся цепочки, где чередуются функция редукции и хеш, и хранятся только начала и концы цепочек. Ойшлин (2003) усовершенствовал метод, добавив разные функции редукции на разных позициях, что уменьшило число коллизий внутри цепочек ¹⁰.

Для защиты достаточно соли — случайного значения, уникального для каждой записи. Хеш вычисляется от salt || password, поэтому:

• одинаковые пароли дают разные хеши;
• заранее вычисленная таблица бесполезна, потому что для каждой соли нужна своя;
• атака на конкретный аккаунт требует пересчёта таблицы, что сопоставимо с прямым перебором.

Соль не обязана быть секретной — она хранится рядом с хешем. Её длина: 16 байт и больше, генерируется криптографическим генератором.

«Перец» (англ. pepper) — дополнительный секрет, общий для всех записей, который хранится не в базе, а в конфигурации или в HSM. Он защищает от сценария, когда украдена только база: без перца перебор невозможен. Ограничение: перец нельзя менять без пересчёта всех хешей, и он не помогает, если украден и код.

Медленные функции хеширования паролей

PBKDF2

PBKDF2 (RFC 8018) — простейшая медленная функция: HMAC применяется к паролю и соли заданное число раз ¹.

DK = T₁ || T₂ || …
Tᵢ = F(P, S, c, i)
F = U₁ ⊕ U₂ ⊕ … ⊕ U_c
U₁ = HMAC(P, S || INT(i)),  U_j = HMAC(P, U_{j−1})

Достоинства: простота, стандартизованность, поддержка везде (в том числе в ФСТЭК-сертифицированных средствах). Недостаток: только время, никакой памяти. GPU легко распараллеливает PBKDF2, потому что каждое вычисление требует лишь несколько десятков байт состояния.

Параметры: число итераций и длина производного ключа. OWASP рекомендует 600 000 итераций для PBKDF2-HMAC-SHA256 (и 210 000 для SHA-512) ⁷. NIST SP 800-63B требует, чтобы число итераций было «как можно большим», и приводит 10 000 как абсолютный минимум для устаревших систем ⁶.

import hashlib

dk = hashlib.pbkdf2_hmac("sha256", password, salt, 600_000, dklen=32)

bcrypt

bcrypt (1999) — адаптивная функция на основе шифра Blowfish с модифицированным расписанием ключей ⁸. Параметр cost задаёт число итераций как 2^cost; при cost = 12 это 4096 раундов расширения ключа. Достоинство — адаптивность: при росте вычислительных мощностей увеличивают cost, не меняя формат.

Особенность: bcrypt использует только первые 72 байта пароля, остальное игнорируется. Это не уязвимость при разумных паролях, но при длинных парольных фразах часть энтропии теряется, и это нужно знать. Вторая особенность — внутреннее состояние 4 КБ, что ограничивает параллелизм на GPU, но не так сильно, как у scrypt и Argon2.

scrypt

scrypt (RFC 7914) — функция, затратная по памяти ². Параметры N (число блоков), r (размер блока), p (параллелизм). Память оценивается как 128 · N · r байт; при N = 2^17, r = 8 это 128 МиБ.

Алгоритм сначала заполняет большой массив псевдослучайными блоками, затем обращается к нему в псевдослучайном порядке. Именно это делает атаку дорогой: для каждого параллельного вычисления нужна своя память, а её количество на видеокарте ограничено. Кроме того, случайные обращения к большой памяти плохо ложатся на архитектуру GPU.

import hashlib

dk = hashlib.scrypt(password, salt=salt, n=2**17, r=8, p=1, dklen=32, maxmem=256 * 1024 * 1024)

Тестовый вектор RFC 7914: scrypt("", "", N=16, r=1, p=1, dklen=64) даёт 77d65762…d18906. Он нужен для проверки реализации и показывает, что параметры входят в результат.

Argon2 и выбор параметров

Argon2 (RFC 9106) — победитель конкурса Password Hashing Competition (2015) ³¹². Три варианта: Argon2d (устойчив к GPU, но уязвим к атакам по сторонним каналам), Argon2i (устойчив к сторонним каналам, но слабее против GPU), Argon2id (гибрид, рекомендуемый по умолчанию).

Параметры: память m, число проходов t, параллелизм p, длина соли и тега. Редакции рекомендаций различаются, и их стоит называть явно. OWASP (редакция 2023 года и новее) приводит несколько профилей: m = 19 МиБ, t = 2, p = 1; m = 46 МиБ, t = 1, p = 1; m = 12 МиБ, t = 3, p = 1. RFC 9106 рекомендует более дорогие профили: m = 64 МиБ, t = 3, p = 4 как второй вариант и m = 2 ГиБ, t = 1, p = 4 как первый, для систем, где память действительно есть.

from argon2.low_level import hash_secret_raw, Type

tag = hash_secret_raw(
    secret=password, salt=salt, time_cost=2, memory_cost=19 * 1024,
    parallelism=1, hash_len=32, type=Type.ID,
)

Пакет argon2-cffi (в Ubuntu — python3-argon2) может отсутствовать; в этом случае продвинутая часть работы выполняется на scrypt, а Argon2 разбирается по спецификации. В cryptography Argon2 появился начиная с версии 44, поэтому в среде с 3.4.8 он недоступен.

Выбор параметров — компромисс между стоимостью проверки и стоимостью перебора. Ориентир — время проверки порядка десятых долей секунды на той машине, где она выполняется (это порядок величины, а не норматив: конкретное число зависит от оборудования и нагрузки). Меньше — перебор становится дешевле; больше — сервер не справляется и появляется соблазн кэшировать результаты. Параметры фиксируются в формате хранения вместе с солью и версией алгоритма, иначе обновление профиля потребует пересчёта всех хешей.

Сравнение

Практическое правило: для нового кода — Argon2id, если библиотека доступна; scrypt как замена; PBKDF2 как минимально допустимый вариант для совместимости.

Энтропия паролей и политика

Энтропия и парольные фразы

Энтропия пароля оценивается как log₂ числа вариантов, из которых он выбран. Для случайной строки из 12 символов алфавита 62 это log₂(62^12) ≈ 71 бит. Для пароля Tr0ub4dor&3 энтропия гораздо ниже, чем кажется: он состоит из слова с заменами и суффикса, то есть входит в пространство, которое покрывается правилами мутаций.

Парольная фраза (англ. passphrase) из четырёх случайных слов, выбранных из словаря в 7776 слов (как в схеме Diceware), даёт log₂(7776^4) ≈ 51,7 бита. Пять слов — около 64,6 бита, шесть — около 77,5. Такая фраза длиннее и легче запоминается, чем случайная строка той же энтропии.

Важно: энтропия считается относительно модели выбора. Если слова выбираются не случайно, а «придумываются», энтропия падает до уровня словаря с мутациями, и оценка в 51 бит превращается в 30–35.

Рекомендации NIST SP 800-63B

NIST SP 800-63B (2017, обновления 2020-х) изменил подход к паролям ⁶. Основные положения:

• минимальная длина — 8 символов, рекомендуется 15 и больше для паролей без второго фактора;
• максимальная длина — не менее 64 символов, чтобы не мешать парольным фразам и менеджерам;
• проверка по списку распространённых и скомпрометированных паролей обязательна;
• правила сложности (заглавные, цифры, спецсимволы) и принудительная ротация — не рекомендуются, потому что дают предсказуемые мутации;
• подсказки к паролю не должны раскрывать сам пароль;
• ограничение числа попыток входа обязательно;
• при проверке допускаются пробелы и любые символы Unicode.

Логика изменений: правила сложности заставляют людей выбирать Password1!, что хуже длинной фразы; принудительная ротация заставляет менять Password1! на Password2!. Проверка по списку утечек и ограничение попыток дают больше, чем формальные требования.

Что не работает

Несколько мер, которые кажутся полезными, но не работают. Ограничение длины пароля до 16 символов — мешает менеджерам и фразам. Запрет спецсимволов — снижает пространство. Секретные вопросы — часто угадываются по открытым данным. Хранение пароля в логах или в параметрах URL — утечка. Отправка пароля по электронной почте «для восстановления» — компрометация.

Отдельно стоит упомянуть проверку на скомпрометированные пароли: сервисы вроде Have I Been Pwned позволяют проверить хеш пароля по префиксу, не передавая сам пароль (k-anonymity). Это хорошая практика, и она встроена во многие менеджеры паролей.

Функции выработки ключей

KDF из секрета и KDF из пароля

Важно различать два класса функций, которые по-русски называются одинаково. Полезно держать перед глазами всю таблицу «похожих» примитивов: у них разные входы, разные цели и разные атаки.

Строчки «KDF из секрета» и «парольный KDF» различаются не устройством, а предположением о входе: если вход равномерен, замедлять нечего, а если это пароль, замедление обязательно. Ошибка «применим HKDF к паролю» не даёт ошибки в коде — она даёт незаметно слабую систему.

Функция выработки ключа из пароля (англ. password-based key derivation function) — медленная, с солью, предназначена для низкоэнтропийного входа. Это PBKDF2, scrypt, Argon2. Её цель — сделать перебор дорогим.

Функция выработки ключа из секрета (англ. key derivation function) — быстрая, предназначена для высокоэнтропийного входа. Её цель — из одного хорошего секрета получить несколько ключей для разных целей. Это HKDF.

Путать их опасно: HKDF от пароля не даёт защиты от перебора (он быстрый), а PBKDF2 от случайного ключа — лишняя трата ресурсов.

HKDF: extract и expand

HKDF (RFC 5869) состоит из двух шагов ⁴.

Шаг извлечения (англ. extract) превращает входной материал в псевдослучайный ключ фиксированной длины:

PRK = HMAC(salt, IKM)

Шаг расширения (англ. expand) разворачивает PRK в ключи нужной длины и для нужных назначений:

OKM = T₁ || T₂ || …
T₁ = HMAC(PRK, info || 0x01)
Tᵢ = HMAC(PRK, T_{i−1} || info || i)

Параметр info — это и есть разделение по назначению: разные строки дают независимые ключи. Например, info = b"encryption" и info = b"authentication" дают два ключа, которые нельзя перепутать.

import hashlib, hmac

def hkdf_extract(salt, ikm):
    return hmac.new(salt, ikm, hashlib.sha256).digest()


def hkdf_expand(prk, info, length):
    out, t, i = b"", b"", 1
    while len(out) < length:
        t = hmac.new(prk, t + info + bytes([i]), hashlib.sha256).digest()
        out += t
        i += 1
    return out[:length]

Тестовый вектор RFC 5869, случай 1: IKM = 0b·22, salt = 000102030405060708090a0b0c, info = f0f1f2f3f4f5f6f7f8f9, длина 42. Ожидаемый PRK = 077709362c2e32df0ddc3f0dc47bba6390b6c73bb50f9c3122ec844ad7c2b3e5, OKM = 3cb25f25faacd57a90434f64d0362f2a2d2d0a90cf1a5a4c5db02d56ecc4c5bf34007208d5b887185865.

Схема ниже показывает оба шага.

Разделение по назначению

Доменная сепарация (англ. domain separation) — требование, чтобы каждый ключ использовался ровно для одной цели. Причина проста: если один и тот же ключ применяется и для шифрования, и для MAC, свойства примитивов смешиваются, и появляются атаки, которых не было бы при разделении.

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

Разделение реализуется через info в HKDF, через префиксы в KDF или через разные соли. Главное — чтобы разные цели никогда не получали один и тот же ключ.

Управление ключами

Иерархия и шифрование конвертом

Ключей в системе много, и они образуют иерархию. Верхний уровень — корневой ключ (англ. root key или master key), который хранится в защищённом месте (HSM, KMS) и используется редко. Следующий уровень — ключи шифрования ключей (англ. key encryption key, KEK). Нижний уровень — ключи шифрования данных (англ. data encryption key, DEK), которые используются для конкретных объектов.

Шифрование конвертом (англ. envelope encryption): данные шифруются DEK, а DEK шифруется KEK. Получается «конверт»: зашифрованные данные и зашифрованный ключ рядом. Достоинства: DEK можно менять часто, не перешифровывая данные; KEK остаётся в HSM; при утечке одного DEK скомпрометирован только один объект.

Схема ниже показывает иерархию.

Обёртывание ключей

Для шифрования ключей используют не произвольный режим, а специализированный — обёртывание ключей (англ. key wrapping). AES-KW (RFC 3394) определён именно для этого ⁵: он шифрует ключ с целостностью, без nonce, и результат на 8 байт длиннее входа.

Свойства AES-KW: детерминированность (одинаковый ключ и KEK дают одинаковый результат), встроенная проверка целостности (при подмене расшифрование отклоняется), поддержка в HSM и стандартных библиотеках. Детерминированность здесь достоинство, а не недостаток: обёрнутый ключ хранится в базе, и повторное обёртывание того же ключа не должно давать новый результат.

from cryptography.hazmat.primitives.keywrap import aes_key_wrap, aes_key_unwrap

wrapped = aes_key_wrap(kek, dek)          # длина кратна 8, результат +8 байт
dek = aes_key_unwrap(kek, wrapped)        # InvalidUnwrap при подмене

Ротация, уничтожение и HSM

Ротация ключей (англ. key rotation) — регулярная смена ключей с сохранением возможности читать старые данные. Реализуется через версионирование: в контейнере хранится идентификатор версии ключа, и при чтении используется соответствующая версия. Сроки ротации зависят от чувствительности данных и от требований стандарта (NIST SP 800-57 рекомендует конкретные периоды для разных типов ключей).

Уничтожение ключа (англ. key destruction) — не удаление файла, а гарантированное затирание всех копий, включая резервные и кэшированные. В HSM это делается командой, которая физически уничтожает материал; в программной среде — перезаписью, но гарантий меньше, потому что копии могут остаться в снапшотах и бэкапах.

HSM (англ. hardware security module) — устройство, которое хранит ключи и выполняет операции с ними, не выдавая материал наружу. Программный интерфейс — PKCS#11, а также KMIP и проприетарные API. KMS — облачный аналог: управляемый сервис, который выполняет шифрование и хранит ключи, а клиент получает только результат.

Практическое правило: если ключ можно прочитать в коде или в конфигурации, это не «управление ключами», а хранение секрета в открытом виде. Настоящее управление начинается там, где ключ никогда не покидает границу, в которой он используется.

Аутентификация без передачи пароля

SCRAM

SCRAM (RFC 5802) — схема аутентификации, при которой пароль не передаётся по сети даже в защищённом виде ¹¹. Клиент доказывает знание пароля, используя соль, число итераций и серверный nonce, а сервер проверяет доказательство. Схема устойчива к перехвату и к компрометации базы: украденные верификаторы не позволяют войти без перебора.

SCRAM используется как механизм SASL в PostgreSQL, MongoDB, Kafka, XMPP. Он требует, чтобы сервер хранил не хеш пароля, а верификатор, из которого нельзя вывести ключ клиента.

PAKE и OPAQUE

PAKE (англ. password-authenticated key exchange) — класс протоколов, которые одновременно аутентифицируют стороны по паролю и вырабатывают общий ключ, причём пароль не передаётся и не может быть проверен офлайн по перехвату. Классический пример — SPAKE2 (RFC 9382); другой — OPAQUE, где сервер хранит не пароль, а «конверт», который нельзя использовать для офлайн-перебора без взаимодействия с сервером.

Практическая ценность: PAKE защищает от офлайн-перебора по перехваченному рукопожатию и от компрометации базы (в случае OPAQUE). Стоимость — сложность реализации и отсутствие поддержки в большинстве библиотек, поэтому в массовых продуктах чаще встречается SCRAM или TLS с паролем внутри защищённого канала.

Итоги темы

Пароли нельзя хранить открыто и нельзя хранить «просто хешем». Правильная схема включает соль (уникальную для каждой записи), медленную функцию (PBKDF2, bcrypt, scrypt или Argon2id) и параметры, подобранные под целевую задержку в 100–300 мс. Память — ключевой ресурс: функции, требующие мегабайт на вычисление, снижают преимущество GPU на порядки.

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

Выработка ключей — отдельная задача: HKDF с шагами extract и expand позволяет из одного секрета получить несколько независимых ключей, а параметр info обеспечивает разделение по назначению. Смешивать KDF из пароля и KDF из секрета нельзя: у них разные цели и разные требования к скорости.

Управление ключами — самая проваливаемая часть. Иерархия, шифрование конвертом, обёртывание ключей (AES-KW), ротация с версионированием, уничтожение и HSM — не бюрократия, а способ сделать так, чтобы утечка одного ключа не означала утечку всех. Правило простое: ключ не должен появляться там, где его можно прочитать.

Следующая тема переходит к асимметричной криптографии — обмену ключами Диффи — Хеллмана, — где задача распределения ключей решается принципиально иначе, а требования к случайности и к проверке параметров становятся ещё строже.

Литература

1. Moriarty K. (ed.). PKCS #5: Password-Based Cryptography Specification Version 2.1. — RFC 8018, IETF, 2017. https://www.rfc-editor.org/rfc/rfc8018
2. Percival C., Josefsson S. The scrypt Password-Based Key Derivation Function. — RFC 7914, IETF, 2016. https://www.rfc-editor.org/rfc/rfc7914
3. Biryukov A., Dinu D., Khovratovich D., Josefsson S. Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications. — RFC 9106, IETF, 2021. https://www.rfc-editor.org/rfc/rfc9106
4. Krawczyk H., Eronen P. HMAC-based Extract-and-Expand Key Derivation Function (HKDF). — RFC 5869, IETF, 2010. https://www.rfc-editor.org/rfc/rfc5869
5. Schaad J., Housley R. Advanced Encryption Standard (AES) Key Wrap Algorithm. — RFC 3394, IETF, 2002. https://www.rfc-editor.org/rfc/rfc3394
6. NIST. Digital Identity Guidelines: Authentication and Lifecycle Management. — SP 800-63B, 2017 (with updates). https://doi.org/10.6028/NIST.SP.800-63b
7. OWASP. Password Storage Cheat Sheet. — OWASP Cheat Sheet Series, 2024. https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
8. Provos N., Mazières D. A Future-Adaptable Password Scheme. — Proceedings of the USENIX Annual Technical Conference, 1999. https://www.usenix.org/legacy/events/usenix99/provos.html
9. Hellman M. E. A Cryptanalytic Time-Memory Trade-Off. — IEEE Transactions on Information Theory, 1980, Т. 26, № 4, С. 401–406. DOI: 10.1109/TIT.1980.1056220
10. Oechslin P. Making a Faster Cryptanalytic Time-Memory Trade-Off. — Advances in Cryptology — CRYPTO 2003, Springer, 2003, С. 617–630. DOI: 10.1007/978-3-540-45146-4_36
11. Newman C., Menon-Sen A., Melnikov A., Williams N. Salted Challenge Response Authentication Mechanism (SCRAM-SHA-1). — RFC 5802, IETF, 2010. https://www.rfc-editor.org/rfc/rfc5802
12. Biryukov A., Dinu D., Khovratovich D. Argon2: New Generation of Memory-Hard Functions for Password Hashing and Other Applications. — IEEE European Symposium on Security and Privacy (EuroS&P), 2016, С. 292–302. DOI: 10.1109/EuroSP.2016.38

Дополнительные материалы

Вопросы для самопроверки

1. Почему пароль — это секрет с низкой энтропией и какие последствия это имеет для хранения?
2. Почему HTTPS и двухфакторная аутентификация не спасают от утечки базы паролей?
3. Что такое правила мутаций и почему пароль P@ssw0rd2024 не лучше password?
4. Как радужная таблица использует компромисс между временем и памятью?
5. Почему соль делает заранее вычисленные таблицы бесполезными?
6. Чем «перец» отличается от соли и почему его нельзя менять без пересчёта?
7. Почему PBKDF2 уязвим к перебору на GPU сильнее, чем scrypt и Argon2?
8. Как параметры scrypt N, r, p влияют на память и время?
9. Почему bcrypt ограничивает вход 72 байтами и что это значит для парольных фраз?
10. Как оценивается энтропия парольной фразы и почему выбор слов должен быть случайным?
11. Почему NIST SP 800-63B отказался от правил сложности и принудительной ротации?
12. Чем KDF из пароля отличается от KDF из секрета по требованиям к скорости?
13. Что делает параметр info в HKDF и почему он обязателен для разделения ключей?
14. Зачем нужен отдельный ключ данных при шифровании конвертом?
15. Почему SCRAM и OPAQUE защищают лучше, чем «отправить пароль по TLS»?

Глоссарий темы

Шпаргалка по инструментам

import hashlib, hmac, os
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
from cryptography.hazmat.primitives.keywrap import aes_key_wrap, aes_key_unwrap

salt = os.urandom(16)
dk = hashlib.pbkdf2_hmac("sha256", b"password", salt, 600_000, dklen=32)
dk = hashlib.scrypt(b"password", salt=salt, n=2**17, r=8, p=1, dklen=32,
                    maxmem=256 * 1024 * 1024)

kek = hashlib.scrypt(b"password", salt=salt, n=2**15, r=8, p=1, dklen=32,
                     maxmem=64 * 1024 * 1024)
dek = os.urandom(32)
wrapped = aes_key_wrap(kek, dek)
assert aes_key_unwrap(kek, wrapped) == dek

# OpenSSL: PBKDF2 для проверки совместимости
openssl kdf -keylen 32 -kdfopt digest:SHA256 -kdfopt pass:password \
  -kdfopt hexsalt:00112233 -kdfopt iter:100000 PBKDF2

# Argon2, если установлен python3-argon2
python3 -c "import argon2; print(argon2.__version__)"

параметры OWASP       PBKDF2-SHA256: 600 000 итераций
                      scrypt: N=2^17, r=8, p=1 (или N=2^16 для меньшей памяти)
                      Argon2id: m=19 МиБ, t=2, p=1
целевая задержка      100–300 мс на проверку
соль                  16 байт и больше на запись

Типичные ошибки:

Что почитать и посмотреть

• OWASP Password Storage Cheat Sheet. Практические рекомендации с конкретными параметрами для PBKDF2, bcrypt, scrypt и Argon2id. Обновляется, поэтому полезна как актуальный ориентир. https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
• NIST SP 800-63B. Официальные требования к аутентификации: длина, проверка по списку утечек, ограничение попыток, отказ от правил сложности. Читается как документ, меняющий индустрию. https://doi.org/10.6028/NIST.SP.800-63b
• RFC 8018 (PBKDF2). Спецификация: функции, параметры, тестовые векторы. Полезно для реализации и для понимания, почему итерации применяются именно так.
• RFC 7914 (scrypt). Описание функции, параметров и их влияния на память. Здесь же тестовый вектор, который используется в лабораторной.
• RFC 9106 (Argon2). Спецификация Argon2 с рекомендациями по параметрам и обоснованием выбора Argon2id.
• Provos N., Mazières D. A Future-Adaptable Password Scheme (1999). Первоисточник bcrypt: идея адаптивной стоимости и почему она важна при росте вычислительных мощностей. https://www.usenix.org/legacy/events/usenix99/provos.html
• Hellman M. A Cryptanalytic Time-Memory Trade-Off (1980) и Oechslin P. (2003). Две работы, объясняющие радужные таблицы: от базовой идеи до практической оптимизации. Полезно понять, почему соль ломает всю конструкцию.
• RFC 5869 (HKDF). Спецификация с примером применения: зачем два шага и как info обеспечивает разделение.
• RFC 3394 (AES-KW). Обёртывание ключей: формат, свойства, тестовые векторы. Пример того, как узкая задача решается специализированным алгоритмом, а не «обычным шифрованием».

Углубление (по желанию)

Почему Argon2 победил. Конкурс Password Hashing Competition (2013–2015) ставил задачу выбрать функцию, устойчивую к атакам на GPU, FPGA и ASIC. Argon2 предложил ясную модель стоимости: память, время и параллелизм — три независимых параметра, каждый из которых можно настроить под конкретную машину. Вариант Argon2id сочетает устойчивость к сторонним каналам (первый проход в режиме i) с устойчивостью к GPU (последующие проходы в режиме d). Ключевая идея — память как ресурс, который дорого наращивать параллельно: видеокарта имеет тысячи потоков, но десятки гигабайт памяти, и если каждая проверка требует 64 МиБ, параллелизм резко падает. Это та же логика, что у scrypt, но с более гибкими параметрами.

Что происходит при смене политики паролей. Переход на новые рекомендации (длина вместо сложности, проверка по утечкам, отказ от ротации) упирается не в технологию, а в процессы: старые пароли не соответствуют новым требованиям, миграция требует пересчёта хешей, а пересчёт — знания пароля в момент входа. Практический приём: при успешном входе проверять, соответствует ли сохранённый хеш текущим параметрам, и если нет — пересчитывать с новыми. Так база обновляется постепенно, без принудительных сбросов, которые всегда вызывают недовольство и снижают безопасность (люди начинают записывать пароли на бумаге).

Разделение ключей в реальных протоколах. В TLS 1.3 из общего секрета выводятся ключи для каждого направления и каждого этапа: ранние данные, рукопожатие, данные приложения, обновление, экспорт. Все метки прописаны в спецификации, и любая ошибка в них ломает совместимость. Показательно, что за двадцать лет до этого в TLS 1.2 использовались разные ключи для MAC и шифрования, но выводились они из общего материала через PRF с метками — то есть идея разделения по назначению не нова, новизна в строгости исполнения. Именно поэтому раздел про HKDF важен: это не «ещё одна функция», а способ гарантировать, что ключ шифрования никогда не совпадёт с ключом аутентификации.

Лабораторная работа 10. Хранение паролей и выработка ключей

• Раздел курса: тема 10 «Пароли, выработка и управление ключами»

Введение

Тема 10 разобрала две противоположные задачи: сделать вычисление по паролю как можно более дорогим и сделать выработку ключей из готового секрета как можно более дешёвой. Лабораторная работа проверяет обе на практике. Сначала — аудит учебной «утёкшей» базы: шесть записей, четыре разных способа хранения, словарь из тридцати слов и правила мутаций. Затем — подбор параметров PBKDF2 и scrypt под целевое время, сравнение стоимости по памяти и по времени. Далее — HKDF с проверкой по тестовому вектору RFC 5869 и разделением ключей по назначению. Завершает работу защищённое паролем хранилище ключей «Сейф»: scrypt для выработки ключа, AES-GCM для шифрования, обёртывание ключа данных.

Работа опирается на темы 8 (хеш-функции) и 9 (AEAD). Она готовит тему 14: там понадобится понимание того, что ключ — это не «строчка в конфиге», а объект с жизненным циклом.

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

Цель работы

Измерить стоимость перебора паролей при разных способах хранения, подобрать параметры медленных функций под целевую задержку и собрать защищённое паролем хранилище ключей с корректным разделением ключей.

После выполнения работы можно будет:

• реализовать PBKDF2-HMAC-SHA256 и подобрать число итераций под задержку 100–300 мс;
• восстановить пароли из учебной базы, применяя правила мутаций к словарю;
• сравнить скорость перебора для MD5, SHA-256 с солью, PBKDF2 и scrypt;
• настроить scrypt и объяснить, почему память ограничивает преимущество GPU;
• выработать несколько независимых ключей из одного секрета через HKDF и сверить с RFC 5869;
• собрать хранилище «Сейф» с обёртыванием ключа данных и обнаружить подмену.

Уровни работы

• Минимум (обязательно): части 1–3. Выполняется без внешней сети, только с пакетами из перечня оснащения.
• Практический уровень: 5–6.
• Углубление (по желанию): 4 (Argon2, при наличии пакета).

Теоретический минимум

Нужны разделы «Почему пароли — особая задача», «Медленные функции хеширования паролей», «Функции выработки ключей» и «Управление ключами».

PBKDF2      DK = T₁ || T₂ || …,  Tᵢ = F(P, S, c, i),  F = U₁ ⊕ … ⊕ U_c
HKDF        PRK = HMAC(salt, IKM);  OKM = expand(PRK, info, L)
scrypt      память ≈ 128·N·r байт
AES-KW      обёртывание ключа, результат +8 байт, встроенная целостность
соль        16 байт и больше, уникальна для записи, хранится открыто

Тестовые векторы:

HKDF RFC 5869, случай 1
IKM  0b·22, salt 000102030405060708090a0b0c, info f0f1f2f3f4f5f6f7f8f9, L=42
PRK  077709362c2e32df0ddc3f0dc47bba6390b6c73bb50f9c3122ec844ad7c2b3e5
OKM  3cb25f25faacd57a90434f64d0362f2a2d2d0a90cf1a5a4c5db02d56ecc4c5bf34007208d5b887185865

scrypt RFC 7914
scrypt("", "", N=16, r=1, p=1, dklen=64)
77d6576238657b203b19ca42c18a0497f16b4844e3074ae8dfdffa3fede21442fcd0069ded0948f8326a753a0fc81f17e8d3e0fb2e0d3628cf35e20c38d18906

Перечень оснащения

• Ubuntu 24.04 (или WSL2), Python 3.10+, стандартная библиотека, cryptography 3.4 или новее. Пакет argon2-cffi (python3-argon2) нужен только для продвинутой части. Права root не нужны.
• Архив окружения: lr-env.zip.

Ограничения ресурсов

Словарь — 10^4–10^5 строк; scrypt при N = 2^17 требует около 128 МиБ, что укладывается в 4 ГБ ОЗУ. Время выполнения не нормируется: проверяются свойства и совпадение с тестовыми векторами, а не абсолютные секунды. Если на конкретной машине шаг занимает заметно больше ожидаемого, это фиксируется в журнале вместе с параметрами оборудования.

Безопасная область эксперимента

Работа выполняется в отдельном каталоге ~/crypto-lab-10; всё необходимое лежит в архиве окружения. Учебные серверы и оракулы слушают только 127.0.0.1. Внешняя сеть не используется.

Порядок выполнения работы

mkdir -p ~/lab10 && cd ~/lab10
unzip /path/to/lr-env.zip
python3 check_kdf.py -v

Проверки покрывают PBKDF2, HKDF, scrypt и аудит. Доступность Argon2 проверяется отдельно:

python3 -c "import argon2; print(argon2.__version__)"

Часть 1. PBKDF2 и подбор параметров

Задание

1. Заполните pbkdf2_sha256(password, salt, iterations, dklen) по RFC 8018.
2. Заполните pick_pbkdf2_iterations(target_ms): подберите число итераций так, чтобы одно вычисление занимало около target_ms миллисекунд.
3. Замерьте время при 100 000, 300 000 и 600 000 итерациях. Постройте зависимость времени от числа итераций и убедитесь, что она линейна.
4. Подберите параметры под 200 мс на своей машине. Запишите полученное число итераций.
5. Оцените, сколько времени займёт перебор словаря из миллиона вариантов при подобранных параметрах.

Что должно получиться

Работающая функция, подобранные параметры и оценка стоимости перебора. Вывод: 200 мс на проверку — это удобно для сервера и крайне неудобно для атакующего, потому что миллион вариантов потребует более двух суток на одном потоке.

Часть 2. Аудит «утёкшей» базы

Задание

1. Загрузите data/leaked.json. В нём шесть записей с разными способами хранения: MD5 без соли, SHA-256 с солью, PBKDF2, scrypt.
2. Изучите audit_leaked(db, words): для каждого словаря-варианта функция пробует все форматы. Заполните её, если в заготовке есть TODO.
3. Расширьте правила мутаций: к вариантам «как есть», «с заглавной», «с суффиксами 1, !, 2024» добавьте минимум два своих правила (например, a → @, o → 0).
4. Запустите аудит и убедитесь, что восстановлены все шесть паролей.
5. Измерьте время восстановления для каждого формата отдельно. Постройте таблицу «формат — время на одну попытку — время на весь словарь».

Что должно получиться

Все шесть паролей и таблица времён. Ожидание: MD5 вскрывается за доли секунды, PBKDF2 с большим числом итераций — за минуты, scrypt — заметно дольше. Это и есть измеряемая разница между способами хранения.

Часть 3. scrypt и стоимость по памяти

Задание

1. Заполните scrypt_kdf(password, salt, n, r, p, dklen).
2. Проверьте по вектору RFC 7914: scrypt("", "", n=16, r=1, p=1, dklen=64).
3. Замерьте время и память при N = 2^14, 2^15, 2^16, 2^17 при r = 8, p = 1. Убедитесь, что память растёт как 128·N·r.
4. Сравните с PBKDF2, подобранным на то же время: во сколько раз scrypt дороже по памяти при той же задержке?
5. Объясните, почему это важно: видеокарта может запустить тысячи потоков PBKDF2, но не может дать каждому по 128 МБ.

Что должно получиться

Таблица «N — память — время» и сравнение с PBKDF2. Вывод: память — ресурс, который труднее наращивать параллельно, поэтому scrypt и Argon2 дают лучшее сопротивление GPU, чем PBKDF2.

Часть 4. Argon2 (продвинутая, при наличии пакета)

Задание

1. Проверьте наличие argon2-cffi. Если пакета нет, часть выполняется по документации с записью в журнал, что измерение не проводилось.
2. Выработайте тег с параметрами OWASP по умолчанию: m = 19 МиБ, t = 2, p = 1.
3. Замерьте время при m = 19, 32, 64 МиБ и t = 2, 3.
4. Сравните с scrypt при сопоставимом времени: какой объём памяти требуется каждому?
5. Сформулируйте, почему Argon2id выбран по умолчанию вместо Argon2d и Argon2i.

Что должно получиться

Таблица параметров и времени, либо честная запись о том, что измерение не выполнялось из-за отсутствия пакета. Второе допустимо, первое предпочтительнее.

Часть 5. HKDF и разделение по назначению

Задание

1. Заполните hkdf_extract, hkdf_expand и hkdf.
2. Проверьте по вектору RFC 5869 (случай 1): PRK и OKM должны совпасть побайтово.
3. Из одного секрета выработайте три ключа: для шифрования (info = b"enc"), для MAC (info = b"mac") и для nonce (info = b"nonce"). Убедитесь, что все три различны.
4. Покажите, что смена info на один байт меняет ключ полностью.
5. Объясните, что произойдёт, если использовать один и тот же ключ и для шифрования, и для MAC.

Что должно получиться

Работающий HKDF, совпадение с вектором и три независимых ключа. Вывод: разделение по назначению — не формальность, а требование, без которого свойства примитивов смешиваются.

Часть 6. Хранилище «Сейф»

Задание

1. Соберите хранилище: пароль пользователя → scrypt → ключ хранилища (KEK) → случайный ключ данных (DEK) → AES-GCM для полезной нагрузки.
2. Формат файла: MAGIC | соль(16) | параметры scrypt | обёрнутый DEK | nonce(12) | ct | tag.
3. Реализуйте открытие хранилища: разбор заголовка, выработка KEK из пароля, разворачивание DEK, расшифрование.
4. Проверьте, что неверный пароль даёт ошибку аутентификации, а не мусор; что подмена байта в обёрнутом DEK обнаруживается; что подмена полезной нагрузки обнаруживается.
5. Обсудите, зачем нужен отдельный DEK, если можно шифровать прямо ключом из пароля (ответ: смена пароля требует только переупаковки DEK, а не перешифрования данных).

Что должно получиться

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

Журнал работы

По каждой части: предсказание, команда, результат, объяснение. Для части 2 предсказание — сколько записей вскроется и за какое время, для части 3 — объём памяти при данных параметрах, для части 6 — что именно обнаружит проверка. Все измерения полезно свести в одну таблицу и сравнить с оценками из теории: расхождение в два раза нормально, расхождение в сто раз означает ошибку в методике.

Критерии проверки

Работа считается выполненной, если:

• проверки check_kdf.py завершаются без ошибок;
• форматы хешей сравнены по скорости подбора, параметры подобраны под целевое время на своей машине, HKDF совпал с RFC 5869, хранилище открывается только верным паролем;
• измерения и наблюдения записаны в журнал вместе с объяснением расхождений с предсказанием;
• на контрольные вопросы даны ответы своими словами, а не пересказ команд.

Контрольные вопросы

1. Почему хранение пароля «просто хешем» недостаточно даже при стойкой хеш-функции?
2. Какую роль играет соль и почему она не обязана быть секретной?
3. Чем «перец» отличается от соли и в каком сценарии он помогает?
4. Почему PBKDF2 плохо сопротивляется перебору на видеокартах, а scrypt — лучше?
5. Как параметры scrypt связаны с объёмом памяти и почему это ограничивает параллелизм?
6. Чем Argon2id отличается от Argon2d и Argon2i и почему выбран гибрид?
7. Почему NIST SP 800-63B не рекомендует правила сложности и принудительную ротацию паролей?
8. Чем KDF из пароля отличается от KDF из секрета и что будет, если их перепутать?
9. Что делают шаги extract и expand в HKDF и зачем нужен параметр info?
10. Почему нельзя использовать один ключ и для шифрования, и для MAC?
11. Зачем нужно обёртывание ключей и что даёт AES-KW по сравнению с обычным шифрованием?
12. Почему при смене пароля хранилища не требуется перешифровывать все данные?