Есть ли разница в работе между
$hash=sha1($key.$staticSalt); а также
$hash=sha1($key.$randomSalt);
Если я использую случайную соль, мне нужно хранить случайную соль в базе данных, с другой стороны, если я использую фиксированную соль, тогда нет необходимости использовать БД!
И если код можно взломать, чтобы увидеть соль (статический), тогда хакер сможет увидеть базу данных также с хешем и случайной солью: D
Так стоит ли это?
Что делать, если я использую соль как @#kiss~89+.&&^me ?
Случайные соли обладают огромной выгодой. Если все учетные записи в системе используют одну и ту же соль, злоумышленник может переманить хэши для этой соли и разбить все учетные записи только с одним вычислительным прогоном. Если они используют разные соли на счет, грубая сила приводит вас только к одной учетной записи.
Хотя наилучшая практика для хранения паролей диктует, что они должны храниться в хэшированном формате с уникальной солью, исходный вопрос действительно поднимает разумно хороший момент: если вы храните соль в другом месте для хэшей, влияние этих хешей раскрывается.
1) Если пароли были только хэшированы и сохранены в базе данных, а сайт подвергся SQL Injection, тогда злоумышленник может «взломать» хэши
2) Если пароли были хэшированы с солью, а оба хеша и соли были в базе данных, а на сайте был SQL Injection, тогда злоумышленник мог «взломать» хеши, но потребовал бы большего вычислительного усилия (поскольку нет производительности повышение из предварительно вычисленных таблиц)
3) Если пароли были хешей с солью, а соль хранилась где-то в другом месте, то SQL Injection предоставила бы злоумышленнику небольшое преимущество для установления фактического пароля.
Сценарий 1, очевидно, является самым слабым, но разница в безопасности между 2 и 3 менее ясна и зависит от относительных вероятностей SQL Injection против раскрытия кода на стороне сервера (и связанных классов уязвимости).
К чему вы доверяете больше – свою способность защищать от SQL Injection или способность Apache / PHP / Что бы ни защищало ваш серверный контент.
Вещи никогда не просты, и я на самом деле думаю, что идея в OP имеет больше смысла, чем другие ответы.
(Вы можете использовать как соль, сохраненную в базе данных, так и «ключ», если вам нравится хранить в источнике веб-приложения при генерации паролей).
Соль является случайной по определению; нет такой вещи, как «статическая соль». Если это не случайность, это не соль, а ключ.
Цель соли – убедиться, что атакующий должен установить отдельную атаку для каждого пароля, который он / она хочет взломать. Другими словами, точка сосания хэша заключается в предотвращении предвычисляющих атак ( радужных таблиц ).
Легким решением для правильного выбора является использование стандартной библиотеки вместо резки углов
Всегда используйте случайную соль для каждого пароля.
Если вы этого не сделаете, то преимущество в том, что соль потеряна. Если вы используете ту же соль, то в случае взлома веб-сайта хакер может использовать одну и ту же таблицу хеширования для взлома всех паролей в вашем списке пользователей. Если соль случайна, то он должен иметь новую хэш-таблицу для каждого пользователя.
Я не уверен, правильно ли вы соленый. Цель соли – сорвать заранее атакованные словарные атаки, если ваша база данных скомпрометирована. Поэтому вы используете базу данных для начала, так что означает комментарий «не нужно использовать БД»?
Если вы не используете случайную соль, вам не будет сложнее атаковать атакующего хеши, если они получат руку от соли. Вам будет лучше использовать случайную соль – вам не нужно будет скрывать ее, чтобы ваша безопасность работала.
Соль также не должна быть длинной или необычной. «РК» – хорошая соль. «1q» тоже хорош. Его цель – просто изменить выход хэш-функции.