TIL) 인증 / 인가

Solmii·2020년 6월 16일
TILWeCodesession위코드인가인증
0

Data

목록 보기
4/4
post-thumbnail

인증 / 인가는 API에서 가장 자주 구현되는 기능중 하나!!
( Private한 API (가입 회원 등)는 물론이고 Public한 API (비회원) 도 기본적인 인증과 인가를 요구한다. )

인증(Authentication) 이란?

  • 인증(Authentication)은 유저의 identification을 확인하는 절차다.
  • 쉽게 말하면 유저의 신분! 즉, 아이디와 비밀번호를 확인하는 절차!
  • 인증을 하기 위해선 먼저 유저의 아이디와 비밀번호를 생성할 수 있는 기능(회원가입)도 필요하다.
    ⇒ 다시 말해 인증은 회원가입과 로그인 시에 구현되는 기능이다.

:: 로그인 절차

  1. 유저 아이디와 비밀번호 생성
  2. 유저의 비밀번호는 암호화 해서 DB에 저장
  3. 유저가 로그인할 때, 아이디와 비밀번호 입력
  4. 유저가 입력한 비밀번호 암호화 한 후, DB에 저장되었던 암호화된 유저 비밀번호와 비교 ( 즉, 암호화 한 결과값끼리 비교 )
  5. 비밀번호가 일치하면 로그인 성공!
  6. 로그인 성공하면 access token을 클라이언트에게 전송 ( access token 에 대한 설명은 아래에 있음!!!)
  7. 유저는 로그인 성공 후 부터는 access token을 첨부해서 request를 서버에 전송함으로서 매번 로그인 해도 되지 않도록 한다.

:: 유저 비밀번호 암호화

유저의 비밀번호는 절대!!! 비밀번호 그대로 DB에 저장 하지 않는다.

  • DB가 해킹을 당하면 유저의 비밀번호도 그대로 노출 된다.
  • 외부 해킹이 아니더라도 내부 개발자나 인력이 유저들의 비밀번호를 볼 수 있다.

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

  • DB가 해킹을 당해도 비밀번호가 그대로 노출되지 않으며
  • 내부 인력들도 유저의 비밀번호를 알 수가 없다.

비밀번호 암호에는 단방향 해쉬 함수(one-way hash function)가 일반적으로 쓰인다.

  • 단방향 해시 함수는 원본 메시지를 변환하여 암호화된 메시지인 다이제스트(digest)를 생성한다.
    원본 메시지로 → 암호화된 메시지를 구하기는 쉽지만,
    암호화된 메시지로 → 원본 메시지를 구할 수는 없어서 단방향성(one-way) 이라고 한다.

    예를 들어, "test password"를 hash256이라는 해쉬 함수를 사용하면 0b47c69b1033498d5f33f5f7d97bb6a3126134751629f4d0185c115db44c094e 값이 나온다.

    여기서 "test password2"를 hash256 해쉬 함수를 사용하면 d34b32af5c7bc7f54153e2fdddf251550e7011e846b465e64207e8ccda4c1aeb 값이 나온다.

    이처럼, 실제 비밀번호 문자는 비슷하지만 해쉬 함수로 나온 값은 완전히 다르다!
    이렇게 비밀번호 해쉬 값을 해킹하기 어렵게 만드는 효과를 avalance라고 한다.

:: Bcrypt

bcrypt란 비밀번호를 단방향으로 암호화 하기 위해 만들어진 라이브러리로, 아래에서 설명하는 Salting과 Key Stretching 를 같이 구현한 라이브러리임!

단방향 해시 함수의 취약점

  • Rainbow table attack
    미리 해쉬값들을 계산해 놓은 테이블을 Rainbow table이라고 한다.
    ⇒ 여러가지 경우의 수를 해시값으로 만들어놓고 판매하는 서비스도 있다...넘나 허술

  • 해시 함수는 원래 패스워드를 저장하기 위해서 설계된 것이 아니라 짧은 시간동안 많은 데이터를 검색하기 위해 빠른 처리 속도를 가지도록 설계된 것이지만, 복원이 불가능한 특징이 있어서 암호학적 용도로 사용한다.

    이러한 속성 때문에 공격자는 매우 빠른 속도로 임의의 문자열의 다이제스트와 해킹할 대상의 다이제스트를 비교할 수 있다.
    (MD5를 사용한 경우 일반적인 장비를 이용하여 1초당 56억 개의 다이제스트를 대입할 수 있다고 한다ㄷㄷ)

    이런 방식으로 패스워드를 추측하면 패스워드가 충분히 길거나 복잡하지 않은 경우에는 그리 긴 시간이 걸리지 않는다.
    (대부분 사용자의 패스워드는 길거나 복잡하지 않을 뿐 아니라, 동일한 패스워드를 사용하는 경우도 많다.)

에 대한 2가지 보완점

Salting

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

Key Stretching

  • 단방향 해시값을 계산 한 후, 그 해시값을 또 해시 하고, 이를 계속 반복하는 방법
  • 최근에는 일반적인 장비로 1초에 50억 개 이상의 다이제스트를 비교할 수 있지만, 키 스트레칭을 적용하면, 동일한 장비에서 1초에 5번 정도만 비교할 수 있게 한다. GPU(Graphics Processing Unit)를 사용하더라도 수백에서 수천 번 정도만 비교할 수 있다.
    50억 번과는 비교할 수도 없을 정도로 적은 횟수다.
    앞으로 컴퓨터 성능이 더 향상되면 몇 번의 반복을 추가하여 보완할 수 있다.

💁🏻‍♀️ 비밀번호는 복호화되면 안되므로, 단방향 암호화를 사용한다.
하지만, 다시 복호화해서 확인해야 하는 정보(이름, 주민번호 등)은 양방향 암호화를 사용한다.

( 소금 치고 늘린다!! ㅋㅋㅋㅋㅋ )

:: JWT(JSON Web Tokens)

앞서 언급했듯이 유저가 로그인에 성공한 후에는 access token이라고 하는 암호화된 유저 정보를 첨부해서 request를 보내게 된다.

유저 로그인

POST /auth HTTP/1.1
Host: localhost:5000
Content-Type: application/json

{
    "username": "joe",
    "password": "pass"
}

access token

HTTP/1.1 200 OK
Content-Type: application/json

{
    "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZGVudGl0eSI6MSwiaWF0IjoxNDQ0OTE3NjQwLCJuYmYiOjE0NDQ5MTc2NDAsImV4cCI6MTQ0NDkxNzk0MH0.KPmI6WSjRjlpzecPvs3q_T3cJQvAgJvaQAPtk1abC_E"
}

그러면 서버에서는 access token을 복호화 해서 해당 유저 정보를 얻게 된다.

🤷🏻‍♀️ 왜 access token 이라는걸 굳이 발급할까?

HTTP 세션때 했듯이, HTTP는 stateless 성질을 갖기 때문에, 이미 요청-응답이 진행됐어도 다음 요청 때 예전의 정보가 저장되지 않는다.
만약 access token 발급하지 않는다면, 그래서 사용자는 사이트내에서 페이지를 이동할 때 마다 로그인을 해야 했을 것이다.

ex : access token eyJ.... 을 복호화 하면 다음과 같은 정보를 얻는다.

{
    user_id = 1 
}

⇒ 복호화해서 얻은 유저 아이디를 통해 해당 유저가 누군지 알 수 있다.

  • 이런 절차의 목적은 해당 유저가 매번 로그인 해도 되지 않도록 하는 것이다.
  • access token을 생성하는 방법은 여러가지가 있는데, 그 중 가장 널리 사용되는 방법 중 하가 바로 JWT(JSON Web Tokens)이다.
  • JWT는 말 그대로 유저 정보를 담은 JSON 데이터를 암호화 해서 클라이언트와 서버간에 주고 받는 것이다.

    참고로 이 JWT의 실제 모습은.....

    ⇒ 요로코롬 생겼다!!

전체적인 진행 순서는 이런 느낌!!!!

인가(Authorization) 란?

  • 인가(Authorization)란 유저가 요청하는 request를 실행할 수 있는 권한이 있는 user 인지를 확인하는 절차
    ( 예를 들어, 해당 유저의 권한을 확인한 후 고객 정보를 볼 수 있는 있지만 수정 할 수는 없다는 권한을 부여하는 등)

  • 인가(Authroization)도 JWT를 통해서 구현 될 수 있다.

    ⇒ access token을 통해 해당 유저 정보를 얻을 수 있음으로 해당 유저가 가지고 있는 권한(permission)도 확인 할 수 있다.

:: 인가 절차

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

TIL) Database 뿌셔뿌셔

0개의 댓글