При каком сценарии хакер получит таблицу, но не код PHP?

Question

Хорошо, я понимаю значение соли в моих хэшированных паролях ... вроде.

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

Так в чем же реальная польза соли?

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

Я пытаюсь определить, действительно ли использование соли действительно важно в моем случае.

Спасибо

Answer 1

Следует отметить, что SQL-инъекция может использоваться для чтения файлов с использованием загрузить данные в файл . Наличие значения соли, неизвестного злоумышленнику, заставит злоумышленника сделать гораздо больше догадок, чтобы получить простой текст. Хотя соление почти никогда не принимает это во внимание. Основная идея состоит в том, чтобы выполнить две вещи:

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

2) Заставить атакующего генерировать радужные таблицы большего размера . В этом случае вы хотите по крайней мере 8 байтов. Часто вы видите такое же количество битов, что и у функции дайджеста сообщения, что делает предварительное вычисление совершенно невозможным.

Как только соль получена, инструмент John The Ripper может быть использован для взлома пароля. GPU также обычно используются для взлома сильно засоленных паролей. Следует отметить, что bcrypt () хорошо защищает от FPGA и GPU из-за высоких требований к памяти. Использование жестких функций памяти для хранения паролей может дать очень надежную систему хранения паролей.

Answer 2

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

Для соли 2 ASCII его размер уже в 65536 раз больше.

Что действительно нужно упомянуть, почему вы вообще должны использовать соли, так это тот факт, что большинство пользователей используют слова, непосредственно найденные в словаре. У меня нет данных о том, сколько, но я думаю, это много. Таким образом, даже если не используются «радужные» таблицы, злоумышленник может «перебить» только небольшой набор паролей за один раз. Если у вас нет соли, выполните словарную атаку с некоторыми изменениями (добавление чисел, ...), и вы получите, скажем, 30% всех паролей только с одной словарной атакой. С солью это не может произойти за один проход, значит, это занимает гораздо больше времени, а значит, бессмысленно для атакующего.

На ваш другой вопрос:

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

Answer 3

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

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

Но ответить на заглавный вопрос; Весьма вероятно, что если ваша база данных скомпрометирована, то и ваш PHP-код тоже. Однако они могут получить доступ только для чтения к вашему PHP-коду, в то время как для большинства уровней доступа к базе данных требуется доступ INSERT / UPDATE, чтобы приложение вообще могло функционировать. Некоторые люди разделяют SQL-доступ для чтения и записи, но в большинстве случаев это действительно нереально, потому что вы всегда ВСТАВЛЯЕТЕ и ОБНОВЛЯЕТЕ, даже на страницах, где ваши пользователи даже не вошли в систему (счетчики, кнопки типа "нравится", "нет" и т. Д. .).

Answer 4

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