spring-io/cve-2022-22976-bcrypt-skips-salt脆弱なwork factor 31を持つBCryptパスワードハッシュを検出・更新し、CVE-2022-xxxxの修正のためにSpring Securityデータベースと統合するCLIツール。
CVE-2022-xxxx の緩和対策のために、このツールを使用してデータベース内の更新が必要なハッシュを確認できます。
アプリケーションを データベースと統合 した後、ツールは2つのステップで動作します。
これを実証するために、インメモリのサンプルアプリケーションが使用されます。
そのサンプルアプリケーションで、次のように check ステップを実行できます：
./mvnw spring-boot:run@check
これにより、サンプルデータベース内の更新が必要なBCryptハッシュがチェックされます。
次に、次のように update ステップを実行できます：
./mvnw spring-boot:run@update
これにより、サンプルデータベースで検出された脆弱なハッシュの更新が試みられます。
サンプルアプリケーションは、提供されている VulnerabilityCheck クラスを使用して、各パスワードハッシュをチェックおよび更新します。
警告: アプリケーションを更新してラウンド数を31未満にした後でのみ、これらの手順を進めてください。 OWASPは現在、値10を推奨していますが、一部の高性能システムでは16もの高い値が使用されることがあります。
このツールには、テスト用のインメモリサンプルが含まれています。 それを、自分のデータと統合する独自のクラスに置き換える必要があります。
これを行うには、まずこのリポジトリをクローンします。
次に、sample パッケージ内のコードを、アプリケーションのパスワードデータにアクセスできるコードに置き換えます。
既存のパスワードが脆弱かどうかをチェックするコードを記述するとよいでしょう。
影響を受けたハッシュを更新するコードを記述する必要があります。
どちらの場合も、VulnerabilityCheck を使用して特定のハッシュをチェックおよび更新できます。
ヒント: 上記のコードを作成する際は、更新する必要があるパスワードの数を考慮してください。 データベース接続の失敗、コンピュータのクラッシュ、メモリ不足などが発生する可能性があることを考慮に入れてください。 例えば、何百万ものレコードを一度にメモリに読み込むことは推奨されません。
パスワードハッシュを更新した後、最新のSpring Securityにアップデートできます。 Spring Securityのパスワード更新機能を使用している場合、ユーザーがログインすると、パスワードは自動的に新しく設定したラウンド値に再ハッシュされます。
Q: 自分のハッシュが脆弱かどうかはどうやってわかりますか？
A: Spring Securityの BCrypt クラスでワークファクター31を使用してハッシュ化された場合、脆弱です。
システム内でSpring Securityが管理するパスワードハッシュを確認することで確認できます。
それらが '{bcrypt}$2a$31', '{bcrypt}$2b$31', '{bcrypt}$2y$31', '{bcrypt}$2$31', '$2a$31', '$2b$31', '$2y$31', または '$2$31' で始まる場合、そのパスワードは脆弱であり、更新が必要です。
Q: アプリケーションをどのように変更すればよいですか？
A: OWASPはBCryptにワークファクター10を推奨しています。 一部の高性能システムでは16もの高い値が使用されます。 システムごとに異なり、BCryptは必要に応じて時間とともにワークファクターを増やせるように設計されています。
Q: アプリケーションのどこを変更すればよいですか？
A: おそらく、次のように BCryptPasswordEncoder を構築してワークファクターを設定しているでしょう：
new BCryptPasswordEncoder(31)
以下のようなBean定義に現れるかもしれません：
@Bean
public PasswordEncoder passwordEncoder() {
return new BCryptPasswordEncoder(31);
}
その文字列を探して更新してください。 ワークファクターがアプリケーションの外部プロパティによって駆動されている可能性があることに注意してください。その場合は、代わりに外部設定で変更する必要があります。
Q: Spring Securityを更新したところ、一部またはすべてのログインとユーザー登録がハングしています。何が起きましたか？
A: Spring Security 5.5.7+、5.6.4+、5.7.0+ 以降では、ワークファクター31を示すパスワードハッシュ（例えば '{bcrypt}$2a$31', '{bcrypt}$2b$31', '{bcrypt}$2y$31', '{bcrypt}$2$31', '$2a$31', '$2b$31', '$2y$31', または '$2$31' で始まるもの）は、各ハッシュ計算に2〜3日かかります。 これを軽減するには、Spring Securityをより低いラウンド数を使用するように変更する必要があります。 その後、このツールを使用して脆弱なパスワードハッシュを更新してください。
Q: 推奨される3つのステップ（BCryptPasswordEncoderの設定変更、パスワードハッシュの更新、Spring Securityの更新）をすべて完了しました。変更したパスワードハッシュが新しく設定したワークファクターに更新されません。どうすればよいですか？
UserDetailsPasswordService 型のBeanが公開されていることを確認してください。
このBeanは、パスワードを新しいBCryptのログラウンドに更新するために使用されます。
Q: なぜSpring Securityはアップグレード時にこのツールを使わずに脆弱なパスワードを単純に更新できないのですか？
第一に、最新のSpring Securityでは、ワークファクター31のパスワードハッシュは正しく計算されるため、それぞれに2〜3日かかります。 これがアプリケーションにとって合理的なコストであると想定するのは非現実的です。
第二に、Spring Securityはワークファクターの増加（例えば10から12）のみをサポートしており、減少（例えば31から10）はサポートしていません。