Хорошо. Поскольку мне нужно написать об этом над и над, я сделаю последний канонический ответ только на Пеппер.

Очевидная Положительная Сторона Перцев

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

Вот почему так много людей считают, что перец-это хорошая идея. Это "имеет смысл".

В Реальность Перцев

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

А перцы не подходят ни под доказуемое, ни под ремонтопригодное модели...

Теоретические Проблемы С Перцем

Теперь, когда мы подготовили почву, давайте посмотрим, что не так с перцем.

• Скармливать один гашиш другому может быть опасно.

  В вашем примере Вы делаете hash_function($salt . hash_function($pepper . $password)).

  Мы знаем из прошлого опыта, что "просто подача" одного хэш-результата в другую хэш-функцию может снизить общую безопасность. Причина в том, что обе хэш-функции могут стать объектом атаки.

  Вот почему алгоритмы, подобные PBKDF2 , используют специальные операции для их объединения (в этом случае hmac).

  Дело в том, что, хотя это не так уж и важно, это также не тривиальная вещь, которую можно просто бросить. Криптосистемы предназначены для того, чтобы избегать случаев "должен работать", а вместо этого сосредоточиться на случаях "предназначен для работы". Хотя это может показаться чисто теоретическим, на самом деле это не так. Например, Bcrypt не может принимать произвольные пароли . Таким образом, передача bcrypt(hash(pw), salt) действительно может привести к гораздо более слабому хэшу чем bcrypt(pw, salt), если hash() возвращает двоичную строку.

• Работа Против Дизайна

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

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

  Это не значит, что это не безопасно. Это значит, что мы не знаем, безопасно ли это. И общая рекомендация в отношении безопасности и криптографии заключается в том, что если мы не знаем, то это не так.

  Таким образом, пока алгоритмы не разработаны и не проверены криптографами для использования с секретными значениями (перцами), текущие алгоритмы не следует использовать их вместе.

• Сложность-Враг Безопасности

  Хотите верьте, хотите нет, но сложность-враг безопасности. Создание алгоритма, который выглядит сложным, может быть безопасным, а может и нет. Но вероятность того, что это не безопасно, весьма велика.

Значительные Проблемы С Перцем

• Это не ремонтопригодно

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

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

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

  Что в принципе делает ваш подход немедленным отказом.

• Он Требует, Чтобы Вы Свернули Свой Собственный Крипто

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

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

  • Брюс Шнайер

  Никогда не бросайте свою собственную криптографию...

Лучший Способ

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

• Просто Используйте Алгоритмы, Как Они Существуют

  Если вы используете bcrypt или scrypt правильно (с высокой стоимостью), все пароли, кроме самых слабых словарей, должны быть статистически безопасными. Текущий рекорд по хешированию bcrypt при стоимости 5 составляет 71 тыс. хэшей в секунду. С такой скоростью даже случайный пароль из 6 символов будет взламываться годами. И учитывая, что моя минимальная рекомендуемая стоимость составляет 10, это уменьшает хэши в секунду в 32 раза. Таким образом, мы будем говорить только о 2200 хэшах в секунду. С такой скоростью даже какой-нибудь словарь фразы или модификации могут быть безопасными.

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

• Зашифруйте Выходной Хэш Перед Хранением

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

  Давайте еще раз взглянем на эту линию. Предположим, что злоумышленник знает ваш алгоритм (который необходим для обеспечения безопасности, иначе это безопасность через неизвестность). С традиционным подходом перца, атакующий может создать пароль стража, и так как он знает соль и выход, он может грубо заставить перец. Ладно, это маловероятно, но вполне возможно. С шифром злоумышленник ничего не получит. А поскольку соль рандомизирована, пароль стража даже не поможет ему / ей. Поэтому лучшее, что им остается, - это атаковать зашифрованную форму. Это означает, что сначала они должны атаковать ваш зашифрованный хэш, чтобы восстановить ключ шифрования, а затем атаковать хэши. Но есть много исследований в области атака шифров, поэтому мы хотим полагаться на это.

TL / DR

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