Вот мой вопрос: на ваш опыт, безопаснее ли иметь одну соль для каждого хэша, хранящегося в файле PHP, делающего хеширование, или лучше иметь другую соль для каждого хешированного объекта и хранить его в базе данных с этим объектом?Same Salt or Different Salts
ответ
Соль имеет смысл только в том случае, если она различна для каждой хешированной строки.
Так что, да, создать дополнительный столбец и поместить случайную соль там
Единственная вещь, которую соль делает, если она хранится в базе данных, предотвращает поиск хэша в базе данных. Соль внутри файла PHP более безопасна, если программное обеспечение не является открытым исходным кодом. – AustinAllover
@AustinAllover: если вы не знаете алгоритм (вам нужны источники для этого) - знание соли и хэш ничего не дает.PS: спасибо за downvote – zerkms
Вам нужно знать алгоритм для обоих случаев, неважно, находится ли хэш в базе данных или в файле. Какое преимущество дает соль в базе данных? и я ниспровергаю, потому что я чувствую, что ваш ответ неверен: P – AustinAllover
Различные соли для каждого хэша; в противном случае хешированный объект становится уязвимым для атаки грубой силы.
Все, что уязвимо перед грубой силой – zerkms
@zerkms: Я не согласен. Атаки с применением грубой силы всегда будут работать (в конечном итоге), но хорошо соленый пароль не «уязвим» ... чтобы быть уязвимым, должна быть уязвимость. Как использование той же соли. –
bruteforce называется «** грубым - **», потому что это просто напыщенные предметы по одному. Нет защиты от bruteforce. По умолчанию каждый хэш уязвим для грубой силы. Если мы знаем соль (и, очевидно, мы это делаем), мы можем применять bruteforce. – zerkms
Единственное, что соль, которая хранится в базе данных делает защиту от радужных таблиц
Если это не программное обеспечение с открытым исходным кодом, это более безопасно, чтобы иметь одну соль в файле PHP.
Многие разработчики не согласятся со мной, но для хакеров это не ежу понятно
Если соль хранится в файле PHP, хакер должен будет получить доступ к файлам, чтобы увидеть соль, и она будет по-прежнему защищать от радужных столов ...
В большинстве случаев (подпишитесь на безопасность пакетного шторма, если вы мне не верите), уязвимости выполняются через SQL-инъекцию/XSS (межсайтовый скриптинг), большие атаки на Wordpress от анонимных и т. д. .. ВСЕ ИНТЕРЕС. И очень редко существует уязвимость, которая позволит злоумышленнику увидеть исходный код с использованием RFI (включение удаленного файла) или что-то подобное.
Подумайте об этом, если кто-то увидит вашу базу данных через SQL Injection и т. Д., У них есть доступ к базе данных, поэтому у них также будет ваша соль, поэтому, если это случайное, это не имеет значения.
Это называется «безопасность безвестности». Когда вы говорите о безопасности, имеет смысл подумать о «худших» случаях. И в худшем случае, когда хакер украл оба БД и код – zerkms
Как насчет одной соли в PHP и второй соли в базе данных? –
@zerkms Итак, в худшем случае, и они получают только вашу базу данных ... они также получают вашу соль. И в случаях МОСТ у них есть только доступ к базе данных. – AustinAllover
Если вы храните пароли в базе данных, вам нужно смешать что-то, что зависит от каждой записи, чтобы вы не могли легко найти совпадающие пароли в базе данных. Вы можете использовать случайную соль, или вы можете просто указать имя пользователя (если оно является неизменным) или какое-то другое неизменяемое уникальное поле.
Если вы используете что-то вроде имени пользователя, тогда вы также должны сделать что-то уникальное для своей реализации, поскольку есть, вероятно, другие сайты, использующие один и тот же алгоритм, и поэтому есть шанс найти совпадения. Строго говоря, это не должно быть соль, которую вы включаете в хеш, это может быть просто разница в том, как работает ваш алгоритм, но обычно проще просто добавить глобальную соль. Если вы используете соль для каждой соли, тогда нет необходимости добавлять другую глобальную соль.
С этими типами проблем обычно проще продумать виды атак, которые могут использовать хакеры. Помните, что вы на самом деле не пытаетесь защитить свои данные (поскольку ваша база данных была скомпрометирована), вы на самом деле пытаетесь запретить хакерам принимать учетные данные, используемые на вашем сайте, и использовать их на других сайтах.
Удивительно, что этот вопрос вызвал довольно приличную дискуссию, и нет никаких повышений –