#php #mysql #security #salt
#php #mysql #Безопасность #соль
Вопрос:
Хорошо, итак, я понимаю значение соли в моих хэшированных паролях … вроде.
Я настраиваю базовую схему аутентификации, в которой я устанавливаю пароли, и у пользователей нет возможности устанавливать пароли как нечто, что они могли бы использовать для другого сайта.
Итак, какова реальная полезность соли?
При каких обстоятельствах кто-то может скомпрометировать мою пользовательскую таблицу, но не получить доступ к остальным таблицам со всеми данными или к моему PHP-коду, который показывает магию?
Я пытаюсь определить, действительно ли использование соли так важно в моем случае.
Спасибо
Комментарии:
1. Соль важна, если вы хотите, чтобы ваши пользователи не пострадали в значительной степени, если / когда ваша таблица паролей будет украдена (они будут затронуты в любом случае в том смысле, что в этом сценарии вы должны принудительно немедленно сменить пароль для всех, чтобы максимально ограничить ущерб). Почему вас волнует, как может произойти авария? Не могли бы вы спросить, при каких условиях сработает подушка безопасности, и подумать о том, чтобы не устанавливать ее в свой автомобиль?
2. Возможно, вам следует выбрать другой ответ на этот вопрос.
Ответ №1:
Следует отметить, что SQL-инъекция может использоваться для чтения файлов с использованием load data infile. Имея значение соли, неизвестное злоумышленнику, это заставит злоумышленника сделать намного больше догадок, чтобы получить обычный текст. Хотя соление почти никогда не учитывает это. Основная идея заключается в том, что два выполняют две вещи:
1) У двух пользователей с одинаковым паролем будут разные хэши паролей. Вот почему некоторые системы соления используют очень маленькие соли, например, всего несколько байт.
2) Принуждение злоумышленника к созданию больших радужных таблиц. В этом случае вам нужно не менее 8 байт. Часто вы видите соли с тем же количеством битов, что и функция дайджеста сообщений, что делает предварительные вычисления полностью невозможными.
Как только соль получена, инструмент John The Ripper можно использовать для взлома пароля. Графические процессоры также обычно используются для взлома сильно просоленных паролей. Следует отметить, что bcrypt() хорошо защищает от ПЛИС и графических процессоров из-за высоких требований к памяти. Использование жестких функций памяти для хранения паролей может дать очень надежную систему хранения паролей.
Ответ №2:
Насколько я понимаю, соль замедляет обратное вычисление паролей пользователей в случае взлома этой таблицы. Соли связываются с паролем, а затем однонаправленно хэшируются, чтобы избежать возможности определения скомпрометированных паролей из таблиц Rainbow или списков предварительно хэшированных паролей.
Комментарии:
1. Итак, я предполагаю, что тогда возникает вопрос: каковы последствия обратного вычисления паролей после взлома сайта. В моем случае ничего; дыра в безопасности должна быть исправлена, а пароли должны быть сгенерированы заново, но кто-то, у кого есть 10-15 паролей, которые я придумал, не принесет им никакой пользы, как только я определю и устраню проблему, верно? Значит, соли нет?
Ответ №3:
Большая проблема с солением паролей (и их хешированием в первую очередь) заключается в том, что много людей… на самом деле почти все люди… повторно используйте их пароли. Кроме того, большинство пользовательских таблиц также хранят электронные письма и / или имена пользователей. Так что, если кому-то удастся получить пароли всех ваших пользователей, ущерб был нанесен не только на вашем сайте, но и в любом другом месте, где зарегистрированы эти пользователи, где их можно легко найти. Со всеми данными, которые обычно хранятся в пользовательских таблицах, ущерб трудно преувеличить.
Короче говоря; взломанные пароли не только дают пользователям доступ к тому, что вы размещаете, но и влияют на безопасность клиентов практически на каждом сайте, на который они заходят.
Но чтобы ответить на вопрос заголовка; очень вероятно, что если ваша база данных скомпрометирована, ваш PHP-код тоже. Однако они могут получить доступ только для чтения к вашему PHP-коду, тогда как для большинства уровней доступа к базе данных требуется доступ для ВСТАВКИ / ОБНОВЛЕНИЯ, чтобы приложение вообще функционировало. Некоторые люди разделяют доступ к SQL на чтение и запись, но в большинстве случаев это нереально, потому что вы всегда вставляете и обновляете, даже на страницах, на которых ваши пользователи даже не вошли в систему (счетчики, кнопки «нравится / не похоже» и т. Д.).
Комментарии:
1. Итак … кто-нибудь может пролить свет на то, как я могу улучшить свое понимание, увидев -1?
Ответ №4:
Если вы солите, скажем, один символ ASCII случайным образом, злоумышленнику нужна таблица, размер которой в 256 раз больше, чем у таблицы rainbow без солей.
Для 2 ASCII char salt его размер уже в 65536 раз больше.
Что действительно нужно упомянуть, почему вы вообще должны использовать соли, так это тот факт, что большинство пользователей используют слова, найденные непосредственно в словаре. У меня нет данных о том, сколько, но я предполагаю, что это много. Таким образом, даже если не используются радужные таблицы, злоумышленник может «использовать» только небольшой набор паролей за один раз. Если у вас нет соли, выполните атаку по словарю с некоторыми изменениями (добавлением чисел, …), и вы получите, скажем, 30% всех паролей только с одной атакой по словарю. С солью это не может произойти за один запуск, означает, что это занимает гораздо больше времени, означает, что для злоумышленника это бессмысленно.
На ваш другой вопрос:
ничто не мешает злоумышленнику получить другие данные вашей таблицы. Но это не то, чего могут избежать хешированные пароли с солью или без нее.
Комментарии:
1. Вы, вероятно, говорите о md5, вы также можете хэшировать с помощью sha256 и т. Д., Очень сложно найти исходную строку, если она не типа 123456…
2. не имеет значения, что я сказал. Более того, сегодня я рад, если приложение вообще использует хэши. Если посолить еще лучше. Факт в том, что существуют миллионы приложений, которые даже не используют какой-либо хэш. Итак, sha256 не является критерием, почему бы не использовать соли. В любом случае, даже с sha256 вы безопаснее используете соль, это факт. Данные должны быть в безопасности в течение многих лет, кто знает, может быть, злой ублюдок уже вычисляет их? 🙂
3. Это не зло, это умно… Конечно, пароли должны быть солеными, я просто говорил, что чистый md5 легче всего взломать … любой нестандартный хэш / шифрование хорош… Вы не сможете взломать его, если не знаете, что это такое.
4. вы подразумеваете безопасность под неизвестностью? Я бы никогда не использовал какой-либо алгоритм шифрования / хеширования, который не является общедоступным и не проверяется криптографами.
5. -1 65536 радужных таблиц? НЕТ, сэр, соль в 2 символа бесполезна и уже должна быть покрыта радужной таблицей среднего размера. Вы должны хотя бы прочитать о «rainbowcrack», прежде чем рассказывать другим людям, как это работает.