Как расшифровать хеш bcrypt

Обновлено: 07.07.2024

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

4 ответа

У меня есть этот hash, сгенерированный с помощью функции crypt в php: $1$jV3.NS/.$JLVMBWe0N/W0Rbft4NgPV . Я знаю, что $1$ -это hash MD5, jV3.NS/. -соль, а другой текст-зашифрованная строка. Можно ли расшифровать этот hash, если я знаю соль?

Тебе HASHING, а не ENCRYPTING!

В чем разница?

Разница в том, что хэширование-это односторонняя функция, а шифрование-двусторонняя функция.

Итак, как вы можете убедиться, что пароль правильный?

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

Должны ли вы hash или шифровать пароли?

То, что вы сейчас делаете-хеширование паролей-правильно. Если бы вы просто шифровали пароли, нарушение безопасности вашего приложения могло бы позволить злоумышленнику тривиально узнать все пароли пользователей. Если у вас hash (или лучше, соль и hash ) пароля, пользователю необходимо взломать пароли (что является вычислительно дорогостоящим на bcrypt ), чтобы получить эти знания.

Поскольку ваши пользователи, вероятно, используют свои пароли в нескольких местах, это поможет защитить их.

Ты просто не можешь .

bcrypt использует соление, разных раундов, я обычно использую 10.

Это 10 солит случайную строку в ваш пароль.

Чтобы ответить на оригинальный вопрос плакатов . чтобы 'decrypt' пароль, вы должны сделать то, что сделал бы взломщик паролей.

Другими словами, вы запустили бы программу для чтения из большого списка потенциальных паролей (словарь паролей), и вы бы hash каждый из них использовал bcrypt и соль и сложность пароля, который вы пытаетесь расшифровать. Если Вам повезет, вы найдете совпадение, но если пароль сильный, то вы, скорее всего, не найдете совпадения.

Bcrypt имеет дополнительную характеристику безопасности-быть медленным hash. Если бы ваш пароль был хэширован с помощью md5 (ужасный выбор), то вы могли бы проверять миллиарды паролей в секунду, но поскольку он хэшируется с помощью bcrypt , вы сможете проверять гораздо меньше паролей в секунду.

Тот факт, что bcrypt медленно превращается в hash и солится, делает его хорошим выбором для хранения паролей даже сегодня. Тем не менее, я считаю, что NIST рекомендует PBKDF2 для хэширования паролей.

Понимание BCrypt хэширования

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

BCrypt хэш выглядит так $2a$13$ZyprE5MRw2Q3WpNOGZWGbeG7ADUre1Q8qo.uUUtcbqloU0yvzavOm , и у него есть определенный порядок. Первый кусочек хэша $2a определяет, какой хэш-алгоритм был использован. Следующая часть $13 определяет стоимость. Стоимость - это примерно то, сколько мощности требуется для вычисления хэша. Она находится по логарифмической шкале 2^стоимость и определяет, сколько раз данные проходят через алгоритм хеширования. Например, при стоимости 10 вы можете хэшировать 10 паролей в секунду на среднем компьютере, при стоимости 15 это занимает 3 секунды на хэш…, при стоимости 31 вычисление хэша займет несколько дней. На сегодня, стоимость 12 считается достаточно безопасной. Последняя часть вашего хэша $ZyprE5MRw2Q3WpNOGZWGbeG7ADUre1Q8qo.uUUtcbqloU0yvzavOm, выглядит как одна большая строка цифр, точек и букв, но на самом деле это два отдельных куска информации. Первые 22 символа - это соль в обычном тексте, а остальные - хэшированный пароль.

Чтобы начать использованием bcrypt, сначала установите его.

npm install bcrypt

А затем подключите и определите несколько констант для дальнейших примеров:

Более подробно о node.bcrypt.js читайте здесь.

Хеширование и сравнение паролей асинхронно

Чтобы хэшировать пароль:

Метод 1 (генерация соли и хэша при отдельных вызовах функций):

Метод 2 (автогенерация соли и хэша)

Обратите внимание, что оба метода дают один и тот же конечный результат.

Чтобы проверить пароль:

Почему асинхронный режим рекомендуется использовать вместо синхронного режима? Если вы используете bcrypt на простом скрипте, то использование синхронного режима совершенно нормально. Однако, если вы используете bcrypt на сервере, рекомендуется использовать асинхронный режим. Это связано с тем, что хэширование, выполняемое bcrypt, требует больших затрат процессора, поэтому синхронная версия заблокирует цикл событий и не позволит вашему приложению обслуживать любые другие входящие запросы или события. Асинхронная версия использует пул потоков, который не блокирует основной цикл событий.

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

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

Добавьте это в существующую хэш-функцию (поскольку вам нужно дождаться завершения хэша перед вызовом функции сравнения) после того, как вы выведите завершенный хэш и выведите “res” в консоль внутри compare. Вы должны увидеть в консоли хэш, а затем напечатать “true”! Если вы измените ‘myPlaintextPassword ‘в функции сравнения на’ какой-то другой пароль обычного текста’, то он должен сказать false.

Хэширование и сравнение паролей синхронно

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

Теперь, чтобы сравнить ввод пароля с новым хэшем, вы должны использовать метод compareSync:

Было обнаружено, что 79% участников недавнего опроса ZoneAlarm используют рискованные пароли. Данные были использованы для представления очень стильной инфографики, показывающей, насколько широко распространено использование плохих паролей. Но независимо от того, насколько сложно угадать хорошие пароли, их может быть не сложнее взломать, чем плохие, в зависимости от того, как хранится пароль.

BCrypt

Bcrypt может расширить так называемый ключевой фактор, чтобы компенсировать все более мощные компьютеры и эффективно «замедлять» скорость хэширования. Изменение ключевого фактора также влияет на результат хэширования, так что это делает Bcrypt чрезвычайно устойчивым к атакам на основе радужных таблиц. Более новые компьютеры могут пытаться угадать исходный ввод хеша, но все равно потребуется столько же времени (или дольше), чтобы проверить, соответствует ли его предположение или нет. Все это делает Bcrypt почти будущим!

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

Насколько медленнее bcrypt, чем, скажем, MD5? Зависит от фактора работы. Используя коэффициент работы 12, bcrypt хэширует пароль yaaa примерно за 0.3 секунды на моем ноутбуке. MD5, с другой стороны, занимает меньше микросекунды.

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

Чтобы оценить возможности Bcrypt, давайте сравним их с подходящим алгоритмом хеширования, таким как SHA-2. SHA-2 не использует никаких криптографических алгоритмов, но вместо этого использует алгоритм хеширования для генерации его выходных данных (хотя алгоритмы как SHA-2, так и Blowfish могут выдерживать очень похожий уровень проверки). Bcrypt намного медленнее, чем SHA-2, и, следовательно, теоретически лучше. SHA-2 также не адаптивен, как Bcrypt и его ключевой фактор, поэтому он будет более восприимчивым к атакам на основе таблиц по мере увеличения вычислительной мощности компьютера. SHA-2 на данный момент является полностью способной функцией хэширования, но Bcrypt выигрывает, потому что это скорость (с хэшированием, чем медленнее, тем лучше) и адаптивность.

Bcrypt – представляет собой функцию хэширования паролей, основанную на шифре Blowfish. Впервые была представлена в USENIX в 1999 году разработчиками Niels Provos и David Mazières. Помимо включения salt для защиты от атаки Rainbow Table, bcrypt является адаптивной функцией: со временем, счетчик итераций может быть увеличен, чтобы сделать процесс медленнее, и таким образом повысить устойчивость к Brute-forse, даже с увеличением вычислительной мощности.

Содержание

Blowfish примечателен среди блочных шифров для его дорогостоящей фазы настройки ключа. Он начинается с подключений в стандартном состоянии, затем использует это состояние для выполнения блочного шифрования с использованием части ключа и использует результат этого шифрования (более точно хеширование) для замены некоторых из подраздела. Затем он использует это измененное состояние для шифрования другой части ключа и использует результат для замены большего количества подразделов. Это происходит таким образом: используется прогрессивно измененное состояние для хеширования ключа и замены бит состояния, пока не будут установлены все подразделы.

Прово и Мазьер воспользовались этим и продолжили. Они разработали новый алгоритм настройки ключей для Blowfish, дублируя полученный шифр «Eksblowfish» («дорогой ключевой график Blowfish»). Настройка ключа начинается с измененной формы стандартной настройки ключа Blowfish, в которой и salt, и пароль используются для установки всех подразделов. Затем выполняется ряд раундов, в которых применяется стандартный алгоритм Key Blowfish, используя альтернативу salt и пароль в качестве ключа, каждый раунд, начинается с состояния подраздела из предыдущего раунда. Теоретически это не более сильное, чем стандартное расписание ключевых событий Blowfish, но количество раундов переключения настраивается; поэтому этот процесс можно сделать произвольно медленным, что помогает предотвратить атаки грубой силы на хэш или salt.

Например, запись теневого пароля $2a$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWyуказывает параметр стоимости 10, что указывает на 2 10 раундов расширения ключа. Salt тут N9qo8uLOickgx2ZMRZoMyeи полученный хеш IjZAgcfl7p92ldGxad68LJZdL17lhWy. В стандартной практике пароль пользователя не сохраняется.

В исходной спецификации Bcrypt определен префикс $2$. Это следует за форматом Modular Crypt Format, используемым при хранении паролей в файле паролей OpenBSD:

$1$: MD5
$2$: Bcrypt
$sha1$: SHA-1
$5$: SHA-256
$6$: SHA-512

Изначально, в спецификации не значилось, как обрабатывать не-ASCII-символ и нулевой ограничитель, поэтому она была дополнена, чтобы утвердить следующие положения:

строка должна кодироваться в кодировке UTF-8
нулевой ограничитель должен быть включен

С этим изменением версия была изменена на $2a$]

Никто, включая канонический OpenBSD, не принял идею 2x / 2y. Это изменение маркера версии было ограничено crypt_blowfish .

BCrypt был создан для OpenBSD. Когда у них была ошибка в их библиотеке, они решили поднять номер версии.

Алгоритм bcrypt является результатом шифрования текста «OrpheanBeholderScryDoubt» 64 раза с использованием Blowfish. В bcrypt обычная функция настройки ключа Blowfish заменяется функцией дорогостоящей настройки ключа (EksBlowfishSetup):

Алгоритм bcrypt в значительной степени зависит от алгоритма настройки ключа «Eksblowfish», который работает следующим образом: Function EksBlowfishSetup

InitialState работает как в оригинальном алгоритме Blowfish, заполняя записи P-массива и S-box дробной частью Pi в шестнадцатеричном формате.

Функция ExpandKey выполняет следующие действия: Function ExpandKey(state, salt, password)

Многие реализации bcrypt урезают пароль до первых 72 байтов. Сам математический алгоритм требует инициализации с 18 32-разрядными подразделами (эквивалентно 72 октетам / байтам). Исходная спецификация bcrypt не предусматривает какого-либо одного конкретного метода для преобразования паролей на основе текста из userland в числовые значения для алгоритма. Один краткий комментарий в тексте упоминает, но не дает мандата, о возможности просто использовать кодированное значение ASCII символьной строки: «Наконец, ключевым аргументом является секретный ключ шифрования, который может быть выбранным пользователем паролем до 56 байтов (включая завершающий нулевой байт, когда ключ является строкой ASCII)".

Обратите внимание, что в приведенной выше цитате упоминаются пароли «до 56 байтов», хотя сам алгоритм использует начальное значение в 72 байта. Хотя Provos и Mazières не указывают причину более короткого ограничения, они, возможно, были мотивированы следующим утверждением от первоначальной спецификации Bruce Schneier «Blowfish» «Ограничение по размеру ключа 448 [бит] гарантирует, что [ sic ] каждый бит каждого подраздела зависит от каждого бита ключа".

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

Читайте также: