Как использование соли делает пароль более безопасным, если он хранится в базе данных?

В настоящий момент я изучаю Rails, но ответ не должен быть специфичным для Rails.

Итак, насколько я понимаю, система безопасных паролей работает так:

  • Пользователь создает пароль
  • Система шифрует пароль с помощью алгоритма шифрования (скажем, SHA2).
  • Хранить хэш зашифрованного пароля в базе данных.

При попытке входа в систему:

  • Пользователь пытается войти
  • Система создает хэш попытки с тем же алгоритмом шифрования
  • Система сравнивает хэш попытки с хешем пароля в базе данных.
  • Если совпадают, их впускают. Если нет, им нужно попробовать еще раз.

Насколько я понимаю, этот подход подвержен радужной атаке, при которой может произойти следующее.

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

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

Однако эта соль хранится в столбце «соль» базы данных.

Итак, мой вопрос: как это меняет тот факт, что если злоумышленник получил доступ к базе данных в первую очередь и создал хэш для `` настоящего '' пароля, а также имеет хеш для соли, то почему это не так подвержен радужной атаке? Потому что теория будет такова, что он пробует каждую перестановку + хэш соли и сравнивает результат с хешем пароля. Это может занять немного больше времени, но я не понимаю, насколько это надежно.

Простите мое невежество, я просто изучаю этот материал, и это никогда не имело для меня особого смысла.


encryption passwords cryptography salt
person marcamillion    schedule 23.10.2010    source источник
comment
См. Принятый ответ на этот вопрос; stackoverflow.com/questions/1219899 / Он объясняет, как хэш предотвращает радужные атаки.   -  person nickd    schedule 24.10.2010
comment
возможный дубликат Где вы храните строки соли?   -  person blowdart    schedule 24.10.2010
comment
Это действительно объясняет мне идею радужной таблицы (то есть противоречит идее выполнения грубой силы str8 для каждой перестановки путем выполнения предварительных вычислений / предположений в форме радужной таблицы). Но я до сих пор не понимаю, почему так невозможно взломать в наши дни, когда вычислительные ресурсы так дешевы.   -  person marcamillion    schedule 24.10.2010
comment
Неа. Я не защищаю и не спрашиваю, имеет ли смысл хранить соль в другом месте, чем в db. Я пытаюсь исследовать идею о том, насколько соль на самом деле более безопасна в эпоху, когда вычислительные ресурсы настолько дешевы.   -  person marcamillion    schedule 24.10.2010
comment
Это не невозможно - если у вас будет достаточно времени, вы сможете перебрать хеш-код с помощью перебора. Вот почему вы все еще пытаетесь сохранить конфиденциальность своей базы данных :) И, конечно же, это не единственное соображение. Другие включают использование хорошего алгоритма хеширования - многие из них ориентированы на быстрое хеширование, что противоположно тому, что вы хотите при хешировании паролей.   -  person Nick    schedule 24.10.2010
comment
@Ник. Довольно. Многие стандарты предлагают хешировать соленые пароли несколько раз (обычно ›1000), потому что требуемые дополнительные вычисления не сильно затрудняют проверку одного пароля, но значительно затрудняют атаки методом перебора.   -  person dajames    schedule 26.10.2010
comment
BCrypt - один из алгоритмов, в который встроена такая защита. Еще лучше то, что вы можете настроить количество раундов шифрования, так что по мере того, как компьютеры становятся быстрее, вы можете просто увеличивать сложность для новых хэшей.   -  person Nick    schedule 26.10.2010
comment
SHA-2 - это алгоритм хеширования. Хеширование - это другое понятие по сравнению с шифрованием.   -  person wulfgarpro    schedule 23.11.2016

Ответы (3)


arrow_upward
8
arrow_downward

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

Учтите, что соль не нужно держать в секрете; он просто должен быть достаточно большим (например, 64-битным) и достаточно случайным, чтобы два человека, использующие один и тот же пароль, имели исчезающе малый шанс использовать одну и ту же соль. (При желании вы можете проверить уникальность соли.)

person Jonathan Leffler    schedule 23.10.2010
comment
Ох, хорошо. Таким образом, идея состоит в том, что злоумышленник не будет проводить атаку методом грубой силы (сравнивая строку с солью с хешем pw в базе данных), потому что это занимает слишком много времени - при условии, что хэш salt + pw достаточно длинный (64-битный кусок)? Если это так, то разве это не имеет особого смысла в наши дни, когда огромные вычислительные ресурсы становятся дешевле / бесплатными? Например, если злоумышленник имеет доступ к ботнету из 1 миллиона компьютеров, почему он не может написать сценарий, который просто выполняет это сравнение методом грубой силы каждой соли с этим миллионом машин? - person marcamillion; 24.10.2010
comment
Перебор хэша занимает довольно много времени, и даже если бы это было так просто, как вы предполагаете, вы все равно остановили бы любого, не имея в своем распоряжении миллиона компьютерных ботнетов. - person ceejayoz; 24.10.2010
comment
Цель состоит в том, чтобы сделать взлом паролей труднее, чем другие методы атаки. Если злоумышленник может прочитать базу данных И имеет достаточно времени вычислений, чтобы построить радужную таблицу для значения соли для каждой учетной записи, которую хочет злоумышленник, то либо вы, либо злоумышленник неправильно оценили риск / ценность взлома вашего сайта. - person Slartibartfast; 25.10.2010
comment
Конечно, из-за этого грубая сила становится проблемой. Это не усложняет задачу, если злоумышленник действительно скомпрометировал базу паролей, где соль хранится в виде обычного текста. - person wulfgarpro; 23.11.2016

arrow_upward
8
arrow_downward

Во-первых, то, что вы описали, - это не радужная атака, а словарная атака.

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

Чтобы иметь хоть какую-то надежду на эффективность, словарь должен включать что-то вроде миллиона входных данных (и миллион совпадающих результатов). Вы упомянули SHA-1, поэтому давайте воспользуемся этим в нашем примере. Он дает 20-байтовый (160-битный) результат. Предположим, что средний ввод составляет около 8 символов. Это означает, что словарь должен быть примерно 28 мегабайт. Однако с 32-битной солью размер и время создания словаря умножаются на 2 32 -1.

В качестве чрезвычайно грубого приближения, скажем, создание (несоленого) словаря заняло час. То же самое с 32-битной солью займет 2 32 -1 часа, что составляет около 15 лет. Не так много людей, готовых тратить столько времени на атаку.

Поскольку вы упомянули радужные таблицы, я добавлю, что они, как правило, даже больше и медленнее для начала. Типичная радужная таблица легко заполнит DVD, и умножение этого на 2 32 -1 дает достаточно большое число, чтобы хранение также стало серьезной проблемой (например, это больше, чем все встроенное хранилище вся история компьютеров, по крайней мере, на планете Земля).

person Jerry Coffin    schedule 23.10.2010
comment
Хорошо, достаточно честно. Ваша математика имеет смысл. Я понимаю, что эта атака не является надежной, но достаточной, чтобы удержать «неопределенных» злоумышленников. Но будет справедливо сказать, что использование хеша + соли все еще может быть взломано, не так ли? Например, эти 15 лет можно значительно сократить, если 100 000 компьютеров будут выполнять вычисления или даже 1 миллион. Если вы предполагаете, что у злоумышленника есть практически неограниченные вычислительные ресурсы, чтобы решить эту проблему (например, скажем, что он взломал Google и имеет доступ ко всем серверам Google - неправдоподобно, но просто иллюстрирует точку зрения), то атака по словарю имеет смысл, верно? - person marcamillion; 24.10.2010
comment
2 ^ 32-1 бит = 4294967295 бит = 536 МБ. Если вы не имели в виду 2 ^ 32-1 * 32 бита, то это не так много памяти. Даже тогда 2 ^ 32-1 * 32 = 17,179 ГБ. - person marcamillion; 24.10.2010
comment
@marcmillion: вам также необходимо объединить результаты, поэтому даже при большом количестве серверов вам также потребуется хорошее общение, координация и т. д., чтобы сделать это (но да, в конечном итоге это возможно). Не уверен, куда вы пытаетесь пойти со своей математикой. Каждый бит, который вы добавляете к ключу, удваивает размер словаря. - person Jerry Coffin; 24.10.2010
comment
@marcamillion Злоумышленнику потребуется столько памяти per_password, если он хочет генерировать каждый хеш для каждой соли. Конечно, на практике им потребуется меньше из-за того, как работают радужные таблицы, но требуемый объем хранилища по-прежнему непомерно высок. - person Nick Johnson; 24.10.2010
comment
Я согласен и просто подумал, возможно ли это в конечном итоге. @ Ник, ааа ... в этом есть смысл. Интересный. Спасибо, что объяснили это. - person marcamillion; 24.10.2010

arrow_upward
1
arrow_downward

Атакующий не может провести атаку по радужному столу и вынужден прибегать к грубой силе, что намного менее эффективно.

person Florian Mayer    schedule 23.10.2010