2022-10-13(목) 회의록

1. 엔티티에 Setter 제거

• 이유
  • 엔티티같은 경우는 JPA 영속성 컨텍스트에 의해서 관리될 수 있는 객체이므로 어디선가 setter로 데이터 조작이 된다면 DB에 쉽게 영향을 줄 수 있다.
• 문제들과 그에 대한 해결
  • 컨틀롤러 메소드의 매개변수로 해당 엔티티 자체를 줄 수 없음
    • @ModelAttribute를 통하여 특정 클래스가 매개변수로 들어오면 필드명과 파라미터가 일치함에 따라 setXXX()로 바인딩이 되지만, 세터를 제거하면 바인딩이 되지 않는다.
    • 폼태그 등에서 파라미터로 값을 받는 컨트롤러 메소드에서는 매개변수를 DTO같은 값을 받아야함.
    • 검증처리도 생성할 때, 수정할 떄, ... 각각 다르게 해야하기 때문에 매개변수로는 DTO로 받는게 좀 더 좋은 방법
  • setter가 없기 때문에 엔티티를 생성할 때는 정적 생성 메소드, 빌드패턴, ... 과 같은 생성 방법에 대해서 생각해봐야함
    • 수정할 때 또한 어떠한 메소드를 통해서 객체의 필드 값을 변경하는 로직이 필요함

2. 비밀번호 암호화

• 이유
  • 비밀번호를 DB에 평문으로 저장하며 DB가 유출되면 고객들의 비밀번호가 쉽게 빠져나감
• 해결 방법
  • 평문을 해싱을 통하여 암호화처리 함 (단방향)
  • 스트래칭 : 해싱을 N번 처리하여 쉽게 유추하지 못하게 하기 위한 방법
  • 솔팅 : 비밀번호는 사람들이 익히 쓰는 문장들일 가능성이 크므로 해싱을 여러번 처리한 값도 레인보우테이블에 있을 수 있다. 따라서 랜덤으로 발생된 값을 비밀번호 뒤에 붙인 뒤 해싱
  • 스트레칭과 솔팅을 합쳐서 해싱을 N번 할때마다 그 뒤에 SALT를 붙여서 해싱함
  • DB에는 다이제스트(암호화된 메세지)와 솔트가 있어서 매번 로그인 시도할 때마다 회원가입시 암호화 처리 했던 것과 똑같은 로직을 진행하고 암호화된 비밀번호와 일치하는지 비교