Spring Security BCryptパスワードエンコーダ - ワークロードファクタ

Question

私はSpring SecurityのBcrypt Password Encoderを新しいアプリケーションに統合していますが、テスト中にワークロードが異なると思われる2つのエンコーダを使用してパスワードを一致させると効果がないようです仕事の要素。次の例を参考にしてください。

public static void main(String[] args) { 
    PasswordEncoder strongEncoder = new BCryptPasswordEncoder(12); 
    PasswordEncoder weakEncoder = new BCryptPasswordEncoder(6); 

    String password = "SomePassword@@"; 

    String strongEncodedPass = strongEncoder.encode(password); 
    String weakEncodedPass = weakEncoder.encode(password); 

    //Prints true 
    System.out.println(weakEncoder.matches(password, strongEncodedPass)); 
    //Prints true 
    System.out.println(strongEncoder.matches(password, weakEncodedPass)); 
} 

エンコーダが異なる作業負荷を使用しているため、両方のステートメントの結果がfalseになるべきではありませんか？

上記サンプルは、塩を生成する際に、強度のみが使用されるJava 8のソースコードを読む

Answer 1

にバネセキュリティコア4.1.0.RELEASE.jarを用いて試験しました。暗号化アルゴリズム自体で使用されるラウンド数は16にハードコードされています。

だから、あなたが見るものが期待されます。しかし、なぜSpringが暗号化部分のラウンド数を選ぶことができなかったのか分かりません。ドキュメンテーションが本当に混乱しているので、バグ/機能要求でそれを通知する価値があるかもしれません。

Answer 2

あなたはbcryptの（https://en.wikipedia.org/wiki/Bcrypt）上のWikipediaの記事を見れば、あなたはハッシュの形式は、例えばラウンド

の数が含まれていることに気づくでしょう、シャドウパスワードレコード$2a$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWyはコストパラメータを指定します210の重要な展開ラウンドを示す10の値。塩はN9qo8uLOickgx2ZMRZoMyeであり、得られたハッシュはIjZAgcfl7p92ldGxad68LJZdL17lhWyである。

パスワードがハッシュと一致する場合は、元のハッシュと同じ回数だけハッシュされます。

つまり、matches()はセットアップから独立している可能性があり、おそらく静的である可能性があります。