Должен ли я инициализировать 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:

случайным образом - экземпляр SecureRandom использовать

, что приводит к предсказуемым солей.

Соль должны быть (в лучшем случае) уникальны, см A Future-Adaptable Password Scheme:

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

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

коллизия соли и предсказуемая соль ослабляют вашу безопасность, см Seven Ways To Screw Up BCrypt:

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

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

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

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