개발자 입장에서 보는 인증 & 인가

인증 Authentication

• 인증은 왜 필요할까?
  • 우리 서비스를 누가 쓰며 어떻게 사용하고 있는지 추적이 가능하도록 하기 위해
    (ex. 회원가입한 사람들이 좋아요를 누른다거나 게시글을 쓰는 등의 행위를 DB에 저장하여 추적하기 위함)
• 인증에 필요한 것은 무엇이 있을까?
  • ID, Email, Password
  • 가장 중요한 것은 비밀번호

 

비밀번호 어떻게 관리해야 하는가?

법규상의 강제

Database에 저장 시 개인 정보를 해싱하여 복원할 수 없도록 함

통신 시 개인정보를 주고 받을 때 SSL을 적용하여 암호화 (HTTPS)

 

 

암호화는 어떻게 할까?

단방향 해쉬란?

• 본래 해쉬(hash) 함수는 자료구조에서 빠른 자료의 검색, 데이터의 위변조 체크를 위해서 쓰이지만, 복원이 불가능한 단방향 해쉬함수는 암호학적 용도로 사용한다.
• MD5, SHA-1(이 둘은 보안 취약), SHA-256 등이 있다.
• 1234를 SHA-256 해싱하면 다음과 같다.
  03ac674216f3e15c761ee1a5e255f067953623c8b388b4459e13f978d7c846f4
• 하지만 같은 알고리즘으로 '1234'를 다시 해싱하면 항상 같은 결과가 도출되므로 데이터가 쌓이면 유추가 가능해진다.
• 이와 같은 허점을 이용해서 가능한 경우의 수를 모두 해시값으로 만들어서 판매하는 서비스도 존재한다.
  http://project-rainbowcrack.com/table.html 
• Rainbow Table이라고 부르는데, 이러한 테이블을 이용해서 해시값을 유추해주는 사이트도 존재한다. https://crackstation.net/ 
• 이 같은 허점을 보완하고자 salting과 Key stretching이라는 아이디어가 생겨났다. 비밀번호를 생성한 문자열(salt)를 합쳐서 해싱하여 이 해시값을 저장하는 방법이다.

 

SALTING & KeyStretching?

• 단순해쉬값이 해킹에 쉽게 노출되기 때문에 Salting이라는 아이디어가 생겨났다.
• 입력한 비밀번호와 임의로 생성한 문자열(Salt)를 합쳐서 해싱해서 이 해시값을 저장하는 방법
• 이 때에 비교를 위해 해시값과 소금(Salt)값을 같이 저장해야 한다.
• 여기에 해커가 패스워드 무작위 대입을 통해 해시값을 계산하는데 필요한 시간을 대폭 늘리기 위해 Salting 및 해싱을 여러번 반복해서 원본 값을 유추하기 어렵게 만드는 것이 키 스트랫칭(Key Stretching)이다.

출처 : https://forum.huawei.com/enterprise/en/what-is-salting-cyber-security-awareness/thread/492569-867

비밀번호를 오랫동안 바꾸지 않으면 비밀번호를 바꾸라고 뜨는데(ex. 비밀번호를 6개월 동안 변경하지 않으셨습니다. 비밀번호를 바꾸시겠습니까? ➡ ✅예(비밀번호 변경) ❎ 다음에 변경) 암호화를 아무리 철저히 해도 100% 안전을 보장할 수 없기 때문에 주기적으로 바꿔주어야 한다.

 

bcrypt

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

• bcrypt(비크립트)는 앞서 말한 개념들을 실제로 적용하기 편하게 해주는 대표적인 라이브러리
• 다양한 언어를 지원하고 있으며, 사용이 간편하여 쉽게 적용이 가능하다
• bcrypt는 해쉬 결과값에 소금값과 해시값 및 반복횟수를 보관하기 때문에 비밀번호 해싱을 적용하는데 있어 DB설계를 복잡하게 할 필요가 없다.

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

 

 

인가 Authorization

인가는 무엇일까?

• 해당 유저가 request에 해당하는 권한이 있는지 확인하는 절차
• HTTP의 특징은 무엇일까?
  • 바로 request/response 요청과 응답
  • stateless한 성질(저장하지 않는 성질)
• 서버는 사용자가 로그인했을 경우, 로그인했다는 것을 어떻게 알 수 있을까?
  • 바로 headers에 메타데이터를 보내서 확인한다.
• 이 메타정보를 바로 JSON Web Toke 일명 'JWT'라고 한다. => 암호화하는 작업은 굉장히 무겁고, 서버에 무리가 간다. 

 

 JSON Web Token

JWT의 구조

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

 

헤더와 내용에는 개인정보가 들어가지 않기 때문에 암호화할 필요가 없다

 

 

 

BE 면접에선 "bcrypt 왜 썼어요?" 혹은 "JWT 왜 썼어요?" 라고 물어볼 수 있는데 그 때 버벅거리지 않으려면 알고 있어야 한다.