인증(Authentication) & 인가(Authorization)

JiYeon Park·2021년 2월 13일
0

Web

목록 보기
1/2
post-thumbnail

인증과 인가

  • 인증은 시스템에 접근 시, 등록된 사용자인지 여부를 확인하는 것(대표적으로 로그인 기능)
  • 인가은 접근 후, 인증된 사용자에게 권한을 부여하는 것으로 사용자 등급(일반/관리자)로 권한을 부여 할 수 있다.

인증(Authentication)

인증은 유저의 정보를 확인하는 절차로 유저의 아이디와 비번을 확인하는 절차입니다.
인증을 하기 위해서 유저의 아이디와 비번을 생성할 수 있는 기능이 필요합니다.

비밀번호를 관리하기 위해서는 법규상에 주요 개인정보가 암호화하도록 법적으로 요구하고 있습니다.
Database에 저장 시, 개인 정보를 해싱하여 서버 관리자 또한 개인정보를 암호화하여 복원할 수 없도록 암호화가 필요합니다.

암호화 방법

암호화가 필요한 이유

  • 유저의 비밀번호가 그대로 DB에 저장 시, DB가 해킹 당하면 개인정보가 그대로 노출됩니다.
  • 외부 해킹이 아니더라도 내부 개발자나 관리자들이 유저의 비밀번호가 확인 가능합니다.

단방향 해쉬?

  • 비밀번호 암호에는 단방향 해쉬 함수(one-way hash function)가 일반적으로 쓰입니다.
  • 본래 해쉬(hash)함수는 자료구조에서 빠른 자료의 검색, 데이터의 위변조 체크를 위해서 쓰이지만, 복원이 불가능한 단방향 해쉬함수는 암호학적 용도로 사용합니다.
  • (MD5, SHA-1) -> 둘은 보안취약, 최근에는 SHA-256이라고 합니다.
    결과만 봐서는 당장 식별이 불가능하므로 완벽해 보이지만 언제나 같은 값으로 결과값이 나오기 때문에 해킹에 취약합니다.
  • 이와 같은 허점을 이용해서 가능한 경우의 수를 모두 해시값으로 만들어서 판매하는 서비스도 존재합니다.

    이 같은 허점을 보완하고자 SALTINGKeyStretching이라는 아이디어가 생겼습니다. 비밀번호와 임의로 생성한 문자열(salt) 를 합쳐서 해싱하여 이 해시값을 저장하는 방법입니다.

SALTING & KeyStretching

  • 말 뜻대로 내 비밀번호 사이에 랜덤한 문자를 집어 넣은 후 해쉬 함수로 집어 넣습니다.
  • 단순해쉬값이 해킹에 쉽게 노출되기 때문에 salting 이라는 아이디어가 생겨났습니다.
  • 물론 이때 비교를 위해 해시값과 소금값을 같이 저장해야 합니다.
  • 여기에 해커가 패스워드 무작위 대입을 통해 해시값을 계산하는데 필요한 시간을 대폭 늘리기 위해 Salting해싱을 여러번 반복해서 원본 값을 유추하기 어렵게 만드는 것이 키 스트랫칭(Key Stretching)입니다.

bcrypt

Salting & Key Stretching 대표적 라이브러리

  • 다양한 언어를 지원하고 있으며, 사용이 간편하여 쉽게 적용이 가능합니다.
  • bcrypt는 hash 결과값에 소금값과 해시값 및 반복 횟수를 같이 보관하기 때문에 비밀번호 해싱을 적용하는데 있어 DB설계를 복잡하게 할 필요가 없는 장점이 있습니다.

인가(Authorization)

:유저가 요청사는 request를 실행할 수 있는 권한이 있는 유저인가를 확인하는 절차.

  • 'JWT(JSON Web Token)'를 쓰면 인가가 수월함. 서버가 유저 정보를 갖고 있으므로 데이터에서 유저의 권한 정보도 읽어들이면 됨.
    -유저가 로그인에 성공한 후에는 access token이라고 하는 암호화된 유저 정보를 첨부해서 request 첨부하여 보냅니다.

인가(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) 혹은 다른 에러 코드를 보낸다.
profile
열심히 공부중인 초보 개발자

0개의 댓글