Standard passordkoder i Spring Security 5

1. Oversikt

I Spring Security 4 var det mulig å lagre passord i ren tekst ved hjelp av autentisering i minnet.

En større overhaling av passordadministrasjonsprosessen i versjon 5 har innført en sikrere standardmekanisme for koding og dekoding av passord. Dette betyr at hvis Spring-applikasjonen lagrer passord i ren tekst, kan oppgradering til Spring Security 5 føre til problemer.

I denne korte opplæringen vil vi beskrive et av disse potensielle problemene og demonstrere en løsning.

2. Vårsikkerhet 4

Vi starter med å vise en standard sikkerhetskonfigurasjon som gir enkel autentisering i minnet (gyldig for Spring 4):

@Configuration offentlig klasse InMemoryAuthWebSecurityConfigurer utvider WebSecurityConfigurerAdapter {@Override-beskyttet ugyldig konfigurering (AuthenticationManagerBuilder auth) kaster unntak {auth.inMemoryAuthentication () .withUser ("spring") .password ("secret") ".roles;" } @ Override-beskyttet tomkonfigurasjon (HttpSecurity http) kaster unntak {http.authorizeRequests () .antMatchers ("/ private / **"). Godkjent () .antMatchers ("/ public / **") .permitAll (). Og () .httpBasic (); }} 

Denne konfigurasjonen definerer autentisering for alle /privat/ kartlagte metoder og offentlig tilgang for alt under /offentlig/.

Hvis vi bruker den samme konfigurasjonen under Spring Security 5, får vi følgende feil:

java.lang.IllegalArgumentException: Det er ingen PasswordEncoder kartlagt for id "null"

Feilen forteller oss at det gitte passordet kunne ikke dekodes siden ingen passordkoder ble konfigurert for autentisering i minnet.

3. Vårsikkerhet 5

Vi kan fikse denne feilen ved å definere en DelegeringPasswordEncoder med PasswordEncoderFactories klasse.

Vi bruker denne koderen til å konfigurere brukeren vår med AuthenticationManagerBuilder:

@Configuration offentlig klasse InMemoryAuthWebSecurityConfigurer utvider WebSecurityConfigurerAdapter {@Override-beskyttet ugyldig konfigurering (AuthenticationManagerBuilder auth) kaster Unntak {PasswordEncoder encoder = PasswordEncoderFactories.createDelegatingPasswordEncoder (); auth.inMemoryAuthentication () .withUser ("spring") .password (encoder.encode ("secret")) .roles ("USER"); }} 

Nå, med denne konfigurasjonen, lagrer vi passordet vårt i minnet ved hjelp av BCrypt i følgende format:

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

Selv om vi kan definere vårt eget sett med passordkodere, anbefales det å holde oss til standardkoderne gitt i PasswordEncoderFactories.

3.2. NoOpPasswordEncoder

Hvis vi av en eller annen grunn ikke vil kode det konfigurerte passordet, kan vi benytte oss av NoOpPasswordEncoder.

For å gjøre det, prefikser vi bare passordfrasen vi gir til passord() metoden med {noop} identifikator:

@Configuration offentlig klasse InMemoryNoOpAuthWebSecurityConfigurer utvider WebSecurityConfigurerAdapter {@Override beskyttet ugyldig konfigurering (AuthenticationManagerBuilder auth) kaster Unntak {auth.inMemoryAuthentication () .withUser ("spring") .password ("{no};" }} 

På denne måten vil Spring Security bruke NoOpPasswordEncoder under panseret når det sammenligner passordet som oppgis av brukeren, med det vi konfigurerte ovenfor.

Merk imidlertid at vi aldri skal bruke denne tilnærmingen på produksjonsapplikasjonen! Som den offisielle dokumentasjonen sier, er NoOpPasswordEncoder er utfaset for å indikere at det er en eldre implementering, og bruk av den anses som usikker.

3.3. Migrere eksisterende passord

Vi kan oppdatere eksisterende passord til de anbefalte Spring Security 5-standardene ved å:

  • Oppdatere lagrede passord med ren tekst med verdien kodet:
Streng kodet = ny BCryptPasswordEncoder (). Koding (plainTextPassword); 
  • Forhåndsbestilling hash lagrede passord med deres kjente koderen identifikator:
{bcrypt} $ 2a $ 10 $ MF7hYnWLeLT66gNccBgxaONZHbrSMjlUofkp50sSpBw2PJjUqU.zS {sha256} 97cde38028ad898ebc02e690819fa220e88c62e0699403cbffdfd 
  • Ber brukere om å oppdatere passordene når kodemekanismen for lagrede passord er ukjent

4. Konklusjon

I dette raske eksemplet oppdaterte vi en gyldig Spring 4-autentiseringskonfigurasjon i minnet til Spring 5 ved hjelp av den nye passordlagringsmekanismen.

Som alltid kan du finne kildekoden på GitHub-prosjektet.


$config[zx-auto] not found$config[zx-overlay] not found