Почему добавление пароля хеширования повышает безопасность?

Я занимаюсь исследованиями безопасного хранения паролей в базе данных. Обычно рекомендуется использовать соль. Как поясняется в одном из ответов в Secure hash and salt for PHP passwords, это изменяет значение хэшей, делая пароль более сложным для компрометации.Почему добавление пароля хеширования повышает безопасность?

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

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

источник

2011-12-21 Gigi

Вы должны прочитать, например. http://en.wikipedia.org/wiki/Salt_(cryptography). –

Обратите внимание, что цель соли - помешать злоумышленнику, у которого есть доступ к самому хешу **. –

Возможный дубликат [В чем преимущество соления хэша паролей?] (Http://stackoverflow.com/questions/8305893/what-is-the-advantage-of-salting-a-password-hash) – littleadv

рассмотрите сценарий, в котором вы принимаете пароль от пользователя, и вы отправляете его по сети или сохраняете в базе данных как обычный текст.

если ваш пользователь вводит пароль, скажем, 6-8 символов. Хакер может предварительно генерировать хэши для всех возможных строк длиной от 6 до 8 символов, и он может вывести пароль, сравнив его с вашим хешем. (Сопоставляя свой хэш против всех заранее генерирующих хэшей, он может получить набор возможных кандидатов, если возникает столкновение)

Но если вы добавите соль, скажем, 30 хладагентов к его паролю с открытым текстом, а затем нажмите его. для любого хакера очень сложно заранее создать все возможные комбинации этого диапазона. Это основная причина, почему мы используем соль.

Вы не можете ограничить каждый пользователь вводить пароль длиной 30 символов в целях безопасности. если какой-либо пользователь выбирает пароль длиной 4 символа, добавьте 30 солей и сделайте его более безопасным.

источник

2011-12-21 21:22:59

Это, в основном, правильно, но добавление 30-значной соли к 4-символьному паролю не очень помогает. Соль заключается в том, чтобы сделать любое вычисление пароля уникальным, поэтому злоумышленник, получающий хеши, не может использовать предварительно вычисленную таблицу. Однако соль не зашифрована. В SQL-дампе СОЛС будут на равных. Так что взломать пароль из четырех символов по-прежнему очень просто. Потому что есть только четыре символа. Объем безопасности, который он добавляет, ничтожно мал. – Erlend

@ Eriend - да, соление добавляет немного безопасности к 4-символьному паролю. Но с большим паролем. Безопасность не взламывает отдельный пароль. Это все еще будет в грубое время.Безопасность заключается в том, что если я использую один и тот же пароль с 50 разными веб-сайтами, которые используют разные соли, даже если вы управляете компрометацией одного веб-сайта и выясняете мой пароль открытого текста и соответствующий хеш, вы не сможете сравнить этот хэш с хэши, хранящиеся на других сайтах - вам нужно будет компрометировать/переборщить их. – iheanyi

Без соли, как только открытый текст для известного хэша будет найден, вы можете скомпрометировать любого, у которого пароль имеет то же самое, без каких-либо дополнительных усилий. Соль больше о защите всех остальных от ошибки манекена. Конечно, если после компрометации исходного сайта вы предположили, что я использовал один и тот же пароль - вы были бы золотыми. Но, если бы не было прямого способа связать различные учетные записи на разных сайтах напрямую со мной, то злоумышленнику все равно придется много работать. – iheanyi

Соленые пароли уменьшают вероятность того, что в файле rainbow table уже содержится содержащийся в нем хэш-файл соленых паролей.

источник

2011-12-21 21:13:57

Предполагая, что подходящая соль (большой и случайный) и алгоритм хеширования, который не подвержен грубой силе (SHA-1 слишком быстро *). Но да, совершенно основная цель соли ... она определенно не предназначена для «секретности» (по крайней мере, не более, чем хеш ее соли). –

Являются ли таблицы радуги основаны на типичных словарных паролях, или они вычисленный через сам хеш? – Gigi

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

Почему добавление пароля хеширования повышает безопасность?

ответ

Смежные вопросы