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

Я провел некоторое исследование о безопасном хранении паролей в базе данных. Обычно рекомендуется использовать соль. Как объясняется в одном из ответов в разделе Безопасный хэш и соль для паролей PHP, это изменяет значение хэшей, что затрудняет компрометацию пароля.

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

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


security salt
person Gigi    schedule 21.12.2011    source источник
comment
Вы должны прочитать, например. en.wikipedia.org/wiki/Salt_(криптография).   -  person Oliver Charlesworth    schedule 22.12.2011
comment
Обратите внимание, что соль предназначена для того, чтобы помешать злоумышленнику, который имеет доступ к самому хэшу.   -  person Oliver Charlesworth    schedule 22.12.2011
comment
возможный дубликат В чем преимущество соления хэша пароля? < /а>   -  person littleadv    schedule 22.12.2011

Ответы (2)


arrow_upward
5
arrow_downward

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

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

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

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

person Rajesh Pantula    schedule 21.12.2011
comment
Это в основном правильно, но добавление 30-символьной соли к 4-символьному паролю на самом деле не очень помогает. Соль заключается в том, чтобы сделать любой расчет пароля уникальным, поэтому злоумышленник, который получает хэши, не может использовать предварительно вычисленную таблицу. Однако соль не зашифрована. В дампе SQL SALT будут в обычном виде. Таким образом, взломать пароль из четырех символов по-прежнему очень просто. Потому что нужно угадать только четыре символа. Уровень безопасности, который он добавляет, незначителен. - person Erlend; 22.12.2011
comment
@Eriend - да, соление мало повышает безопасность 4-символьного пароля. Но это происходит с большим паролем. Безопасность заключается не во взломе индивидуального пароля. Это все еще будет в грубой силе времени. Безопасность заключается в том, что если я использую один и тот же пароль на 50 разных веб-сайтах, использующих разные соли, даже если вам удалось скомпрометировать один веб-сайт и вычислить мой открытый текстовый пароль и соответствующий хэш, вы не сможете затем сравнить этот хэш с хэши, хранящиеся на других сайтах - вам также нужно их скомпрометировать/переборщить. - person iheanyi; 16.07.2014
comment
Без соли, как только открытый текст для известного хэша найден, вы можете скомпрометировать любого, чей пароль совпадает с паролем, без каких-либо дополнительных усилий. Соль больше предназначена для защиты всех остальных от ошибки одного болвана. Конечно, если после компрометации первоначального сайта вы предположили, что я использовал тот же пароль, вы были бы золотым. Но, если бы не было прямого способа привязать различные учетные записи на разных сайтах непосредственно ко мне, то у злоумышленника все равно было бы много работы. - person iheanyi; 16.07.2014

arrow_upward
4
arrow_downward

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

person Mike Daniels    schedule 21.12.2011
comment
Предполагая подходящую соль (большую и случайную) и алгоритм хеширования, который не подвержен грубой силе (SHA-1 слишком быстрый). Но да, основная цель соли ... она определенно не предназначена для секретности (по крайней мере, не больше, чем хэш, который она солит :) - person ; 22.12.2011
comment
Основаны ли радужные таблицы на типичных паролях на основе словаря или они вычисляются с помощью самого хэша? - person Gigi; 22.12.2011
comment
Радужные таблицы — это в основном предварительно сгенерированные хэши с использованием одной и той же хэш-функции. для строки длиной, скажем, 4, все 4 комбинации длины символов генерируются и передаются через одну и ту же хеш-функцию и сохраняются. если в будущем вы получите хэш длиной 4 символа, вы просто будете искать в таблице возможных кандидатов. - person Rajesh Pantula; 22.12.2011