Должен ли я инициализировать SecureRandom для моего BCryptPasswordEncoder с начальным числом?

Question

Я просто делаю обзор кода задачи коллег и наткнулся на следующие строки кода (он реализовывал систему входа в систему на основе Spring Security).

@Bean
public PasswordEncoder passwordEncoder(){
    return new BCryptPasswordEncoder(ENCODING_STRENGTH, new SecureRandom(SEED_BYTES));
}

Это хорошая идея, чтобы инициализировать этот конкретный SecureRandom с постоянным семенем? Я так не думаю, но не могу объяснить почему.

Answer 1

Увидеть SecureRandom:

Кроме того, SecureRandom должен производить недетерминированный вывод. Поэтому любой начальный материал, передаваемый объекту SecureRandom, должен быть непредсказуемым, а все выходные последовательности SecureRandom должны быть криптографически стойкими, как описано в RFC 1750: Рекомендации по случайности для безопасности.

Если твой SEED_BYTES является константой, это предсказуемо.

BCryptPasswordEncoder использует криптографически сильный SecureRandom только для генерации соли, см. BCrypt#gensalt:

random - экземпляр SecureRandom для использования

Это приводит к предсказуемым солям.

Соль должна быть (в лучшем случае) уникальной, см . Адаптируемую в будущем схему паролей:

Однако, как предложили Моррис и Томпсон [9], таблицы поиска могут быть сорваны со вторым входом в F, который они называют солью. Если случайная соль выбирается всякий раз, когда пользователи устанавливают новые пароли, и если пространство соли достаточно велико, чтобы обеспечить незначительную вероятность повторения, таблицы поиска не дают противнику никаких преимуществ; он может также вычислить F во время атаки. Если, с другой стороны, пространство соли слишком мало, выходные биты F становятся полезными предикатами для паролей, и этот факт используется программой QCrack [12], описанной в разделе 6.

Если вы используете постоянное семя, вы получите ту же последовательность солей после каждого перезапуска вашего приложения. Это приводит к солевым столкновениям.

Столкновение соли и предсказуемая соль ослабляют вашу безопасность, см. Семь способов испортить BCrypt:

# 1: Использование неслучайной соли

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

# 2: Использование неверного случайного источника для генерации соли

[...] Кроме того, некоторые из слабых случайных источников страдают от проблем, известных как "отравление семенами", когда злоумышленник может повлиять на случайность, создаваемую в будущем.