Растягивание пароля - способ уменьшить загрузку процессора

Question

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

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

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

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

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

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

Answer 1

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

Answer 2

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

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

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

Взгляните на механизм аутентификации ответа с солеными вызовами (SCRAM) .

Answer 3

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

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

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

Answer 4

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

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

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

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