Скорость может быть преимуществом по одной причине и недостатком по другой.
Когда дело доходит до безопасности паролей, низкие требования к процессору/памяти криптографического хэша имеют недостаток, а именно, если записи или база данных будут раскрыты или взломаны, злоумышленнику придется выполнить минимальную работу, чтобы перебрать эти хэши в открытый текст. пароль.
Это связано с тем, что пароли обычно короткие и имеют меньшую энтропию, чем безопасность прообраза хеш-функции. Если пароли огромные и случайные, скажем, 32 случайных буквы и цифры, то одной быстрой итерации хеш-функции более чем достаточно.
В целях безопасности вы хотите, чтобы «функция хэширования паролей» занимала столько времени (вычислительных ресурсов) и памяти, сколько возможно для замедления массовых атак. Однако это становится недостатком для сервера, который сравнивает хэш со значением базы данных, поскольку в большинстве случаев этот сервер должен вычислять хэш из предоставленного пользователем пароля.
Злоумышленник может воспользоваться этим недостатком, потребляя большое количество ресурсов за счет скоординированных массовых попыток входа в систему с известными или ожидаемыми именами пользователей, что фактически представляет собой атаку типа «отказ в обслуживании» с низкой пропускной способностью, когда сервер настолько занят отслеживанием фиктивных попыток входа в систему, что реальные пользователи не могут войти в систему.Это можно смягчить, регулируя количество попыток доступа для каждого IP-адреса и имени пользователя, а также добавляя задержку перед отображением ошибки входа. Если пользователь не существует, сервер не должен хэшировать пароль, а должен вернуть ошибку с соответствующей задержкой, как если бы пользователь существовал, чтобы злоумышленник не мог сделать вывод о наличии имен пользователей в базе данных.
PBKDF2 — чрезвычайно распространенный хэш паролей, и в своей основе он обычно использует HMAC, поэтому что-то вроде 40000 циклов PBKDF2-HMAC-SHA256 на самом деле может занять примерно в 80000 раз больше времени, чем одна итерация хеширования. Если ранее сервер мог выполнять 4 миллиарда итераций хеширования в секунду, то теперь он может выполнять только 50 000 хэшей PBKDF2, прежде чем полностью загрузит свой ЦП. Если вы хотите, чтобы на проверку паролей выделялось не более 10 % ресурсов, их нужно ограничить до 5 000 попыток входа в секунду... что может показаться много, но как вы думаете, сколько людей входит в что-то вроде Gmail, Lastpass или Salesforce около 9 утра в понедельник?
Должна быть сбалансированная конфигурация и достаточно оборудования, чтобы обрабатывать все входы пользователей даже при большой нагрузке без заметной задержки для этих пользователей и предотвращать отказ злоумышленников в обслуживании этих пользователей. Надежность хэша пароля может также меняться с течением времени по мере увеличения ресурсов злоумышленников, изменения моделей угроз и т. д. Стоимость ущерба репутации может быть во много раз выше, чем стоимость оборудования для выполнения очень дорогих хэшей паролей.
Есть ли другие ситуации, когда скорость является недостатком? Внезапно я действительно не могу придумать ни одного, хеш-функции обычно используются как часть схемы, например, цифровые подписи с задействованным вычислительно дорогим асимметричным алгоритмом, безопасность в этом случае зависит от размера хэша и эффективная сила ключа подписи, а не скорость хэша.
