Злоумышленнику «разрешено» знать соль - ваша безопасность должна быть разработана таким образом, чтобы даже при знании соли она все еще была в безопасности.
Что делает соль?
Соль помогает в защите от атак грубой силы с использованием предварительно вычисленных «радужных таблиц».Соль делает грубую силу намного дороже (в терминах времени и памяти) для атакующего.Вычисление такой таблицы является дорогостоящим и обычно выполняется только тогда, когда его можно использовать для более чем одной атаки / пароля.Если вы используете одну и ту же соль для всех паролей, злоумышленник может предварительно вычислить такую таблицу, а затем переборить ваши пароли в открытый текст ...Пока вы генерируете новую (лучшую криптографически стойкую) случайную соль для каждого пароля, для которого вы хотите сохранить хеш, проблем не возникает.
В зависимости от того, как вы используете MD5, это слабое место, поскольку MD5 больше не рассматривается как «криптографически защищенный»
Если вы хотите еще больше укрепить безопасностьВы можете вычислить хэш несколько раз (хэш и т. Д.) - это не будет стоить вам дорого, но делает атаку грубой силой / вычисление «радужных таблиц» еще дороже ... пожалуйста, не изобретайте себя- существуют проверенные стандартные методы для этого, см., например, http://en.wikipedia.org/wiki/PBKDF2 и http://www.itnewb.com/tutorial/Encrypting-Passwords-with-PHP-for-Storage-Using-the-RSA-PBKDF2-Standard и http://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes.aspx
В наши дни использование такого механизма обязательно поскольку «время CPU / GPU» (может использоваться для таких атак, как «радужные таблицы», «грубая сила» и т. д.) становится все более доступным (см., например, тот факт, что облачная служба Amazon входит в число 50 самых быстрых суперкомпьютеров в мире и может использоватьсякем-либо за сравнительно небольшое количество)!
НЕ рекомендуется разбивать соль на 2 части, одну жестко закодированную / постоянную и одну уникальную!
В зависимости от алгоритмаЭто может быть слабостью, помогающей злоумышленнику нарушить вашу безопасность.Я настоятельно рекомендую НЕ делать этого, если только вы не можете математически доказать, что это не ослабляет вашу безопасность (что очень трудно сделать ИМХО).
Нет никакой проблемы для злоумышленника узнать вашу полную соль, еслиВы правильно внедрили защиту ...
ОБНОВЛЕНИЕ (согласно комментарию):
RFC 2898 является важной ссылкой на PBKDF2 .В разделе 4.1 говорится о добавлении части к соли
соль должна содержать данные, которые явно различают различные операции и ключи различной длины
Это не имеет отношения к ИМХОк тому, что спрашивает ОП.RFC говорит об информации о длинах ключей и т. Д., Включаемой в качестве дополнительной части вместе со случайной солью.Это очень похоже на наличие формата файла, содержащего раздел заголовка, описывающий конкретные аспекты данных, которые он содержит.Это не ослабляет безопасность и, возможно, очень полезно в сценарии, где необходима совместимость между различными системами.
В отличие от того, что запрашивает OP, в основном сохраняет только часть соли в БД, сохраняя при этом другую(меньшая) часть, жестко запрограммированная в приложении, что означает, что соль в БД не завершена ... выполнение этого означает потерю энтропии соли (то есть 64-битная соль с 8-битной постоянной величиной на самом деле безопасна только как 56-битная).бита), что, в свою очередь, приводит к ослаблению безопасности, которую обеспечивает соль (по крайней мере, для любого алгоритма, который я могу сейчас продумать) ... это противоречит намерениям ОП (повышение безопасности).
ОБНОВЛЕНИЕ 2 (согласно обсуждению с owlstead):
Вы можете добавить некоторый «секрет» (который может быть жестко задан в вашем приложении) в открытый текст ПЕРЕД хэшированием с помощью PBKDF2, используя уникальную и случайную соль, котораяполностью хранится в БД ... это может немного помочь, хотя и обеспечивает безопасностьпо неизвестности ИМО.