BCrypt

[registration with Srping Security- password Encoding](Registration with Spring Security – Password Encoding)

• 현재 MD5PasswordEncoder 와 ShaPasswordEncode 는 현재 deprecated되었다

Password encode를 define

• Spring에서 특정한 encoder를 사용하기 위해서는 Bean으로 등록하는 것이 필요하다.

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

• 예전에 SHAPasswordEncoder의 경우에는, password를 인코딩 할 때 마다 client측에서 salt를 넘겨줘야 했다.
• 하지만 BCrypt의 경우에는, 내부적으로 [ random salt] 를 생성한다.
  • 즉! 호출 할 때 마다 [ 서로 다른 결과 ]를 얻을 수 있다는 것이다.
  • 이런 [ random sal 생성 ] 이 작동하게 하기 위해, BCrypt는 자신의 hash value 내부에 salt를 저장할 것이다.
    다음 hash value의 경우

    $2a$10$ZLhnHxdpHETcxmtEStgpI./Ri1mksgJ9iDP36FmfMdYyVg9g0b2dq

  • 세 개의 fields들이 $에 의해 분리되어있다.
  1. wa는 BCrypt 알고리즘의 버전을 명시
  2. 10은 알고리즘의 길이를 명시
  3. 그 뒤의 파트는 , 실제로 랜덤으로 생성된 salt를 의미한다. 기본적으로 22개의 characters이 salt이다. 이 파트의 나머지 부분은 [plain text의 실제 hashed 된 version ] 이다.
• 또한 BCrypt 알고리즘은 길이 59 or 60의 String을 생성한다!!
• varchar이나 char의 경우 binary safe하지 않으며, 그 equality도 [ 오로지 byte 값 ] 에만 의한게 아니라 [ 실제 collation ] 에도 영향을 받는다.
• 따라서 항상, 이렇게 인코딩된 결과가 저장된 column이 이것을 수용할 수 있도록 만들어야만 한다. 자주 하는 실수가 column의 길이를.. 다르게 만드는 것임.

password에 varchar사용?

• passwords를 저장 할 때에는, hashing을 거친 후 그 해쉬값을 저장하게 된다.
• 많은 해슁 알고리즘은 일정한 길이의 것으로 해쉬를 한다. 따라서 char를 사용할 때 일정 길이를 잘 할당만 시켜준다면, 여기서 issue가 되지는 않을 수도 있긴 하다.
• db의 field의 size는 정확하게 output의 size와 매치해야 한다.

How to securely hash passwords?

How to securely hash passwords?

• 어떤 것을 dB에 저장하기 전에