Как взломать базу данных? Вопрос по засолке и т. Д.

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

Я не понимаю, зачем хакеру взламывать хэши, если они пытаются выяснить пароль пользователя (при условии, что это их цель)? Разве это не было бы проще? Единственная защита от подбора пароля - это ограничение ввода пароля X раз в день или CAPTCHA?

Как вообще можно взломать базу данных? Это больше похоже на угадывание пароля или хэши можно получить с помощью MySQL-инъекции?

Спасибо!


php security brute-force salt
person Tarik    schedule 14.07.2010    source источник
comment
Когда вы говорите, не было бы проще? о чем ты говоришь?   -  person Scott Chamberlain    schedule 15.07.2010
comment
для соленых хэшей: http://stackoverflow.com/questions/1645161/salt-generation-and-open-source-software/1645190#1645190   -  person Jacco    schedule 15.07.2010
comment
Разве это не было бы проще? относится к заявлению ранее. Не было бы проще попытаться взломать пароль с помощью грубой силы, чем пытаться получить хеш?   -  person Tarik    schedule 15.07.2010
comment
Это не так, поскольку попытка использования всех вариантов пароля на веб-сайте может легко привести к некоторым ограничениям частоты попыток входа в систему или, по крайней мере, вызвать значительный объем трафика журнала. Поэтому, скорее всего, на это заметят очень много времени.   -  person che    schedule 17.07.2010

Ответы (4)


arrow_upward
4
arrow_downward

Да, соление предназначено для защиты паролей от преобразования в открытый текст. Это также мешает кому-либо сказать: «зашифрованный пароль на сайте A тот же, что и на сайте B, поэтому у пользователя один и тот же пароль в обоих местах».

Это не только для защиты пользователей от хакеров; это также защищает их от вас.

Да, единственная защита от подбора пароля - замедлить или запретить повторные попытки. Большинство CAPTCHA взламываются или не работают, и вы не можете наложить CAPTCHA или предположить ограничение на кого-то, у кого есть копия необработанной базы данных. Так что держите даже зашифрованные данные подальше от злоумышленников. Не допускайте их попадания в ваш .htpasswd или / etc / shadow файл или в вашу базу данных.

Если вы не используете соль, создать радужную таблицу (заранее) намного проще, чем угадать очень надежный пароль напрямую. Ключевым моментом является то, что построение обратного сопоставления hash-> password может быть выполнено один раз, а (несоленый) хеш навсегда сломан для всех, у кого есть радужная таблица.

База данных может быть взломана, если ваш провайдер будет скомпрометирован, если в вашем коде есть уязвимость, связанная с инъекцией, если угадан пароль вашей учетной записи пользователя БД, если ваш провайдер использует eBay для продажи (предположительно очищенного) жесткого диска, на котором было три- летняя копия вашей базы на нем ... Это может случиться по-разному.

person Borealid    schedule 14.07.2010
comment
Соли укрепляют хэш против атак с предварительным вычислением (радужные таблицы), а не против «преобразования в открытый текст» (хэш (соленый или нет) не может быть отменен). Кроме того, создание радужной таблицы так же дорого, как взлом одного пароля. Однако после того, как вы вычислили радужную таблицу, вы можете искать в ней хэши и быстро находить соответствующие входные данные. - person Jacco; 15.07.2010
comment
@Jacco: если у вас есть радужная таблица, вы можете сопоставить хэш с (некоторым совпадающим) открытым текстом. Поскольку пользователи, как правило, выбирают пароли невысокой сложности, а хеш-пространство велико, обнаруженный вами открытый текст почти всегда будет паролем пользователя. Итак, нет, соление - это предотвращение перехода в открытый текст с помощью радужных таблиц. И, как я уже сказал, причина, по которой создание радужной таблицы проще, чем взлом одного пароля, заключается в том, что радужную таблицу можно создать заранее. - person Borealid; 15.07.2010

arrow_upward
4
arrow_downward

Идея соления и хеширования состоит в том, чтобы защитить пароли в случае взлома базы данных, будь то SQL-инъекция, атаки переполнения буфера или просто переход в серверную комнату и извлечение диска из ваш сервер. Соление не защитит вас от подбора пароля, но поможет в случае, если злоумышленник доберется до данных.

person che    schedule 14.07.2010

arrow_upward
2
arrow_downward

Это может быть глупо, но многие люди используют одни и те же пароли для разных сайтов. Если ваша база данных скомпрометирована, а пароли просто хешируются, тогда есть методы (например, радужные таблицы, даже несколько веб-сайтов), которые хакер может использовать, чтобы найти значение пароля, которое приводит к тому же хешу. Затем этот пароль можно использовать, чтобы попытаться получить доступ к другим сайтам, на которых у пользователя есть учетная запись.

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

person Mark Baker    schedule 14.07.2010

arrow_upward
1
arrow_downward

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

person zebediah49    schedule 14.07.2010