PHP и MySQL солевой вопрос безопасности

Question

Что если мой сервер взломают, а хакер увидит мои хешированные пароли и увидит, какую соль я использовал.

О чем беспокоиться?

Answer 1

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

Answer 2

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

Так что да, соль MD5 плюс в этом случае "достаточно хороша".

Answer 3

Да, это так. Теперь хакер может их взломать (если он знает, как на самом деле вы солили пароли).

Больше не о чем беспокоиться - поскольку вы используете соленые пароли, более интеллектуальные атаки (кроме грубой силы) не могут быть применены.

Answer 4

Я не специалист в этой области, но это мое понимание:

Учитывая соль, злоумышленник может построить так называемый «радужный стол», который, по сути, противоположен хэш-функции. С помощью этой таблицы они могут искать зашифрованное значение в таблице и возвращать входной пароль, такой что hash(password + salt) = encrypted value.

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

(Соль по-прежнему намного лучше, чем ничего, потому что таким образом злоумышленник должен по крайней мере создать свой собственный радужный стол, а не просто загрузить обычный).

Больше информации и, возможно, лучший ответ

Answer 5

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

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

Выможет еще больше замедлить его, используя намеренно медленный хеш, который замедлит грубое форсирование до такой степени, что это может стать невозможным.MD5 - худший выбор, потому что он действительно быстрый (и не работает).Семейство SHA также было разработано, чтобы быть быстрым, но это лучший выбор.Bcrypt или вообще семейство * fish приличное, но поддержка между системами и языками различна.Будьте осторожны, используйте хеш вариант * fish, поскольку они также используются для шифрования (может быть перевернуто).

См. http://blog.phusion.nl/2009/08/13/securely-store-passwords-with-bcrypt-ruby-now-compatible-with-jruby-and-ruby-1-9/.

Answer 6

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

http://pbeblog.wordpress.com/2008/02/12/secure-hashes-in-php-using-salt/

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

Answer 7

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

Answer 8

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