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