проблема здесь в основном проблема энтропии. Так что давайте начнем искать там:

Энтропия На Символ

количество бит энтропии на байт:

• Символы
  • биты: 4
  • значения: 16
  • энтропия в 72 символах: 288 бит
• Альфа-Числовые
  • биты: 6
  • значения: 62
  • энтропия в 72 символов: 432 бит
• "Общие" Символы
  • бит: 6.5
  • значения: 94
  • энтропия в 72 символах: 468 бит
• Полный Байт
  • бит: 8
  • значения: 255
  • энтропия в 72 символах: 576 бит

Итак, как мы действуем, зависит от типа персонажей мы ожидаем.

Первая Проблема

первая проблема с вашим кодом, это ваш "перец" шаг хэша выводит шестнадцатеричные символы (начиная с четвертого параметра до hash_hmac() не установлен).

поэтому, хешируя свой перец, вы эффективно сокращаете максимальную энтропию, доступную паролю, в 2 раза (от 576 до 288 возможно bits).

Второй Проблема

однако, sha256 представлена только 256 биты энтропии в первую очередь. Таким образом, вы эффективно сокращаете возможные 576 бит до 256 бит. Ваш шаг хэша * немедленно*, по самому определению проигрывает по крайней мере 50% от возможно энтропии в пароле.

вы можете частично решить эту проблему, переключившись на SHA512, где вы только уменьшите доступную энтропию примерно на 12%. Но это все-таки не так уж и незначительно разница. Это на 12% уменьшает количество перестановок в разы 1.8e19. Это большое число... И это фактор уменьшает его...

Основная Проблема

основная проблема заключается в том, что существует три типа паролей более 72 символов. Влияние, которое эта система стилей оказывает на них, будет очень разным:

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

• высокая энтропия случайных паролей

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

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

  позвольте мне сказать это снова. Для пользователей, которые используют высокую энтропию, длинные пароли, решения значительно уменьшает силу их пароля на измеримую величину. (62 бита энтропии потеряно для 72 символов пароля, и больше для более длинных паролей)

• случайные пароли средней энтропии

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

  для этой группы, вы собираетесь немного разблокировать больше энтропии (не создавать его, но позволить больше энтропии вписаться в пароль bcrypt). Когда я говорю немного, я имею в виду немного. Безубыточность возникает, когда вы максимизируете 512 бит, которые имеет SHA512. Таким образом, пик составляет 78 символов.

  позвольте мне сказать это снова. Для этого класса паролей, вы можете хранить только дополнительные 6 символов перед запуском энтропия.

• низкая энтропия неслучайные пароли

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

  для этой группы вы можете значительно разблокировать больше энтропии (не создавать ее, но разрешить больше вписываться в ввод пароля bcrypt) путем хэширования. Безубыток составляет около 223 символы, прежде чем закончится энтропия.

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

Назад В Реальный Мир

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

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

шансы случайно угадать 72 правильных символа в строкеочень низкий. У вас больше шансов выиграть в лотерею Powerball 21 раз, чем иметь это столкновение... Вот о каком количестве мы говорим.

но мы не можем наткнуться на это статистически. В случае фраз вероятность того, что первые 72 символа будут одинаковыми, - это много выше, чем для случайного пароля. Но это все еще тривиально низко (вы с большей вероятностью выиграете лотерею Powerball 5 раз, основываясь на 2,3 битах на символ).

практически

практически, это действительно не имеет значения. Шансы того, что кто-то угадает первые 72 символа правильно, где последние имеют существенное значение, настолько низки, что не стоит беспокоиться. Зачем?

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

возьмем пример. Давайте возьмем цитату из Библии (просто потому, что это общий источник длинного текста, а не по любой другой причине):

не желай дома ближнего твоего. Не возжелай жены ближнего твоего, ни раба его, ни служанки его, ни вола его, осел, или все, что принадлежит вашему соседу.

это 180 символов. 73-й символ-это g во втором neighbor's. Если вы догадались, что много, вы, вероятно, не останавливаясь на nei, но продолжая с остальной частью стиха (так как пароль может быть использован). Таким образом, ваш "хэш" не добавил много.

кстати: я абсолютно не выступаю за использование цитаты из Библии. На самом деле, точное противоположный.

вывод

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

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

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

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

это мой $0.02 по крайней мере (или, возможно, намного больше, чем $0.02)...

Что Касается Использования" Секретного " Перца:

буквально нет исследований по подаче одной хэш-функции в bcrypt. Поэтому неясно, в лучшем случае, если подача "перченого" хэша в bcrypt когда-либо вызовет неизвестные уязвимости (мы знаем, что делаем hash1(hash2($value)) может подвергать значительные уязвимости вокруг сопротивления столкновению и предвидения атак).

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

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

теперь атака SQL-инъекции не будет пропускать ничего полезного, потому что у них нет ключа шифрования. И если ключ просочился, злоумышленники не лучше, чем если бы вы использовали простой хэш (что доказуемо, что-то с помощью перец "пре-хэш" не дает).

Примечание: Если вы решите сделать это, используйте библиотеку. Для PHP, я сильно рекомендуем Zend Framework 2's Zend\Crypt пакета. Это на самом деле единственный, который я бы рекомендовал в данный момент времени. Он был сильно пересмотрен, и он принимает все решения за вас (что очень хорошо)...

что-то типа:

use Zend\Crypt\BlockCipher;

public function createHash($password) {
    $hash = password_hash($password, PASSWORD_BCRYPT, ["cost"=>$this->cost]);

    $blockCipher = BlockCipher::factory('mcrypt', array('algo' => 'aes'));
    $blockCipher->setKey($this->key);
    return $blockCipher->encrypt($hash);
}

public function verifyHash($password, $hash) {
    $blockCipher = BlockCipher::factory('mcrypt', array('algo' => 'aes'));
    $blockCipher->setKey($this->key);
    $hash = $blockCipher->decrypt($hash);

    return password_verify($password, $hash);
}

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

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

• Брюс Шнайер