Потерпите меня, я только изучаю PHP всего несколько недель, поэтому пример кода может смутить меня. Я думаю, что, наконец, понимаю соление! Это защита паролей внутри базы данных, если она нарушена.
Я не понимаю, почему хакер должен взломать хэши, если они пытаются определить пароль пользователя (если это их цель)? Разве это не будет проще? Единственная защита от угадывания паролей заключается в том, чтобы реализовать лимит ввода пароля X количество раз в день или CAPTCHA?
Каким образом база данных будет взломана в первую очередь? Это больше угадывает пароль или может хеши получить через MySQL инъекции?
Благодаря!
Да, соление – это защита от паролей от обратного обращения к открытым текстам. Это также мешает кому-то сказать: «Зашифрованный пароль тот же на сайте A, что и на сайте B, поэтому у пользователя одинаковый пароль в обоих местах».
Это не только для защиты пользователей от хакеров; это также защищать их от вас .
Да, единственная защита от угадывания пароля – это замедление или запрет повторных попыток. Большинство CAPTCHA являются прерывистыми или ломающимися, и вы не можете наложить ограничение CAPTCHA или догадки на кого-то, у кого есть копия необработанной базы данных. Поэтому храните даже зашифрованные данные из рук злонамеренных людей. Не позволяйте им в вашем файле .htpasswd или / etc / shadow или в вашей базе данных.
Если вы не используете соль, создание радужного стола (заранее) намного проще, чем угадать очень сильный пароль напрямую. Ключ состоит в том, что построение обратного отображения hash-> password может быть выполнено один раз, а хэш несохраненного навсегда разбит на всех, у кого есть радужный стол.
База данных может быть взломана, если ваш провайдер взломан, если в вашем коде есть уязвимость в отношении инъекций, если ваш пароль учетной записи пользователя БД угадан, если ваш провайдер использует eBay для продажи (предполагаемого стираемого) жесткого диска, летнюю копию вашей базы данных на нем … Это может произойти многими способами.
Идея соления и хеширования заключается в защите паролей в случае, если база данных была скомпрометирована, будь то путем инъекции SQL, переполнения буфера или просто путем перехода в серверную комнату и вытащить диск из вашего сервера. Соление не защитит вас от угадывания пароля, но поможет в случае, если злоумышленник получит данные.
Ключевым моментом здесь является то, что они не пытаются получить пароль пользователя для использования на вашем сайте, хотя после того, как вы исправите отверстие, которое может быть полезно. Это так, что если по какой-либо причине ваш сайт подвергнут риску, у вас нет вреда для пользователей. Люди склонны дублировать пароли; это было бы плохо.
Это может быть глупо, но многие люди используют одни и те же пароли для разных сайтов. Если ваша база данных скомпрометирована, а пароли просто хэшируются, тогда есть методы (например, таблицы радуги, даже несколько веб-сайтов), которые хакер мог использовать, чтобы найти значение пароля, которое приводит к такому же хэшу. Затем этот пароль можно использовать, чтобы попытаться получить доступ к другим сайтам, на которых у пользователя есть учетная запись.
Если пароли в вашей базе данных солены, то это становится значительно сложнее … и если другие веб-сайты также сольют свои пароли с разными солями, то это становится непрактичным для хакера.