Почему делает BCrypt.net GenerateSalt (31) возврат немедленно?
Я споткнулся через BCrypt.net после того, чтобы читать сообщение Jeff Atwood о хранении паролей, которые привели меня к рекомендации Thomas Ptacek использовать BCrypt для хранения паролей. Который наконец привел меня к этой реализации C# BCrypt
В комментариях к последней ссылке выше кого-то спросил, "Почему делают GenerateSalt (30) берут навсегда, но GenerateSalt (31), кажется, не торопится вообще?"
Я выполнил BCrypt. HashPassword (пароль, BCrypt. GenerateSalt (31)), и получил мой результат в 0 миллисекундах.
Я выполнял BCrypt. HashPassword ("пароль", BCrypt. GenerateSalt (30)) больше 5 минут теперь и все еще не имеют результата.
Я понимаю, что нам, вероятно, не будут нужны случайным образом сгенерированные 30 символьных солей для создания наших хэшей пароля (или необратимое шифрование в случае BCRYPT) в течение многих лет. РЕДАКТИРОВАНИЕ я должен был прочитать код немного, logRounds, не имеет никакого отношения к соленой длине. Спасибо Aaronaught.
Так, почему делает GenerateSalt (31), возвращают значение почти немедленно (когда он должен сопроводить в два раза длиннее, чем GenerateSalt (30)?
ОБНОВЛЕНИЕ
вот фиксация:
private byte[] CryptRaw(byte[] password, byte[] salt, int logRounds) {
// ... snip ...
uint rounds = 1U << logRounds;
// ... snip
}
2 ответа
Я подозреваю, что ошибка здесь:
private byte[] CryptRaw(byte[] password, byte[] salt, int logRounds) {
// ... snip ...
int rounds = 1 << logRounds;
// ... snip
}
Когда вы указываете 31 для logRounds , он вычисляет это как 2 ^ 32, что не может вписывается в int и переполняется, поэтому хеширование фактически выполняется за ... ну, нулевые проходы. Вместо этого автору следовало использовать uint . Легко исправить!
Также хотел прокомментировать это:
Я понимаю, что нам, вероятно, не понадобится случайно сгенерированная соль из 30 символов для создания хэшей наших паролей ...
Обратите внимание, что параметр logRounds делает не относится к количеству символов / байтов в соли, которое всегда равно 16. Это относится к логарифмическому основанию количества проходов, которые хэш будет выполнять для вычисления; Другими словами, это способ масштабировать bcrypt с помощью закона Мура, делая вычисление функции на несколько порядков дороже, если компьютеры когда-либо станут достаточно быстрыми, чтобы взломать существующие хэши.
Если хеширование с помощью GenerateSalt (31) возвращается почти мгновенно, это ошибка. Вы должны сообщить об этом вверх по течению (у меня, для jBCrypt). : -)
По умолчанию лог-раундов 10. Это означает, что (если я правильно помню) используется 1024 раунда. Каждый раз, когда вы увеличиваете лог-раунды, количество раундов удваивается.
При 30 лог-раундах вы делаете 1073741824 раундов. Это по праву занимает много времени. На 31 лог-раунде должно быть выполнено 2147483648 раундов, но я подозреваю, что в конкретной реализации вы вместо этого используете переполнение. : - (