Учитывая, что у вас уже есть случайная соль, добавление какой-либо другой строки не добавляет и не умаляет уровень безопасности.
По сути, это просто трата времени.
обновление
Это становилось немного длинным, чтобы использовать комментарии.
Прежде всего, если у злоумышленника есть база данных, и единственное, что вы зашифровали, - это пароль, то игры все равно заканчиваются. У них есть данные, которые являются действительно важной частью.
Во-вторых, соль означает, что они должны создать большую радужную таблицу, чтобы охватить возможности большей длины пароля. Время, которое требуется, становится непрактичным в зависимости от длины соли и ресурсов, доступных взломщику. Смотрите этот вопрос для получения дополнительной информации:
Как реализовать защиту паролем для отдельных файлов?
обновление 2
;)
Это правда, что пользователи повторно используют пароли (как показывают некоторые из последних взломанных сайтов), и хорошо, что вы хотите, чтобы потеря ваших данных не повлияла на них. Однако, как только вы закончите читать это обновление, вы поймете, почему это не совсем возможно.
Другие вопросы должны быть собраны вместе. Вся цель соли заключается в том, чтобы гарантировать, что одни и те же два пароля приводят к разным значениям хеш-функции. Каждое солт-значение потребует создания радужной таблицы, охватывающей все возможности хэширования паролей.
Поэтому, не используя солт-значение, можно ссылаться на одну глобальную радужную таблицу. Это также означает, что если вы используете только одно солт-значение для всех паролей на сайте, то, опять же, они могут создать единую радужную таблицу и получить все пароли одновременно.
Однако, когда каждый пароль имеет отдельное значение соли, это означает, что они должны создать радужную таблицу для каждого значения соли . Радужные таблицы требуют времени и ресурсов для строительства. Вещи, которые могут помочь ограничить время, необходимое для создания таблицы, это знание ограничений длины пароля. Например, если ваши пароли должны быть от 7 до 9 символов, то хакер должен только вычислить значения хеша в этом диапазоне.
Теперь значение соли должно быть доступно функции, которая собирается хэшировать попытку пароля. Вообще говоря, вы можете скрыть это значение в другом месте; но, откровенно говоря, если они украли базу данных, они смогут довольно легко отследить ее. Таким образом, размещение значений рядом с реальным паролем не влияет на безопасность.
Добавление дополнительного бита символов , который является общим для ВСЕХ паролей ничего не добавляет к миксу. Как только хакер взломает первый, станет очевидно, что другие имеют это значение, и они могут соответствующим образом кодировать свой генератор радужных таблиц. Это означает, что это существенно не экономит время. Кроме того, это ведет к ложному чувству безопасности с вашей стороны, что может привести к тому, что вы сделаете неправильный выбор.
Что возвращает нас к цели посола паролей. Цель состоит не в том, чтобы сделать это невозможным, поскольку любой, у кого есть время и ресурсы, может их взломать. Цель состоит в том, чтобы сделать это трудным и трудоемким. Эта трудоемкая задача - предоставить вам время для обнаружения взлома, уведомления всех, кто вам нужен, и принудительного изменения пароля в вашей системе.
Другими словами, если база данных потеряна, все пользователи должны быть уведомлены, чтобы они могли предпринять соответствующие действия для изменения своих паролей в вашей и других системах. Соль просто покупает вас и их время, чтобы сделать это.
Причина, по которой я упоминал «нецелесообразно» ранее в отношении взлома их, заключается в том, что на самом деле вопрос заключается в том, как хакер определяет стоимость паролей в сравнении со стоимостью взлома. Используя разумные значения соли, вы можете увеличить вычислительные затраты настолько, чтобы об этом беспокоило очень мало хакеров. Они имеют тенденцию быть низко висящими фруктовыми людьми; если у вас нет причин быть целью. В этот момент вы должны рассмотреть другие формы аутентификации.