Почему BCrypt.net GenerateSalt(31) сразу возвращается?

StackOverflow https://stackoverflow.com/questions/2222383

  •  19-09-2019
  •  | 
  •  

Вопрос

Я наткнулся на BCrypt.net после прочтения Сообщение Джеффа Этвуда о хранении паролей что привело меня к рекомендации Томаса Птачека используйте BCrypt для хранения паролей.Что в конце концов привело меня к эта реализация BCrypt на C #

В комментариях к последней ссылке выше кто-то спросил "Почему GenerateSalt (30) длится вечно, но GenerateSalt (31), похоже, вообще не занимает времени?"

Я запустил BCrypt.HashPassword(пароль, BCrypt.Генерирует ALT(31)) и получил свой результат за 0 миллисекунд.

Я запускаю BCrypt.HashPassword("пароль", BCrypt.Генерирует ALT(30)) уже более 5 минут, и до сих пор нет результата.

Я понимаю, что нам, вероятно, не понадобится случайно сгенерированная соль из 30 символов для создания наших хэшей паролей (или необратимое шифрование в случае BCrypt) в течение многих лет. Редактировать Мне следовало немного почитать код, logRounds не имеет никакого отношения к длине соли.Спасибо, Аарон Нот.

Итак, почему GenerateSalt(31) возвращает значение почти мгновенно (хотя это должно занять примерно в два раза больше времени, чем GenerateSalt(30)?

Обновить

вот исправление:

private byte[] CryptRaw(byte[] password, byte[] salt, int logRounds) {
    // ... snip ...
    uint rounds = 1U << logRounds;
    // ... snip
}
Это было полезно?

Решение

Я подозреваю, что ошибка здесь:

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 раундов, но я подозреваю, что вместо этого конкретная реализация, которую вы используете, переполняется.:-(

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top