Хранение хеша соль + пароль в БД и защита от парольной атаки

Question

Пожалуйста, помогите мне с моим пониманием.Также я не говорю об обмене ключами SSL или DH.Поскольку соль хранится в БД и является для злоумышленника секретом, позволяющим просто защитить исходный пароль пользователя (таблицы Rainbow), на случай, если злоумышленник получит руку на саму БД.Тогда как вы будете защищаться от атак методом перебора или словаря.Еще раз, регистрация неправильных запросов и отказ в IP многих плохих запросов известна, я говорю о криптографии здесь.Так как пароль для user1 такой же, злоумышленник получил его с других сайтов, как соль защищает здесь.Наверное, нет, тогда какие есть лучшие решения, чтобы остановить такие атаки?Предположим, что данные действительно важны, такие как номера кредитных карт + CVV (я знаю, не храните CVV, но это не вопрос).

РЕДАКТИРОВАТЬ: Кстати, я пришел с какой-то глупой идеей, и это похоже на известный метод для остановки атак по словарю.Подробнее об этом вопросе: Высокая стоимость шифрования, но меньшая стоимость дешифрования

Может быть, мы сможем обсудить здесь некоторые другие методы защиты от атаки паролем / словарём / социальной инженерией

Answer 1

Мне немного неясно, каков ваш настоящий вопрос, но если он звучит так: «Как соль помогает защитить меня от атак грубой силой?» Ответ в том, что технически это не так. В соли нет ничего, что затрудняло бы атаки методом "грубой силы", а соли затрудняли одновременную обработку нескольких учетных записей методом "грубой силы". По сути, соли искусственно раздувают пространство поиска, необходимое для проведения атаки методом перебора, что затрудняет вычислительные вычисления для предварительного расчета каждого возможного пароля и проверки его по всей базе данных. Соли могут храниться в открытом виде, если они уникальны для каждого пароля.

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

То, что все это сводится к тому, что вы должны использовать bcrypt, если вы хэшируете пароли. Он предназначен для включения соли и является адаптивной системой хеширования. Для получения дополнительной информации см. эту статью на security.stackexchange.com

Answer 2

О соли: Если вы ищете зашифрованный пароль "MD5" с помощью поисковой системы, такой как Google, здесь вы можете найти оригинальный простой пароль. Но если вы смешаете соль в своем простом пароле и затем примените шифрование "MD5", вы не сможете его найти. Если какой-либо хакер каким-либо образом взломает вашу базу данных и если вы используете только шифрование MD5, то он может использовать вышеуказанный метод для взлома паролей. Например, Поиск этой строки в Google: 5f4dcc3b5aa765d61d8327deb882cf99, вы получите оригинальную строку пароля. Соль в основном добавляется для защиты от таких атак.

Проверьте здесь . Посмотрите на Просто содержание и концепцию здесь, чтобы понять. Это из документов безопасности Spring.

Answer 3

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

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

Answer 4

Без соли злоумышленник может использовать автономную атаку для предварительного вычисления хэша общих паролей: «секрет», «qwerty» и т. Д. Никакая соль не позволяет злоумышленнику определить, когда разные пользователи используют один и тот же пароль, поскольку у них будетте же хеши.Соль предотвращает предварительный расчет и позволяет избежать проблемы с совпадающим хешем.

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

Использование растяжения (повторное хеширование) также может замедлить атакующего.Вместо хранения hash(password + salt) вы сохраняете hash^n(password + salt), где n достаточно велико, чтобы общий расчет занимал не менее 0,1 секунды.Это ограничивает атакующего до десяти попыток в секунду, не оказывая заметного влияния на пользователя.