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