이글은 ehdrms2034.github.io 에서 옮겨진 글입니다.
원 글은 20/01/18일에 작성됐습니다.
[서버개발캠프 4기] 2번째 과제 Auth Server 제작하기
서버개발캠프 2주차 과제는 Auth Server를 제작하는 것이다.
조건은 다음과 같다.
- RDBMS를 사용할 것 (ex : Mysql, Postgresql)
- 이메일 인증을 넣을 것
- 캐시 서버를 사용할 것 (Redis)
- 관리자 페이지를 제작할 것
- 비밀번호 찾기가 들어갈 것
- Password Encryption 할 것
- 로그인 및 회원가입 기능 들어갈 것
프로젝트 규모가 꽤 커서, 중요한 부분만 설명하고 가겠다!
나머지는 Github 홈페이지에 올라와있으니 확인하도록!
아래는 링크 주소 :
GitHub - ehdrms2034/AuthServer-with-Node-Mysql-Redis-JWT
프로젝트 설계 하기 - 비밀번호 암호화
Auth Server를 만드는데 있어 가장 중요한 것은 바로 비밀번호를 어떻게 잘 관리하느냐 일 것이다. 그 이유는 서버가 해커의 공격으로 뚫린다 하더라도 2차, 3차적인 피해를 예방할 수 있냐를 결정 지을 것이 바로 비밀번호의 암호화이기 때문이다.
PBKDF2 (With Sha-256) 알고리즘 기법을 사용
그래서 나는 사용자의 비밀번호를 관리하기 위해 pbkdf2 암호화를 적용하였다
pbkdf를 간략하게 설명하자면 평문을 Sha-1,Sha-256등 여러 암호화 기법들을 1번만 암호화 하는것이 아니라 임의의 횟수대로 반복하여 해쉬 값을 생성하는 것이다.
그러나 Hash 값을 그대로 비밀번호에 저장하기에는 문제점이 발생한다.
변환된 해쉬는 본래의 평문과 1:1 대응 한다.
이말이 무슨 말이냐면, asdf 를 해쉬 알고리즘을 이용해서 h1h2h3라는 해쉬 값을 얻었다고 한다면 이 asdf는 h1h2h3 이외에는 다른 해쉬값을 얻을 수 없다는 것이다.
그렇다면 존재하는 모든 값들을 해쉬값으로 저장해둔 테이블이 있다면? 해쉬값으로 변환해둔 값들을 저장해둔 테이블을 바로 레인보우 테이블 이라고 하고, 이것이 바로 Hash를 이용한 단방향 암호화의 보안 취약성이다.
그렇다면 이 취약성을 해결할 방법은 없을까?
Salting 기법을 사용하여 비밀번호를 암호화
Salting 기법은 말그대로 소금을 친다는 것이다. Hash Function으로 추출된 값은 원래의 평문과 1:1 대응 관계였다고 했나?
그렇다면 기존의 평문에 Salt값이라고 불려지는 값들과 같이 암호화를 한다면, 같은 암호값이라도 매번 암호화 되는 값이 다르기 때문에 레인보우 테이블 공격을 쉽게 막을 수 있다.
로그인 유지는 어떻게 했을까? - JWT 토큰 인증 방식 사용
대부분의 서비스는 사용자가 로그인을 하여 권한을 획득한 후, 서버가 제공하는 서비스를 이용할 것이다.
즉 권한을 획득하지 못하면 서버가 제공하는 기능을 사용하지 못한다는 말과 같다.
그렇다면 2주차 과제에서는 어떻게 사용자의 권한을 유지하게끔 설정했을까?
유저 인증 관리 방법은 계속적으로 발전해왔다. 초기에는 쿠키 그다음 세션 그리고 현재, JWT 토큰 기반 인증 방식이 대세를 이루고 있다.
왜 JWT 토큰 인증 방식을 사용했느냐?
쿠키는 보안상 문제가 된다
쿠키 인증방식은 권한 자체를 클라이언트(브라우저)단에 저장을 해놓기 때문에, 유저가 쿠키를 마음대로 수정이 가능하다. 쿠키에 유저 권한을 넣어놓고, 사용자가 임의로 그 권한을 관리자로 변경해버리면 그대로 서버를 이를 악용하는 사용자에게 탈취당하는 셈이된다.
세션은 서버에 많은 부하를 가지고 온다
세션은 사용자의 권한을 서버에 저장해놓기 때문에, 서버자체를 탈취당하지 않는 이상 보안상 안정적이다. 그러나 세션은 서버에 그 값을 저장해놓고 사용자가 클라이언트를 종료할 때 까지 지속적으로 유지 및 확인을 해야 된다. 이는 사용자 수가 적을때는 문제를 일으키진 않지만, 사용자 수가 많을때는 사용자 수 만큼 지속적으로 세션을 유지 해야 되는데, 이는 서버에 많은 부담을 가지고 온다
그래서 JWT 토큰을 사용한다
JWT 토큰에 대한 설명은 추후 따로 블로깅을 통해서 올리도록 하겠다. JWT토큰에 대한 설명은 아래링크를 참고하시길..!
JWT JSON Web Token 소개 및 구조 | VELOPERT.LOG
JWT 토큰은 payload에 원하는 정보를 가지고 signature(서명)부분을 통해서 이 JWT가 -진또배기- 진짜인지 가짜인지 구별할 수 있다.
즉 이 JWT 토큰을 사용자 인증이 필요한 부분에 미들웨어 또는 직접 넣어주게 된다면, 세션을 항상 연결하지 않고서 사용자에 대한 인증부분을 해결할 수 있게 된다.
다음은 프로젝트의 전체적인 구조와 왜 Redis를 사용했는가에 대해 간략하게 적어보도록 하겠다!
