TIL - 22.02.21

 

개인 공부 후 자료를 남기기 위한 목적이므로 내용 상에 오류가 있을 수 있습니다.

 

2월 21일(월)

 

Authentication(인증)

---

로그인 절차

 

1. user 아이디(id)와 비밀번호(password)를 생성한다. [회원가입]
2. 유저로부터 받은 비밀번호(password)를 암호화해서 DB에 저장한다. [암호화]
3. 유저 로그인 시도(아이디와 비밀번호 입력)한다.
4. 유저가 입력한 비밀번호를 암호화한 후 DB에 저장된 유저 비밀번호와 비교한다.
5. 두 비밀번호가 일치하면 로그인이 성공한다.
6. 로그인 성공 시 access token을 클라이언트에게 전송한다.
7. 유저는 로그인 성공 이후부터 access token을 가지고 HTTP request를 서버에 전송함으로써 매번 로그인 하지 않아도 로그인이 필요한 서비스를 이용할 수 있다.

 

 

유저 비밀번호 암호화

 

1. 유저의 비밀번호는 절대로 유저로부터 받은 비밀번호를 그대로 저장하지 않는다.
2. 그 이유는 DB가 해킹되면 유저의 비밀번호가 그대로 노출되기 때문이며, 외부 해킹이 아니더라도 내부 개발자나 인력이 유저들의 비밀번호를 볼 수 있기 때문이다. (보안 취약성)
3. 따라서 유저의 비밀번호는 반드시 암호화해서 저장해야 한다. (DB가 해킹을 당해도 비밀번호가 그대로 노출되지 않으며 내부 인력도 비밀번호를 쉽게 알 수 없음)
4. 일반적으로 비밀번호 암호화에는 단방향 해쉬 함수(one-way hash function)을 사용한다.
5. 단방향 해쉬 함수는 원본 메세지를 변환하여 암호화된 메세지를 생성한다.
6. 이 때, 원본 메세지를 알면 암호화된 메세지를 구하기는 쉽지만 암호화된 메세지로는 원본 메세지를 구할 수 없기 때문에 단방향이라고 하는 것이다.
7. 예를 들어, "test password"와 "test password2"는 실제 비슷한 비밀번호이지만 해쉬 함수 hash256을 사용하여 암호화를 하면 전혀 다른 해쉬 값이 도출된다. 이러한 효과를 avalance 라고 하며, 비밀번호의 해쉬 값을 해킹하기 어렵게 만드는 요소 중 하나이다. 

 

 

Bcrypt

 

1. 단방향 해쉬 함수도 몇 가지 취약점이 존재한다.
2. 해쉬 함수는 원래 패스워드를 저장하기 위해서 설계된 것이 아니라 짧은 시간 안에 데이터를 검색하기 위해 설계된 것이다. 그렇기 때문에 해쉬 함수는 본래 처리 속도가 매우 빠르게 설계 되었다. 이러한 속성 때문에 공격자는 매우 빠른 속도로 임의의 문자열의 다이제스트와 해킹할 대상의 다이제스트를 비교할 수 있다. 
3. 이처럼 위의 속성을 활용하여 패스워드를 추측하면 패스워드가 충분히 길거나 복잡하지 않은 경우에는 그리 긴 시간이 걸리지 않는다. (대부분 사용자의 패스워드는 길거나 복잡하지 않을 뿐만 아니라, 동일한 패스워드를 사용하는 경우가 많음)
4. 따라서, 단방향 해쉬 함수의 취약점들을 보완하기 위해 일반적으로 두 가지 보완점들이 사용된다.
5. 첫 번째 보완 방법은 Salting이고, 두 번째 보완 방법은 Key Stretching 이다.
6. 우선 Salting은 실제 비밀번호에 추가적으로 랜덤 데이터를 더해서 해쉬 값을 계산하는 방법을 의미한다.
7. Key Stretching은 단방향 해쉬 값을 계산한 후 그 해쉬 값을 다시 해쉬하는 행위를 반복하는 방법을 의미한다.
8. 이처럼 최근에는 위에서 언급한 두 가지 보완방법(Salting & Key Stretching)을 사용하여 해쉬 값을 계산하기 때문에, 일반적인 장비로 1초에 50억개 이상의 다이제스트를 비교하던 상황에서 동일한 장비로 1초에 5번 정도만 비교할 수 있게 되었다.
9. 참고로, Salting과 Key Stretching을 구현한 해쉬 함수 중에서 가장 널리 사용되는 것이 bcrypt이다. (bcrypt는 처음부터 비밀번호를 단방향 암호화 하기 위해 만들어진 해쉬 함수임)

 

 

JWT(JSON Web Tokens)

 

1. 앞서 언급한 것 처럼 유저가 로그인에 성공한 후에는 access token이라고 하는 암호화된 유저 정보를 첨부해서 request를 보내게 된다.
2. 그러면 서버는 HTTP request로 받은 access token을 복호화해서 해당 유저의 정보를 얻게 된다.
3. 그 결과 서버에서는 복호화를 해서 얻은 유저 아이디를 통해 해당 유저가 누구인지 알 수 있다.
4. 이러한 절차의 목적은 해당 유저가 매번 로그인하지 않도록 하는 것이다.
5. access token을 생성하는 방법은 여러가지가 있는데, 그 중 가장 널리 사용되는 기술이 바로 JWT이다.
6. JWT(JSON Web Tokens)는 말 그대로 유저 정보를 담은 JSON 데이터를 암호화하여 클라이언트와 서버가 주고 받는 방식이다.

 

JWT 예시

 

 

Authorization(인가)

---

인가(Authorization)

 

1. Authorization(인가)는 유저가 요청하는 HTTP request를 실행할 수 있는 권한이 있는 유저인지를 확인하는 절차이다. (ex. 해당 유저는 고객 정보를 볼 수 있지만 수정할 수는 없음)
2. Authorization도 JWT를 통해 구현될 수 있다.
3. 즉, access token을 통해 해당 유저 정보를 얻을 수 있기 때문에 해당 유저가 가지고 있는 권한(permission)도 확인할 수 있다.

 

 

인가(Authorization) 절차

 

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