PBKDF2 Генератор хешей
Бесплатный онлайн-инструмент PBKDF2 Генератор хешей. 100% локальная обработка — ваши данные никогда не покидают устройство.
Результат будет отображен здесь...
Ввод → Вычислить хеш
Usage Guide
О PBKDF2
PBKDF2 (Функция формирования ключа на основе пароля 2) — функция формирования ключа, стандартизированная в RFC 8018 (PKCS#5) и NIST SP 800-132. В отличие от простой хэш-функции, PBKDF2 специально разработана для получения криптографического ключа из пароля путём многократного применения псевдослучайной функции (HMAC-SHA256 или HMAC-SHA512) — сотни тысяч раз. Это делает перебор паролей вычислительно дорогостоящим. PBKDF2 соответствует стандарту FIPS 140-2 и широко применяется в шифровании дисков LUKS, Wi-Fi WPA2/WPA3, защищённом хранилище iOS/Android и менеджерах паролей.
Шаги использования
Инструмент поддерживает две операции: формирование ключа (режим шифрования) и проверка пароля (режим расшифровки):
Руководство по параметрам
PBKDF2 имеет четыре ключевых параметра, определяющих безопасность и результат формирования ключа:
PBKDF2 против Argon2 / bcrypt
Понимание того, когда выбирать PBKDF2 вместо других алгоритмов хэширования паролей:
FAQ
Q: Каков формат вывода PBKDF2?
A: Инструмент выводит самодостаточную строку хэша: {итерации}:{алгоритм}:{соль_base64}:{производный_ключ_hex}.
Например: 600000:sha256:abc123...==:d4e5f6....
Компоненты:итерации: количество использованных раундов HMAC (например, 600000).алгоритм: хэш-функция (sha256 или sha512).соль_base64: случайная соль в кодировке Base64.производный_ключ_hex: производный ключ в шестнадцатеричной кодировке.
Для проверки введите в режиме расшифровки: пароль|{полная строка хэша}.
Q: Почему PBKDF2 требует 600 000 итераций?
A: PBKDF2 не является memory-hard — его можно дёшево параллелизовать на GPU. Современный GPU может вычислять около 1–2 миллиардов итераций PBKDF2-SHA256 в секунду. При 600 000 итерациях на хэш GPU всё равно может делать ~1600 попыток в секунду. Высокое число итераций — основной механизм защиты, напрямую умножающий затраты атакующего. OWASP 2023 устанавливает 600 000 как минимум для SHA-256; для SHA-512 используйте 210 000. Увеличивайте эти значения со временем.
Q: Чем PBKDF2 отличается от bcrypt или Argon2?
A: PBKDF2: только computation-hard, не memory-hard. Параллелизуем на GPU. Одобрен FIPS 140-2. Требует очень большого числа итераций. Идеален для FIPS-регулируемых сред. bcrypt: computation-hard, ~4 КБ памяти, умеренная устойчивость к GPU. Ограничение 72 байта для пароля. Не может формировать ключи произвольной длины. Argon2id: memory-hard, устойчив к GPU/ASIC, современное предпочтение OWASP. Не одобрен FIPS. Производительность при равной безопасности: Argon2 значительно быстрее PBKDF2 при том же эффективном уровне безопасности благодаря устойчивости к памяти.
Q: Соответствует ли PBKDF2 стандарту FIPS 140-2?
A: Да. PBKDF2 явно определён в NIST SP 800-132 и одобрен по FIPS 140-2. Это делает его обязательным выбором для федеральных агентств США, подрядчиков, медицинских систем под HIPAA и финансовых приложений с требованиями PCI-DSS. Argon2 и scrypt не одобрены FIPS. При необходимости соответствия FIPS PBKDF2 — единственный широко доступный вариант на сегодняшний день. Убедитесь, что ваша реализация PBKDF2 использует криптографический модуль с валидацией FIPS.
Q: Почему соль важна и её нужно хранить?
A: Соль — случайное значение, добавляемое к паролю перед хэшированием, чтобы два одинаковых пароля давали разные производные ключи. Без соли злоумышленники могут использовать заранее вычисленные радужные таблицы для одновременного взлома нескольких хэшей. Соль не обязана быть секретной — она лишь должна быть уникальной для каждого пароля. Соль включена в строку вывода и должна храниться вместе с производным ключом для воспроизведения того же хэша при проверке. Никогда не используйте одну соль для разных паролей.
Q: Как использовать PBKDF2 для формирования ключа AES?
A: Установите длину ключа 32 байта (256 бит), чтобы напрямую получить ключ AES-256. Используйте 600 000 итераций с SHA-256. Храните соль вместе с зашифрованными данными. При расшифровке заново сформируйте ключ с тем же паролем, солью, итерациями и алгоритмом, затем используйте его для расшифровки с помощью AES-256-GCM. Именно так работают шифрование диска LUKS, защита данных iOS и многие менеджеры паролей. Производный ключ детерминирован — одинаковые входные данные всегда дают одинаковый ключ.
Use Cases
Рекомендуется: Хранение паролей с соответствием FIPS
Организации, подпадающие под FIPS 140-2, NIST SP 800-131A, HIPAA или PCI-DSS, обязаны использовать одобренные криптографические алгоритмы. PBKDF2 с HMAC-SHA256 или HMAC-SHA512 — единственная широко доступная KDF для паролей, отвечающая этим требованиям. Используйте не менее 600 000 итераций для SHA-256 и храните полную строку вывода. Это главная причина выбирать PBKDF2 вместо Argon2id в регулируемых средах.
- ✅ PBKDF2-HMAC-SHA256 (≥600 000 итераций) — соответствует FIPS
- ✅ PBKDF2-HMAC-SHA512 (≥210 000 итераций) — соответствует FIPS
- ❌ Argon2 / scrypt — не одобрены FIPS 140-2
- ❌ bcrypt — не одобрен FIPS 140-2
Рекомендуется: Формирование ключа для шифрования диска (LUKS)
LUKS (Linux Unified Key Setup) по умолчанию использует PBKDF2 (LUKS1) и PBKDF2/Argon2 (LUKS2) для формирования ключа шифрования тома из кодовой фразы. PBKDF2 формирует ключ фиксированной длины (32 байта для AES-256) из пароля пользователя, который затем используется для шифрования мастер-ключа, хранящегося в заголовке LUKS. Безопасность Wi-Fi WPA2/WPA3 также использует PBKDF2 для формирования попарного мастер-ключа (PMK) из пароля Wi-Fi.
- ✅ PBKDF2-HMAC-SHA512 (стандарт LUKS1)
- ✅ Argon2id (предпочтительно для LUKS2 — лучшая устойчивость к памяти)
- 💡 Устанавливайте итерации достаточно высокими, чтобы формирование занимало 0,5–2 секунды на целевом оборудовании
- 💡 Храните соль в метаданных диска/заголовка, никогда отдельно
Допустимо: Проверка паролей в устаревших системах
Многие существующие системы (старые версии Django, .NET Membership, Java PBKDF2WithHmacSHA1) уже хранят хэши PBKDF2. Продолжайте использовать PBKDF2 для этих систем и постепенно увеличивайте число итераций по мере совершенствования оборудования. Используйте сохранённое число итераций для проверки (оно встроено в строку хэша) и обновляйте до актуальных рекомендаций OWASP для новых регистраций и смен пароля. Это позволяет избежать принудительного сброса паролей, улучшая безопасность со временем.
- ✅ PBKDF2 (сохранить для существующих хэшей — миграция не требуется)
- ✅ Увеличивать итерации для новых хэшей до текущего минимума OWASP
- 💡 Прозрачно обновлять число итераций при следующем входе
- 💡 Рассмотреть миграцию на Argon2id для новых проектов, если FIPS не требуется
Допустимо: Формирование нескольких ключей из одного пароля
PBKDF2 может формировать ключи произвольной длины, что удобно, когда из одного мастер-пароля нужно несколько ключей (например, один для шифрования, другой для MAC-аутентификации). Используйте разные соли или суффиксы индексов для независимых ключей. Установите длину ключа 64 байта и разделите вывод на два 32-байтных ключа, или запустите PBKDF2 дважды с разными солями. Эта схема используется в некоторых архитектурах менеджеров паролей.
- ✅ Использовать разные соли для каждого назначения производного ключа
- ✅ Использовать HKDF для расширения ключа после первоначального формирования PBKDF2
- ❌ Никогда не использовать одну соль для разных целей ключа
- 💡 Сочетать с AES-256-GCM для аутентифицированного шифрования
Не рекомендуется: Замена Argon2 в новых проектах
Если вы запускаете новый проект без требований FIPS, PBKDF2 является более слабым выбором по сравнению с Argon2id. PBKDF2 не является memory-hard, а значит GPU могут дёшево параллелизовать атаки. Даже при 600 000 итерациях один высокопроизводительный GPU может делать тысячи попыток PBKDF2 в секунду. Argon2id с параметрами по умолчанию (47 МБ памяти, 1 итерация) достигает сравнимого времени выполнения, полностью исключая параллелизацию GPU за счёт требований к памяти.
- ❌ Избегать PBKDF2 в новых проектах, когда доступен Argon2id
- ✅ Argon2id (memory-hard, предпочтение OWASP)
- ✅ scrypt (memory-hard, широко доступен)
- 💡 PBKDF2 предпочтителен только при обязательном соответствии FIPS
Не рекомендуется: Общее хэширование данных
PBKDF2 — это функция формирования ключа, а не хэш-функция общего назначения. Она намеренно медленная и никогда не должна использоваться для хэширования содержимого файлов, контрольных сумм, аутентификации сообщений или дедупликации. Для целостности данных используйте SHA-256 или SHA-512. Для аутентификации сообщений используйте HMAC-SHA256. Использование вывода PBKDF2 как обычного хэша приведёт к значительным напрасным затратам ЦП без какой-либо пользы для безопасности.
- ❌ Не использовать PBKDF2 для контрольных сумм файлов или целостности данных
- ❌ Не использовать PBKDF2 для аутентификации сообщений (использовать HMAC-SHA256)
- ✅ SHA-256 / SHA-512 для общего хэширования данных
- ✅ HMAC-SHA256 для аутентифицированной целостности сообщений
Сводка лучших практик
- Используйте PBKDF2-HMAC-SHA256 (≥600 000 итераций) или HMAC-SHA512 (≥210 000) для FIPS-совместимых сред. Храните полную строку хэша, включая итерации, алгоритм и соль.
- Для новых проектов без требований FIPS предпочтительнее Argon2id — он является memory-hard и значительно устойчивее к атакам GPU при сравнимой производительности.
- Всегда используйте уникальную случайную соль для каждого пароля (автоматически генерируется этим инструментом). Никогда не повторяйте соли и не встраивайте их в код приложения.
- Увеличивайте число итераций со временем по мере совершенствования оборудования. Число итераций хранится в строке хэша, поэтому старые и новые значения могут сосуществовать.
- Используйте PBKDF2 только при входе или настройке ключа — никогда при каждом запросе. После аутентификации выдавайте токены (JWT, сессии) для высокочастотных операций.