[위코드] TIL(Today I am learned) -13

인증/인가

필수요소인 패스워드 암호화 

인가의 필수요소인 JWT

 

인증의 정의

유저의 정체성을 확인하는 절차.

즉, 본인인지 확인하는 절차로 ID와 Password를 확힌하는 절차.

인증을 위해서 id와 password를 생성하는 기능도 필요.

 

인가의 정의

인가란 유저(user)가 요청한 실행을 할 수 있는 권한이 있는지를 확인하는 것.

즉, 유료로 작동하는 기능이 있는데, 이를 사용할 수 있게 해당유저가 유료로 구매했는지 안했는지를 파악하여 이를 권한을 부여하여 해당 request의 실행여부를 판단하게 해주는 것.

 

이러한 인가와 인증의 정의를 한번 보았다.

그렇다면 이제 로그인이 진행되는 과정을 보자.

 

로그인 절차.

 1) 유저id와 password를 생성.

 2) 해당 유저의 id, password를 암호화하여 DB에 저장

 3) 유저 로그인 → ID, Password 입력

 4) 유저가 로그인한 id, password를 기존에 암호화되어 저장된  DB와 일치하는 지 비교.

 5) 일치하면 로그인!

 6) 로그인하면 Access token을 클라이언트에 전송

 7) 유저는 로그인 성공 후 다음부터는 access token을 첨부하여, request를 서버에 전송하므로 매번 로그인이 필요하지 않게 된다.

 

유저 비밀번호 암호화 원칙

유저의 비밀번호를 그대로 저장하지 않는다.

 1) DB가 해킹당하면 유저의 비밀번호도 그대로 노출된다.

 2) 외부 해킹이 아니더라도 내부 개발자나 내부 인력이 유저의 비밀번호를 볼 수 있다.

유저의 비밀번호는 꼭 암호화해서 저장 해야한다.

 1) DB가 해킹당해도 비밀번호가 바로 노출되지 않아 유저나 회사측에서 대응할 수 있다.

 2) 내부 인력도 비밀번호를 알 수 가 없음.

비밀번호 암호에는 단방향 해쉬 함수가 일반적으로 사용.

 1) 단방향 해쉬 함수는 원본 메세지를 알면 암호화 메세지를 해석하기 쉽지만,
     암호화된 메세지에선 원본을 구하기 어렵기에 단방향이라고 칭함.

 

물론, 단방향 해쉬 함수도 취약점이 있다.

 1) 해쉬 함수는 비밀번호를 위해서 만든 것이 아니라 짧은 시간에 데이터를 검색하기 위해서 설계된 것.

    그렇기에 성능이 좋은 컴퓨터로 빠른속도를 통해서 계속 추측하면서 비교하다보면

    원본 패스워드를 추측할 수 있는데, 이를 통해서 패스워드를 해킹할 수 있다.

 

이러한 약점을 해결하기위해서 많은 보안책이 있지만, 대부분 2가지를 사용한다.

 Salting - 실제 비밀번호 이외에 추가적으로 랜덤 데이터를 더해서 해시값을 계산하는 방법.

 Key Stretching - 단방향 해쉬값을 계산후 한번 더 하고, 중복적으로 실행하여
                       복잡하게 만들어 이를 추론하지 못하게 하는 방법.

                       하지만, 위에서 성능이 높은 컴퓨터로 공격할 수 있다고 언급하였는데 이를 방지하기위해서

                       키스트레칭에선 동일한 컴퓨터로 1초에 5번만 비교할 수있게 적용해놔서 해커가 공격해도 이를

                       함부로 운용하지 못하게 막아두었다.

 

 

 위의 해쉬함수로 만든 암호는 전적으로 복호화를 위해서 만든 것이 아니다. 그래서 단방향이라고 한다.

 사용자가 친 비밀번호와 id를 비교대조하여 로그인을 시키는 것이지 복호화가 아님.

 

JWT란? Jason Web Tokens의 약자로

로그인 했을 경우 access Token을 제공하여 리퀘스트를 보내는데, 서버에선 access token을 복호화하여 해당유저를 얻게 된다.

 

 

Authorization(인가) 절차

1. Authentication 절차를 통해 access token을 생성한다. access token에는 유저 정보를 확인할 수 있는 정보가 들어가 있어야 한다 (예를 들어 user id).
2. 유저가 request를 보낼때 access token을 첨부해서 보낸다.
3. 서버에서는 유저가 보낸 access token을 복호화 한다.
4. 복호화된 데이터를 통해 user id를 얻는다.
5. user id를 사용해서 database에서 해당 유저의 권한(permission)을 확인하다.
6. 유저가 충분한 권한을 가지고 있으면 해당 요청을 처리한다.
7. 유저가 권한을 가지고 있지 않으면 Unauthorized Response(401) 혹은 다른 에러 코드를 보낸다.