Растяжение пароля - способ смягчить затопление ЦП

Сейчас я использую пароли для всех паролей учетных записей пользователей на всех моих сайтах. В БД я храню счетчик итераций и случайно назначенную соль вместе с окончательным хешем. Я использую SHA512 в качестве алгоритма хеширования. Я использую C# в.Net 3.5 и 4.0 (библиотека с двумя фреймворками) для этого.

Для учетных записей, которые получают только случайно назначенные пароли (например, пользователи API веб-служб и т. Д.), Я уменьшаю счет итераций до такого диапазона, чтобы проверка пароля занимала не более 1 секунды или около того. С годами, в зависимости от того, придерживаются ли эти сайты (!), Я буду смотреть на увеличение этих диапазонов в соответствии с мощностью процессора.

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

Так что я доволен безопасностью своих паролей; но теперь у меня есть другая проблема - я могу залить 8-ядерный процессор со 100% использованием в течение 5 секунд, если я получу 8 разных пользователей для входа в систему одновременно!

Мое текущее решение состоит в том, чтобы иметь порог итерации: если операция растяжения превышает это, я помещаю ее в очередь, которая обрабатывается одним потоком. Я мог бы расширить это так, чтобы он использовал не более половины процессоров в машине.

Что я могу сделать лучше? Вы реализовали этот шаблон для хранения пароля и входа в систему - что вы делали?

Источник

4 ответа

Решение

Идея расширения пароля заключается в том, чтобы злоумышленник выполнил тяжелую работу:

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

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

Взгляните на Механизм Аутентификации Ответа Salted Challenge (SCRAM).

Источник

Не является ли большим преимуществом растягивания пароля, что вычисления выполняются на стороне клиента и, следовательно, они не должны влиять на ваш сервер, обеспечивая при этом хорошую защиту?
Честно говоря, если вы реализовали это на своем сервере, вы делаете это неправильно и упустили смысл:-)

Источник

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

Как сказал Джон:

Я думаю, что вы перестарались...:)

Источник

Я думаю, что применение SHA512 более одного раза не имеет никакой дополнительной ценности.

У вас есть следующий рабочий процесс аутентификации:

  1. Пользователь вводит имя пользователя и пароль в веб-форму и отправляет их на сервер в виде простого текста или через SSL;
  2. Сервер вычисляет правильный хэш / соленый хэш / что угодно, чтобы сравнить с тем, который хранится в базе данных;
  3. Сервер сравнивает хеш, вычисленный с тем, который хранится в базе данных.

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

Источник
Другие вопросы по тегам