아래 하나씩 답변 드리겠습니다.
회원 정보 db에 비밀번호를 유저마다 다른 salt값과 합쳐 SHA-256 방식 해시값으로 바꿔 저장했습니다.
>> 아주 잘하셨습니다. 이때 salt 값은 절대 유출이 되면 안되고, 혹시나 개발환경에서 유출되었을 경우
다른 salt 로 갈아끼울수있는 준비를 미리 해두시는게 좋습니다.
그런데 검색해서 보다보면 실무에선 salt도 다른 db나 테이블에 암호화해서 저장한다고 되어있고, 이메일 인증도 기초적인 방법으로 구현해 봤는데 이것도 보안 처리가 필요하다고 되어있었습니다.
>> 이메일 인증의 보안처리 라는것이 어떠한것인지 말씀주시면 더 자세히 말씀 드리는데 도움이 될것같습니다.
가장 기초적인 이메일 인증은 인증 코드를 GET URL에 salt를 포함한 암호화 방식으로 전달하여
해당 URL 클릭시 전달받은 GET 파라미터를 이용하여 인증하는것입니다.
이 부분은 당연히 암호화 되어야 합니다.
카카오 연동 로그인도 만들어봤는데 연동 로그인은 OAuth 2.0 방식으로 19자리 숫자를 고유 id로 부여한다고 되어 있습니다. 전 회원db에 그값을 저장해 놓고 유저를 구분하는데 사용하는데 이 고유id도 해시값으로 만들어서 저장해야 될까요?
>> 19자리 숫자를 고유 id 는 굉장히 큰 수이긴하지만. 단순한 int 타입은 여러개 나열되어있어도 보안상 매우 취약한것으로 판단합니다.
아주 간단한 salt 만 사용하여 암호화 하여도 15Ac4Ce79Qz 등이 나오는데요 이 경우
26(알파벳 소문자)+26(알파벳 대문자) + 10(0~9 숫자) 의 재곱수로 UID가 나오며 무작위 대입공격을 막기 굉장히 편해지지만...
단순한 숫자나열의 경우 자리수당 10개밖에 안되기때문에 상대적으로 몹시 취약해집니다.
또한 중간자 공격이나 통신상 취약점 등으로 19자리 고유 아이디를 탈취당하는 경우가 생길수있는데 .
이러한 부분은 특히나 고유 아이디를 외부에서 받아오는 Oauth 방식에서는 매우 취약합니다.
( 한번 AppID로 부여된 고유 아이디를 변경하는것이 불가능에 가깝기 때문입니다. )
따라서 별도의 salt 처리를 하시는게 보안상 좋은건 맞습니다.