Как работает password_hash?

Я пытаюсь понять password_hash полностью, чтобы иметь возможность объяснить это для аудитора.

Основываясь на моем поиске ответа, я понимаю, что функция password_hash() является оболочкой для crypt() . При чтении руководства по PHP для предопределенных констант я вижу, что он использует значение PASSWORD_BCRYPT как целочисленное значение по умолчанию (в основном он использует алгоритм CRYPT_BLOWFISH для хеширования пароля).

Меня смущает то, что переменная $options , если она опущена, генерирует случайную соль, а стоимость будет установлена ​​равной 10 . Если я поставлю более высокую стоимость (например: 12 ), будет ли она по-прежнему генерировать случайную соль, поскольку я не поставляю значение соли? Причина, по которой меня путают, состоит в том, что я не пропускаю $options но вместо этого предлагаю другую стоимость.

Мои другие вопросы:

  • Почему повышение стоимости повышает безопасность?
  • Как, поскольку password_hash() является односторонней хэширующей функцией, password_verify() проверяет пароль, поскольку соль случайна?
  • Является ли CRYPT_SHA512 сильнее, чем CRYPT_BLOWFISH для хеширования?

Я считаю эту статью невероятно полезной, чтобы понять, как правильно хеш-пароли. В нем объясняется, как хеши могут быть взломаны различными методами, если хеши слабые, и как правильно использовать хэш-пароли для обеспечения достаточной безопасности.

Если я поставлю более высокую стоимость (скажем, 12), она все равно будет генерировать случайную соль, так как я не поставляю значение соли

Да, это будет так, как указано в документации, если соль будет опущена, случайная соль будет сгенерирована с помощью пароля_hash () для каждого хэша пароля (это означает, что если вы опустите значение соли из вашего массива параметров, оно будет сгенерировано функцией password_hash () defaultly). Кроме того, опция соля была устарела с php 7.0 .

почему увеличивается стоимость повышения стоимости?

Это также объясняется в приведенной выше статье в разделе « Создание трещин паролем»: медленные функции хеширования . Чем выше стоимость, тем медленнее будет хеш-функция. Идея состоит в том, чтобы сделать хеш-функцию очень медленной, так что даже с быстрым графическим процессором или специальным оборудованием, словарные и грубые атаки слишком медленны, чтобы быть полезными. Однако стоимость должна быть рассчитана на разумную величину (на основе характеристик вашего сервера), так что при проверке паролей пользователей она не вызывает значительных временных задержек.

Более того, CRYPT_SHA512 сильнее, чем CRYPT_BLOWFISH для хеширования?

Прочитайте это сообщение об их сравнении.

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

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

Стоимость (экспоненциальное значение) относится к тому, сколько усилий прилагается к генерации хэша (где выше = больше вычислительной мощности для генерации хэша). Не устанавливайте его слишком высоко, иначе вы будете заглушать скрипты входа.

Вообще говоря:

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

Но bcrypt обрабатывает соление самостоятельно!

Вернуться к исходному вопросу:

Стоимость используется, чтобы «дорого» взломать пароль с помощью атаки словаря / грубой силы.

Bcrypt в основном хэширует пароль снова и снова, что делает его трудоемким (= дорогостоящим) для получения пароля для заданного хэша. Если вы попытаетесь найти пароль для хэша (принудительная атака), вам нужно рассчитать миллиарды хэшей паролей. Когда каждый хешинг занимает «$ cost» раз дольше, тогда грубая силовая атака невозможна. Даже если вы можете рассчитать хэш для потенциального пароля в миллисекундах.

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

Предположим, вы используете хорошую соль и достаточно длинный пароль, тогда вам понадобится что-то вроде 1-5 секунд для хэша паролей. Если вы используете подход blowfish с стоимостью = 10, вам понадобится 10-50 секунд для хэша пароля. Для одного пароля это не имеет большого значения. Таким образом, направленная атака на один хеш все еще прост, но обычно люди получают большие списки комбинаций пользователей и паролей, и им интересно быстро получить пароли для всех. Тогда это гораздо менее прибыльный для плохого парня, поскольку ему нужно в 10 раз больше мощности процессора, чтобы вычислить все это.