Статическая соль против случайной соли - PHP безопасности

Question

Есть ли какая-либо рабочая разница между

$hash=sha1($key.$staticSalt);  

и

$hash=sha1($key.$randomSalt);  

Если я использую случайную соль, мне нужно сохранить случайную соль в базе данных, с другой стороны, если яиспользуйте фиксированную соль, тогда нет необходимости использовать DB!
И если код можно взломать, чтобы увидеть соль (статическую), то хакер сможет увидеть базу данных также с хешем и случайной солью: D
Так стоит ли это?
Что если я использую соль типа @#kiss~89+.&&^me?

Answer 1

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

Answer 2

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

1) Если пароли были только хэшированы и сохранены в базе данных, а сайт подвергся SQL-инъекции, то злоумышленник может «взломать» хэши

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

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

Сценарий 1, очевидно, является самым слабым, но разница в безопасности между 2 и 3 менее очевидна и зависит от относительной вероятности раскрытия кода SQL-инъекцией по сравнению с серверной частью (и связанными классами уязвимости).

Чему вы доверяете больше - вашей способности защищаться от SQL-инъекций или способности Apache / PHP / What угодно для защиты содержимого на стороне сервера.

Вещи никогда не бывают простыми, и я на самом деле думаю, что идея в ОП имеет больше смысла, чем другие ответы.

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

Answer 3

Соль является случайной по определению; нет такой вещи как «статическая соль». Если это не случайно, это не соль, а ключ.

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

Простое решение для правильного использования - использовать стандартную библиотеку вместо резки углов

Answer 4

Всегда используйте случайную соль для каждого пароля.

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

Answer 5

Я не уверен, правильно ли вы солите - цель соли - предотвратить атаки по предварительно вычисленным словарям, если ваша база данных взломана. Поэтому для начала вы используете базу данных, так что означает ваш комментарий «нет необходимости использовать БД»?

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

Соль также не обязательно должна быть длинной или необычной. «РК» - хорошая соль. «1q» тоже хорошо. Его цель - просто изменить вывод хеш-функции.