Какой смысл в соли и хэшировании, если база данных доступна?
Я только что изучил концепцию хеширования ("Эй! Не забывайте соль!") И использования соли для защиты пароля.
Хеширование - это одностороннее шифрование (на самом деле не шифрование, а хеширование), поэтому его нельзя изменить с помощью технологии. Соль - это префикс или добавление случайно созданных значений к паролю перед хэшированием, потому что проблема хеширования (просто хеширования) в том, что некоторые гении предоставили хэш-таблицу слов из словаря, чтобы они просто сравнили хеш из этого словаря с таблица пользователя из базы данных для входа в систему - W-wait? я сказал таблицу из базы данных? Значит, кто-то может получить доступ к базе данных, поэтому мы должны использовать соль? Если это так, то зачем хакеру восстановить пароль, если он уже имеет доступ к базе данных? Если бы я был им, я бы просто получил все необходимые данные из базы данных, зачем мне использовать ключ, который я украл из дома, чтобы открыть дверь, если я могу получить доступ к дому уже через окно?
Итак, почему хэш? почему соль? Я не понимаю Пожалуйста, кто-нибудь, помогите мне.
Заранее спасибо.
Важное примечание: я не против перемешивания или засолки, я просто хочу уточнить вещи.
5 ответов
Если это так, то зачем хакеру восстановить пароль, если он уже имеет доступ к базе данных?
Причин много. Вот несколько из них:
Люди повторно используют свои пароли, поэтому отсутствие утечки реальных паролей действительно ограничивает воздействие такой атаки.
Без реальных паролей хакер все равно не сможет войти в систему и, скажем, разместить новые записи в взломанной системе.
Кто сказал, что вся информация хранится в базе данных? Что если база данных состоит исключительно из имени пользователя и хэшированных / соленых паролей? Тогда знание контента мало чем поможет.
Владение пользовательскими записями из базы данных не обязательно означает, что у вас есть доступ к базе данных. Из-за некоторой утечки на сайте (привет, SQL-инъекция) вы можете получить доступ к данным, к которым у вас не должно быть доступа, не обязательно подвергая риску весь сервер. Плохо обработанные резервные копии, общие серверы, некомпетентные или злонамеренные сотрудники могут сделать это возможным.
Также и, возможно, что еще более важно, вам нужно защитить пароли ваших клиентов на других сайтах. Люди, к сожалению, используют свои пароли повсюду. Если ваша крошечная база данных чата будет взломана, пароли людей на их банковских сайтах могут быть скомпрометированы этим.
Если у вас есть пароли в виде открытого текста и адреса электронной почты из базы данных, вы можете нанести ущерб! Речь идет не о получении учетных данных для сайта, который уже взломан, а о получении информации для входа на другие сайты.
Большинство людей не используют один пароль только для одного сайта, поэтому, если у вас есть пароль для их основного адреса электронной почты, вы, вероятно, имеете доступ ко ВСЕМ их учетным записям на каждом сайте (через сброс пароля).
Соль используется для того, чтобы идентичные пароли имели разные хэши, пытаясь выяснить пароли сложнее.
Хеширование делает так, что генерация пароля с помощью методов грубой силы занимает очень много времени (особенно с SHA2), так что это делает "неосуществимым" поиск пароля.
Хеш не поможет, если вы не знаете пароль, так как ввод хеша в поле пароля не будет работать (очевидно).
Обычно хакеры находят только пользовательские таблицы и, возможно, некоторую базовую информацию, но если они хотят иметь возможность фактически получить доступ к этой пользовательской информации и что-то изменить, им нужен реальный пароль (так как они не знают всей схемы БД, изменение чего-либо может выглядеть очень подозрительно и это легко отследить, если вы не законно войдите как человек)
Последнее, о чем я забыл, - это то, что люди используют пароли повторно. Поэтому, возможно, вы взломали какой-то случайный сайт, на котором нет полезной информации, но этот человек использовал ту же комбинацию пользователя и пароля в своем онлайн-банке. Это может быть очень плохо, как вы можете видеть, поэтому неспособность легко определить пароль - это ключ.
Предположим, что злоумышленник каким-то образом получает доступ к резервной копии базы данных, содержащей невосстановимые хешированные пароли. Тогда у них есть все данные, которые были там вчера, что довольно плохо. Но, по крайней мере, у них нет доступа к данным, которые будут там завтра, и они не могут ничего удалить с реального сайта, уничтожить его, обслуживать вредоносное ПО через его CMS и т. Д.
Предположим, что злоумышленник получает все пароли в виде открытого текста, особенно если это касается администратора. К сожалению.