Вы утверждаете, что скорость алгоритма не важна, но на самом деле это важно.
Многое зависит от определения «безопасный», SHA512
(почти) невозможно повернуть вспять, но на самом деле довольно легко атаковать грубой силой .
Это потому, что он быстрый - его можно считать фундаментальным недостатком «семейства» SHA в том, что он разработан очень быстро.
Это проблема - SHA512
достигает своей цели - быть очень быстрым (это не намного медленнее, чем SHA1
), но если вы хакер, пытающийся взломать пароли, которые облегчают взлом. 10 или даже 5 лет назад о серьезной атаке грубой силой не могло быть и речи, теперь это пара модных видеокарт или какое-то облачное время.
Именно здесь вступают в действие алгоритмы растяжения ключей - они делают процесс создания хэша пароля преднамеренно медленным . Достаточно медленно, чтобы пользователи, проверяющие отдельный хеш, не заметили, но атака грубой силой займет слишком много времени.
Хорошим примером алгоритма растягивания ключа является RFC2898 или PBKDF2 - он использует длинную соль и тысячи раз выполняет алгоритм SHA для создания хэша, который медленно воспроизводится.
.Net имеет собственную реализацию этого: Rfc2898DeriveBytes
Они используют его для System.Web.Crypto.HashPassword
, но вы можете легко просмотреть их источник , чтобы использовать его в другом месте.
На моем компьютере (довольно старомодном ноутбуке) один хеш .Net Rfc2898DeriveBytes
с 1000 итерациями (по умолчанию) занимает около 50 мс, в то время как я могу перебрать около 250 000 хешей SHA512 в секунду.
Так что в .Net сейчас наиболее безопасным вариантом является использование Rfc2898DeriveBytes
.
Однако RFC2898 / PBKDF2 имеет слабость - хотя медленные параллельные вычисления становятся все дешевле и дешевле, и для создания каждого хеша не требуется много памяти. Прямо сейчас это довольно грубым, но через 5 или 10 лет?
Таким образом, следующее поколение - это алгоритмы типа bcrypt / scrypt , предназначенные для использования большого количества памяти для каждого хэша, что делает дорогостоящее параллельное выполнение. Хотя существуют реализации .Net, их нет (пока), и я бы с осторожностью использовал их до тех пор, пока они не появятся - их использование повлияет на такие вещи, как одновременный вход в систему (если используется для паролей), и поэтому большой риск для ранних последователей.