TOC

Default Password Encoder in Spring Security 5

Default Password Encoder in Spring Security 5

1. Überblick

In Spring Security 4 war es möglich, Kennwörter mithilfe der speicherinternen Authentifizierung im Klartext zu speichern.

Eine grundlegende Überarbeitung des Kennwortverwaltungsprozesses in Version 5 hat einen sichereren Standardmechanismus für das Codieren und Decodieren von Kennwörtern eingeführt. Dies bedeutet, dass ein Upgrade auf Spring Security 5 zu Problemen führen kann, wenn Ihre Spring-Anwendung Kennwörter im Klartext speichert.

In diesem kurzen Tutorial beschreiben wir eines dieser potenziellen Probleme und zeigen eine Lösung für das Problem.

2. Federsicherung 4

Zunächst wird eine Standard-Sicherheitskonfiguration angezeigt, die eine einfache In-Memory-Authentifizierung bietet (gültig für Spring 4): 

@Configuration
public class InMemoryAuthWebSecurityConfigurer
  extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(AuthenticationManagerBuilder auth)
      throws Exception {
        auth.inMemoryAuthentication()
          .withUser("spring")
          .password("secret")
          .roles("USER");
    }

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.authorizeRequests()
          .antMatchers("/private/**")
          .authenticated()
          .antMatchers("/public/**")
          .permitAll()
          .and()
          .httpBasic();
    }
}

Diese Konfiguration definiert die Authentifizierung für alle zugeordneten Methoden von/private/und den öffentlichen Zugriff für alle unter/public/.

Wenn wir unter Spring Security 5 dieselbe Konfiguration verwenden, wird der folgende Fehler angezeigt: 

java.lang.IllegalArgumentException: There is no PasswordEncoder mapped for the id "null"

Der Fehler sagt uns, dass das angegebene Passwortcouldn’t be decoded since no password encoder was configured for our in-memory authentication ist.

3. Federsicherheit 5

Wir können diesen Fehler beheben, indem wirDelegatingPasswordEncoder mit der KlassePasswordEncoderFactoriesdefinieren.

Wir verwenden diesen Encoder, um unseren Benutzer mitAuthenticationManagerBuilder: zu konfigurieren 

@Configuration
public class InMemoryAuthWebSecurityConfigurer
  extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(AuthenticationManagerBuilder auth)
      throws Exception {
        PasswordEncoder encoder = PasswordEncoderFactories.createDelegatingPasswordEncoder();
        auth.inMemoryAuthentication()
          .withUser("spring")
          .password(encoder.encode("secret"))
          .roles("USER");
    }
}

Mit dieser Konfiguration speichern wir jetzt unser In-Memory-Passwort mit BCrypt im folgenden Format: 

{bcrypt}$2a$10$MF7hYnWLeLT66gNccBgxaONZHbrSMjlUofkp50sSpBw2PJjUqU.zS

Obwohl wir unsere eigenen Kennwortcodierer definieren können, wird empfohlen, die inPasswordEncoderFactoriesangegebenendefault encoders beizubehalten.

3.1. Bestehende Passwörter migrieren

Wir können vorhandene Kennwörter auf die empfohlenen Spring Security 5-Standards aktualisieren, indem wir:

  • Aktualisieren von im Klartext gespeicherten Passwörtern mit ihrem codierten Wert: 

String encoded = new BCryptPasswordEncoder().encode(plainTextPassword);

  • Das Präfixieren von gespeicherten Passwörtern mit ihrer bekannten Encoder-ID: 

{bcrypt}$2a$10$MF7hYnWLeLT66gNccBgxaONZHbrSMjlUofkp50sSpBw2PJjUqU.zS
{sha256}97cde38028ad898ebc02e690819fa220e88c62e0699403e94fff291cfffaf8410849f27605abcbc0

  • Benutzer auffordern, ihre Passwörter zu aktualisieren, wenn der Verschlüsselungsmechanismus für gespeicherte Passwörter unbekannt ist

4. Fazit

In diesem kurzen Beispiel wurde eine gültige speicherinterne Spring 4-Authentifizierungskonfiguration auf Spring 5 aktualisiert, wobei der neue Kennwortspeichermechanismus verwendet wurde.

Wie immer finden Sie den Quellcode aufGitHub project.

Related