より安全なパスワードエンコード方式に切り替える場合は、BCryptを使用することをおすすめします。私はあなたのユーザーを移行するために、このようなものを使用します。
// Implement the old PasswordEncoder interface
public class MigrateUsersPasswordEncoder implements PasswordEncoder {
@Autowired
ShaPasswordEncoder legacyEncoder;
@Autowired
JdbcTemplate template;
BCryptPasswordEncoder bcryptEncoder = new BCryptPasswordEncoder();
@Override
public String encodePassword(String rawPass, Object salt) {
return bcryptEncoder.encode(rawPass);
}
@Override
public boolean isPasswordValid(String encPass, String rawPass, Object salt) {
if (legacyEncoder.isPasswordValid(encPass, rawPass, salt)) {
template.update("update users set password = ? where password = ?", bcryptEncoder.encode(rawPass), encPass);
return true;
}
return bcryptEncoder.matches(rawPass, encPass);
}
}
あなたは、ユーザーの割合は、パスワードフィールドのフォーマットによって移行されているかどうか確認することができます。 BCrypt文字列には、$という記号で始まる固有の構文があります。
他の回答の1つは、このコードが誤って複数のパスワードを同時に更新する可能性があることを指摘しています。疑問は、カスタム塩が使用されていると述べたので、塩が無作為に選択されれば衝突の可能性はごくわずかですが、必ずしもそうではないかもしれません。 2つのパスワードが更新された場合は、どのような問題がありますか？次に、アカウントがbcryptハッシュから同じパスワードを持つことを検出することが可能になります。とにかく、更新のためにSHAハッシュが同じであることが必要なので、それはどちらの場合もそうです。塩分の選択が悪い、または無塩ハッシュの使用さえも問題があると思われる場合は、SQLを修正してこれを検出し、別々のBCryptハッシュ値で複数の更新を実行するのは簡単です。
ありがとうコードです。これは多かれ少なかれSpiffが提案したものです。ここでの私の目標は、2つの実装を同時に行うことなくSpring Securityの将来のリリースにアップグレードできることです。また、このソリューションはすべてのユーザーがサインインする場合にのみ機能します。古いものと互換性のある実装が導入されることを願っていますShaPasswordEncoder。 –
ユーザーがサインインしない場合は、適切な審査期間の後にアカウントを維持する価値があるかどうかを判断する価値があります。それらが非アクティブである場合、それらを一時的に無効にし、ユーザーにパスワードをリセットするように頼むメールを送ることができます。古いパスワードエンコーダの使用は、比較的安全ではなく、エラーが発生しやすく、他のシステムと互換性がないため、使用しないでください。クラスは新しいアプリケーションでの使用を阻止するために推奨されていませんが、より安全なオプションを使用したくない場合は、クラスを使用することを止めるものはありません。 –