Registrering med Spring Security - Passordkoding

Denne artikkelen er en del av en serie: • Opplæringsveiledning for vårsikkerhetsregistrering

• Registreringsprosessen med vårsikkerhet

• Registrering - Aktiver en ny konto via e-post

• Vårsikkerhetsregistrering - Send bekreftelses-e-post på nytt

• Registrering med Spring Security - Passordkoding (nåværende artikkel) • Registrerings-API-et blir RESTful

• Spring Security - Tilbakestill passordet ditt

• Registrering - Passordstyrke og regler

• Oppdatere passordet ditt

1. Oversikt

Denne artikkelen diskuterer en kritisk del av registreringsprosessen - passordkoding - lagrer i utgangspunktet ikke passordet i ren tekst.

Det er noen kodingsmekanismer som støttes av Spring Security - og for artikkelen, vi bruker BCrypt, da det vanligvis er den beste løsningen tilgjengelig.

De fleste andre mekanismer, for eksempel MD5PasswordEncoder og ShaPasswordEncoder bruke svakere algoritmer og er nå utfaset.

2. Definer passordkoderen

Vi begynner med å definere den enkle BCryptPasswordEncoder som en bønne i vår konfigurasjon:

@Bean public PasswordEncoder encoder () {return new BCryptPasswordEncoder (); }

Eldre implementeringer - som f.eks SHAPasswordEncoder - vil kreve at klienten sender inn en saltverdi når den koder passordet.

BCrypt, imidlertid, internt vil generere et tilfeldig salt i stedet. Dette er viktig å forstå fordi det betyr at hver samtale vil ha et annet resultat, og derfor trenger vi bare å kode passordet en gang.

For å få denne tilfeldige saltgenerasjonen til å fungere, lagrer BCrypt saltet i selve hashverdien. For eksempel i følgende hash-verdi:

$ 2a $ 10 $ ZLhnHxdpHETcxmtEStgpI. / Ri1mksgJ9iDP36FmfMdYyVg9g0b2dq

Det er tre felt atskilt med $:

  1. De “2a” representerer BCrypt-algoritmeversjonen
  2. De “10” representerer styrken til algoritmen
  3. De “ZLhnHxdpHETcxmtEStgpI.” del er faktisk det tilfeldig genererte saltet. I utgangspunktet er de første 22 tegnene salt. Den gjenværende delen av det siste feltet er den faktiske hashversjonen av ren tekst

Vær også oppmerksom på at BCrypt algoritmen genererer en streng med lengde 60, så vi må sørge for at passordet blir lagret i en kolonne som har plass til det. En vanlig feil er å lage en kolonne med en annen lengde og deretter få en Ugyldig brukernavn eller passord feil ved godkjenningstidspunktet.

3. Kod passordet ved registrering

Vi vil nå bruke PasswordEncoder i vår UserService å hashe passordet under brukerregistreringsprosessen:

Eksempel 3.1. - Den UserService Haster passordet

@Autowired privat PasswordEncoder passordEncoder; @ Override public User registerNewUserAccount (UserDto accountDto) kaster EmailExistsException {if (emailExist (accountDto.getEmail ())) {throw new EmailExistsException ("Det er en konto med den e-postadressen:" + accountDto.getEmail ()); } Brukerbruker = ny bruker (); user.setFirstName (accountDto.getFirstName ()); user.setLastName (accountDto.getLastName ()); user.setPassword (passwordEncoder.encode (accountDto.getPassword ())); user.setEmail (accountDto.getEmail ()); user.setRole (ny rolle (Integer.valueOf (1), bruker)); returner repository.save (bruker); }

4. Kod passordet ved godkjenning

La oss nå håndtere den andre halvparten av denne prosessen og kode passordet når brukeren autentiserer.

Først må vi injisere passordkoderbønnen vi definerte tidligere i vår autentiseringsleverandør:

@Autowired privat UserDetailsService userDetailsService; @Bean offentlig DaoAuthenticationProvider authProvider () {DaoAuthenticationProvider authProvider = ny DaoAuthenticationProvider (); authProvider.setUserDetailsService (userDetailsService); authProvider.setPasswordEncoder (koder ()); return authProvider; }

Sikkerhetskonfigurasjonen er enkel:

  • vi injiserer implementeringen av brukerinformasjonstjenesten
  • vi definerer en autentiseringsleverandør som refererer til informasjonstjenesten vår
  • vi aktiverer også passordkoderen

Og til slutt må vi referer denne godkjenningsleverandøren i vår XML-konfigurasjon:

Eller hvis du bruker Java-konfigurasjon:

@Configuration @ComponentScan (basePackages = {"com.baeldung.security"}) @EnableWebSecurity offentlig klasse SecSecurityConfig utvider WebSecurityConfigurerAdapter {@Override-beskyttet ugyldig konfigurering (AuthenticationManagerBuilder-godkjenning) kaster Exception {auth.authentication; } ...}

5. Konklusjon

Denne raske opplæringen fortsetter registreringsserien ved å vise hvordan du lagrer passordet riktig i databasen ved å utnytte den enkle, men veldig kraftige BCrypt-implementeringen.

De full gjennomføring av denne registreringsveiledningen for vårsikkerhet kan du finne på GitHub.

Neste » Registrerings-API-et blir RESTful « Forrige vårsikkerhetsregistrering - Send bekreftelses-e-post på nytt

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