bcrypt Генератор хешей
Бесплатный онлайн-инструмент bcrypt Генератор хешей. 100% локальная обработка — ваши данные никогда не покидают устройство.
Результат будет отображен здесь...
Ввод → Вычислить хеш
Usage Guide
О bcrypt
bcrypt — функция хэширования паролей, разработанная Нильсом Провосом и Дэвидом Мазьером в 1999 году на основе шифра Blowfish. Она специально создана для работы медленно и с высокими вычислительными затратами, делая атаки перебором нецелесообразными. bcrypt является одним из наиболее широко используемых алгоритмов хэширования паролей в мире и нативно поддерживается такими фреймворками, как Rails, Django, Laravel и Node.js (bcryptjs). Каждый хэш bcrypt содержит встроенную случайную соль и коэффициент стоимости, поэтому хэш полностью самодостаточен для проверки.
Шаги использования
Инструмент поддерживает две операции: хэширование пароля (Зашифровать) и проверка пароля по хэшу (Расшифровать):
Особенности алгоритма
bcrypt обладает несколькими свойствами, делающими его подходящим для хранения паролей:
Руководство по выбору коэффициента стоимости
Правильный коэффициент стоимости обеспечивает баланс между безопасностью и производительностью сервера:
FAQ
Q: Каков формат вывода bcrypt?
A: Хэш bcrypt всегда состоит ровно из 60 символов и выглядит так: $2b$12$LQv3c1yqBWVHxkd0LHAkCOYz6TtxMQJqhN8/lewdBdXyXu2zXpOme.
Разбивка:$2b$: Идентификатор версии bcrypt.12$: Коэффициент стоимости.
Следующие 22 символа: случайная 128-битная соль в кодировке Base64.
Последние 31 символ: производный 184-битный хэш в кодировке Base64.
Ключевое свойство: Все параметры встроены в строку — для последующей проверки пароля не требуется дополнительного хранилища.
Q: Как bcrypt сравнивается с Argon2?
A: bcrypt (1999): сложный вычислительно, ~4 КБ памяти, умеренная устойчивость к GPU, универсальная поддержка. Argon2 (2015): сложный по памяти (настраиваемый, по умолчанию 64 МБ), значительно более высокая устойчивость к ASIC/GPU, предпочтителен OWASP и NIST. Когда использовать bcrypt: При поддержке существующей системы или когда Argon2 ещё недоступен. Когда использовать Argon2: Все новые проекты.
Q: Почему bcrypt нельзя использовать для хэширования файлов или больших данных?
A: bcrypt имеет ограничение ввода в 72 байта. Символы после 72-го байта молча игнорируются. Для целостности файлов используйте SHA-256 или SHA-512. bcrypt предназначен специально только для коротких паролей, вводимых вручную.
Q: Безопасен ли bcrypt в случае компрометации базы данных?
A: Да — хэш bcrypt является односторонним. При cost=12 одно ядро CPU может предпринять примерно 2–5 попыток хэширования в секунду, что делает исчерпывающие атаки на надёжные пароли практически невозможными. Однако bcrypt не защищает слабые пароли — всегда применяйте политику минимальной надёжности пароля.
Q: Какой коэффициент стоимости использовать в продакшене?
A: Рекомендация OWASP 2023: cost=12 в качестве базового уровня. Выполните бенчмарк на своём производственном сервере и выберите наибольший коэффициент стоимости, при котором хэширование занимает менее 500 мс. Никогда не снижайте ниже cost=10. Пересматривайте каждые 2–3 года по мере улучшения оборудования.
Q: Можно ли использовать bcrypt для хранения API-ключей или токенов?
A: Да, с оговорками. bcrypt подходит для хэширования API-ключей и токенов длиной менее 72 байт и редко проверяемых. Для высокочастотной проверки используйте вместо этого быстрый подход SHA-256 + соль.
Use Cases
Рекомендуется: Хранение паролей пользователей
Это основной сценарий использования bcrypt. Хэшируйте с bcrypt (cost ≥ 12) и сохраняйте 60-символьную строку. При входе выполняйте проверку bcrypt. bcrypt поддерживается «из коробки» в Rails (has_secure_password), Django, Laravel и Node.js (bcryptjs).
Рекомендуется: Совместимость с устаревшими системами
Для систем, хранящих миллионы хэшей bcrypt, продолжайте использовать bcrypt и повышайте коэффициент стоимости по мере улучшения оборудования. Новые пользователи могут прозрачно перейти на Argon2id, тогда как хэши bcrypt (идентифицируемые по префиксу $2b$) продолжат корректно проверяться.
- ✅ Сохранять bcrypt для существующих хэшей — принудительная миграция не требуется
- ✅ Постепенно внедрять Argon2id для новых и обновляемых паролей
- ✅ Использовать определение префикса хэша ($2b$ vs $argon2id$) для маршрутизации проверки
- 💡 Регистрировать используемый алгоритм для каждого пользователя для отслеживания прогресса миграции
Допустимо: Хэширование API-ключей
bcrypt может хэшировать API-ключи перед сохранением в базе данных. Для проверки на каждый запрос в масштабе предпочитайте быструю схему HMAC-SHA256 или хэш SHA-256 ключа.
- ✅ bcrypt (cost=10–12, подходит для низкочастотной проверки)
- ✅ SHA-256 + соль (быстрее, подходит для ключей с высокой энтропией)
- ✅ HMAC-SHA256 (для подписи токенов на каждый запрос)
- 💡 Использовать префикс хэша (первые 8 символов) как индекс базы данных для быстрого поиска
Не рекомендуется: Шифрование файлов или данных
bcrypt — это односторонняя хэш-функция, не алгоритм шифрования. Он не может шифровать файлы. Кроме того, ограничение ввода в 72 байта делает его непригодным для хэширования содержимого файлов. Для шифрования файлов используйте симметричный шифр (например, AES-256-GCM).
- ❌ Не использовать bcrypt для шифрования файлов (необратим)
- ❌ Не хэшировать данные длиннее 72 байт с помощью bcrypt
- ✅ Использовать AES-256-GCM для симметричного шифрования файлов
- ✅ Использовать Argon2id или scrypt для формирования ключей на основе пароля
Не рекомендуется: Хэширование данных общего назначения
bcrypt слишком медленный для проверки целостности данных общего назначения. Используйте SHA-256 или SHA-512 для проверки целостности.
- ❌ Не использовать bcrypt для проверки целостности данных или хэширования контента
- ✅ SHA-256 (хэширование целостности общего назначения)
- ✅ BLAKE2b (высокоскоростное криптографическое хэширование)
- ✅ SHA-3 / SHA-512 (более высокий запас безопасности)
Не рекомендуется: Высокочастотная аутентификация
bcrypt спроектирован для медленной работы (~200–500 мс при cost=12). Его запуск при каждом API-запросе перегрузит ваш сервер. Используйте bcrypt только один раз при входе — затем выдавайте подписанный JWT для последующих запросов.
- ❌ Не запускать bcrypt при каждом API-запросе
- ✅ JWT + HMAC-SHA256 (stateless, быстрая аутентификация на каждый запрос)
- ✅ Session + Cookie (традиционное управление сессиями на стороне сервера)
- ✅ OAuth 2.0 / OpenID Connect (федеративная идентификация, на основе токенов)
Сводка лучших практик
- Использовать bcrypt (cost ≥ 12) для хранения паролей пользователей в существующих системах. Для новых проектов предпочитать Argon2id.
- Никогда не использовать bcrypt для хэширования данных общего назначения, шифрования файлов или данных объёмом более 72 байт.
- Выполнять бенчмарк на производственном оборудовании и стремиться к 200–500 мс на хэш. Повышать коэффициент стоимости каждые 2–3 года.
- Для сценариев высокочастотной аутентификации использовать bcrypt только при входе, затем выдавать JWT или сессионные токены.
- Постепенная миграция с bcrypt на Argon2id: сохранять bcrypt для существующих хэшей, использовать Argon2id для новых паролей.