TIL#37 인증과 인가 (1)

luneah·2021년 12월 6일
1

Developer

목록 보기
8/16
post-thumbnail

인증 (Authentication)

인증은 회원가입과 로그인을 말한다. 그렇다면 인증은 왜 필요할까? 우리 서비스를 누가 쓰는지, 어떻게 사용하는지 추적이 가능하도록 하기 위해서 필요하다. 인증에 필요한 것은 무엇이 있을까? 아이디, 이메일주소, 비밀번호 등이 있다. 이 중에서 가장 중요한 것은 비밀번호이다.

비밀번호 관리

  • 법규상의 강제 : 정보주체, 즉 이용자가 안전한 비밀번호를 설정하여 이행할 수 있도록 이라고 선언하고 있다.
  • Database에 저장 시 개인 정보를 해싱하여 복원할 수 없도록 함
  • 통신 시 개인 정보를 주고받을 때 SSL을 적용하여 암호화 (HTTPS)

암호화

단방향 해쉬

본래 해쉬(hash) 함수는 자료구조에서 빠른 자료의 검색, 데이터의 위변조 체크를 위해서 복원이 불가능한 단방향 해쉬함수는 암호학적 용도로 사용한다. MD5, SHA-1 (둘은 보안 취약), SHA-256 등이 있다. '1234'를 SHA-256 해싱하면 다음과 같다.

03ac674216f3e15c761ee1a5e255f067953623c8b388b4459e13f978d7c846f4

결과만 봐서는 당장 식별이 불가능하므로 완벽해보인다. 그러나 같은 알고리즘으로 '1234'를 다시 해싱하면 항상 같은 결과가 도출된다.

이와 같은 허점을 이용해서 가능한 경우의 수를 모두 해시값으로 만들어서 판매하는 서비스도 존재한다. Rainbow Table이라고 부르는 것인데 이러한 Rainbow Table을 이용해서 해시값을 유추해주는 사이트도 존재한다.

SALTING & Key Stretching

위와 같은 단방향 해쉬값이 해킹에 쉽게 노출되는 허점을 보완하고자 salting과 Key Stretching이라는 아이디어가 생겨났다. 입력한 비밀번호와 임의로 생성한 문자열(Salt)을 합쳐서 해싱해서 이 해시값을 저장하는 방법이다. 물론 이때 비교를 위해 해시값과 문자열값을 같이 저장해야 한다.

여기에 해커가 패스워드 무작위 대입을 통해 해시값을 계산하는데 필요한 시간을 대폭 늘리기 위해 Salting 및 해싱을 여러번 반복해서 원본값을 유추하기 어렵게 만드는 것이 키 스트레칭(Key Stretching)이다.

bcrypt

Salting & Key Stretching의 대표적 라이브러리로 위의 개념들을 실제로 적용하기 편하게 해준다. 다양한 언어를 지원하고 있으며 사용이 간편하여 쉽게 적용이 가능하다. bcrypt는 hash 결과값에 소금값과 해시값 및 반복횟수를 같이 보관하기 때문에 비밀번호 해싱을 적용하는데 있어 DB 설계를 복잡하게 할 필요가 없다.

  • bcrypt를 통해 해싱된 결과값(Digest)의 구조

인가 (Authorization)

사용자가 서버에 로그인하면 해당 사용자가 맞는지 확인하는 과정을 말한다. 서버는 사용자가 로그인 했을 경우, headers에 메타데이터를 보내 확인할 수 있다. 이 메타데이터를 JSON Web Token 일명 'JWT'라고 한다.

JSON Web Token

  • JWT의 구조
  1. 헤더(header)
    • 토큰의 타입과 해시알고리즘 정보가 들어간다.
    • 헤더의 내용은 BASE64 방식으로 인코딩해서 JWT의 가장 첫 부분에 기록된다.
    • Ex) {"alg": "HS256", "typ"L "JWT"}
  2. 내용(payload)
    • 내용에는 exp와 같이 만료시간을 나타내는 공개 클레임과 클라이언트와 서버 간 협의 하에 사용하는 비공개 클레임을 조합하여 작성한 뒤 BASE64 인코딩하여 두번째 요소로 위치한다.
    • Ex) {"user-id": 1, "exp": 1539517391}
  3. 서명(signature)
    • JWT가 원본 그대로라는 것을 확인할 때 사용하는 부분이다.
    • 시그니처는 BASE64URL 인코드 된 헤더와 내용 그리고 JWT secret(별도 생성)을 헤더에 지정된 암호 알고리즘으로 암호화하여 전송한다. (복호화 가능)
    • 프론트엔드가 JWT를 백엔드 API 서버로 전송하면 서버에서는 전송받은 JWT의 서명부분을 복호화하여 서버에서 생성한 JWT가 맞는지 확인한다.
    • 주의할 점은 헤더와 내용은 BASE64 인코딩 한 것이므로 누구나 원본을 볼 수 있으니 개인정보를 담아서는 안 된다.

HTTP의 특징

  • request/reponse의 구조
  • stateless한 성질(저장하지 않는 성질)

Ex)

  • 요청 1 : Zoom 로그인 → 응답 1 : 로그인 200 OK!
    요청 1의 응답 1에서 200 OK와 Token 발행
  • 요청 2 : meeting 접속 → 응답 2 : meeting 접속 OK!
    요청 2는 발행받은 Token과 함께 요청 보냄
profile
하늘이의 개발 일기

0개의 댓글