Использование PBKDF2 в сочетании с AES-KW подрывает использование хешей паролей BCrypt?

В настоящее время мы внедряем шифрование в конверте для нашего приложения. Это означает, что нам необходимо получить ключ из пароля пользователя, который затем будет использоваться в качестве ключа шифрования ключа (KEK) для обертывания другого ключа с использованием алгоритма AES-KW. В основном, в нашей базе данных обернутый ключ (который является ключом шифрования данных в нашем случае) будет храниться в той же схеме, что и хеши паролей пользователя в BCrypt.

Меня беспокоит: согласно RFC 3394, §2.2.3.1 всегда имеется постоянное начальное значение, предваряющее обернутый ключ для проверки целостности ключа. Однако в этом случае злоумышленник может просто попробовать перебрать алгоритм PBKDF2, итерируя пространство паролей, попробовать развернуть ключ с помощью производного KEK и проверить, совпадает ли начальное значение развернутого ключа с A6A6A6A6A6A6A6A6. В случае совпадения он не только сможет развернуть ключ, но и получить пароль пользователя, таким образом обходя BCrypt.

Пример:

Предположим, пользователь выбирает пароль из 5 символов [A-Za-z0-9]. Это означает, что кардинальность пространства паролей составляет (26 + 26 + 10)^5 = 62^5 ~ 9.16e8.

Наша текущая идея:

PBKDF2 с HMAC-SHA512 при 100.000 итерациях

BCrypt (предположим среднее время выполнения 0.1с на хеш)

Таким образом, для перебора PBKDF2 потребуется ~9.16e13 оценок хешей SHA512. Я искал на eBay и нашел стойки (в основном для добычи биткойнов) за $150 с хеш-скоростью 1TH/s (это означает 1e12 H/s). Это означает, что в среднем потребуется 9.16e1=91.6с для перебора пароля из 5 символов.

Используя пример с BCrypt, предположим 16 ядер + гипертрейдинг -> 320 BCrypt H/s на одном устройстве. Таким образом, потребуется 2862915.1с для перебора того же пароля на BCrypt, что составляет 33 дня.

Теперь основной вопрос:

почему OWASP все еще рекомендует PBKDF2, несмотря на легкую параллелизацию SHA хешей на GPU? Может быть, будет лучше получить ключ с sha256(bcrypt(password, salt)) вместо pbkdf2(password, salt)? Или, возможно, даже pbkdf2(bcrypt(password, salt), salt)?

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

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

Вам следует отказаться как от PBKDF2, так и от bcrypt. Это устаревшие алгоритмы, которые предлагают мало защиты от атак с использованием специализированного оборудования. Вместо этого переключитесь на современный алгоритм, такой как Argon2. Его можно использовать для одновременного получения ключа и проверочного хеша из пароля. Просто сделайте выход достаточно длинным. Например, если вам нужен 128-битный ключ AES и 128-битный хеш пароля, то генерируйте 256-битный вывод с Argon2. Используйте первую половину в качестве ключа AES и храните вторую половину в качестве хеша пароля.