📚 Теория: почему SHA-256 не подходит для паролей (раскрыть)
Проблема
SHA-256 быстрый и без адаптации. Секунда — миллиарды попыток. Статичная соль из конфига только ускоряет атаку.
⚠️ Rainbow tables и GPU брутфорс вскрывают базу моментально.
Решение
Используйте адаптивные функции: BCryptPasswordEncoder, Argon2PasswordEncoder, PBKDF2 с высокими параметрами cost и pepper из KMS.
🔐 Храните pepper в Secret Manager, тестируйте силу хеша в CI.
Атакующий скачивает базу с SHA-256+staticSalt.
Кластер перебирает миллионы комбинаций в секунду.
Пароли взломаны, аккаунты в проде скомпрометированы.
Как надо: адаптивные хеши, уникальные соли, pepper из KMS, тесты на утечки секретов и проверка настроек encoder-а.
Контекст
Команда хотела совместимость с legacy, поэтому оставила SHA-256. Попутно статичная соль хранится в конфиге, что облегчает брутфорс. Нужно показать проблему и описать переход на современные практики.
- Найди, как сервис строит SHA-256 и сравнивает хеш.
- Продумай переход:
PasswordEncoderиз Spring Security, миграция хешей. - Предложи тесты: проверка, что в конфиге нет статичных секретов, encoder не SHA-1/256.
Сниппет
Code Review
Референс-исправление
Пароли нужно хешировать адаптивно. Используй BCryptPasswordEncoder или Argon2 и вынеси pepper/ключи в Secret Manager.
Флаг ревью: FLAG{java-sha256-password-review}
@Bean
public PasswordEncoder passwordEncoder(SecretService secrets) {
return new DelegatingPasswordEncoder(Map.of(
"bcrypt", new BCryptPasswordEncoder(12),
"argon2", new Argon2PasswordEncoder(16, 32, 1, 1 << 16, 3)
), "bcrypt");
}В тестах добавь проверки: encoder bean ≠ SHA-256, статические секреты отсутствуют в конфиге, password dump проходит через либу zxcvbn.
Проверка флага
После ревью зафиксируй флаг, чтобы дашборд засчитал лабораторию.