인증(Authentication)

회원가입과 로그인을 말한다.

• 서비스를 사용하는 사용자가 누구인지, 어떻게 사용하고 있는지를 추적하기 위해서 인증이 필요하다.
• 아이디, 이메일, 비밀번호 등 인증하기 위해 필요한 요소

비밀번호 관리

• 법규상의 강제

  개인정보 보호법에서 개인정보의 암호화에 대해서 규정하고 있다.
  시스템이 인터넷에서 격리된 네트워크에 위치하는 경우나 예외적인 개인정보 항목을 다루는 경우를 제외하고는 국가에서 권고하는 상용 암호화 알고리즘을 이용해 개인정보를 암호화하도록 법적으로 요구하고 있다.

• 암호화 : 개인정보취급자의 실수 또는 해커의 공격 등으로 인해 개인정보가 비인가자에게 유・노출 되더라도 그 내용 확인을 어렵게 하는 보안기술

• 비밀번호 관리하는 방법

  • Database에 저장 시 개인 정보를 해싱하여 복원할 수 없도록 함.
  • 통신 시 개인정보를 주고받을 때 SSL을 적용하여 암호화(HTTPS)

암호화하는 방법

단방향 해시

• 본래 해시(hash)함수는 자료구조에서 빠른 자료의 검색, 데이터의 위변조 체크를 위해서 쓰이지만, 복원이 불가능한 단방향 해시함수는 암호학적 용도로 사용한다.

• MD5, SHA-(둘은 보안취약), SHA-256 등이 있다.

• '1234'를 SHA-256 해싱

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

• 이와 같은 허점을 이용해서 가능한 경우의 수를 모두 해시 값으로 만들어서 판매하는 사이트 존재(= Rainbow Table)

• Rainbow Table을 이용해서 해시값을 유추해주는 사이트도 존재

• 이같은 허점을 보완하고자 비밀번호와 임의로 생성한 문자열(Salt)를 합쳐서 해싱하여 이 해시값을 저장하는 방법인 salting과 Key Stretching이라는 아이디어가 생겨났다.

Salting & Key Stretching

• 단순 해시 값이 해킹에 쉽게 노출되기 때문에 Salting이라는 아이디어가 생겨났다.

• 입력한 비밀번호와 임의로 생성한 문자열(Salt)를 합쳐서 해싱한 후 이 해시 값을 저장하는 방법

• 입력받은 비밀번호와 해싱된 비밀번호를 비교하기 위해 해시 값과 소금(Salt) 값을 같이 저장해야 한다.

bcrypt

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

• bcrypt는 앞서 말한 개념들을 실제로 적용하기 편하게 해주는 대표적인 라이브러리이다.

• 다양한 언어를 지원하고 있으며, 사용이 간편하여 쉽게 적용이 가능하다.

• bcrypt는 hash 결과 값에 소금 값과 해시 값 및 반복 횟수를 같이 보관하기 때문에 비밀번호 해싱을 적용하는데 있어 DB설계를 복잡하게 할 필요가 없다.

• bcrypt를 통해 해싱된 결과 값(Digest)의 구조는 아래와 같다.
  

인가(Authorization)

사용자가 서버에 로그인 하면 해당 사용자가 맞는지 확인하는 과정을 말하며 인증이 완료된 사용자에게 허락된 권한을 부여해주는 것

• 인가와 관련된 HTTP의 주요한 특징

  • request/response 요청과 응답
  • stateless한 성질(저장하지 않는 성질)

• 서버는 사용자가 로그인했을 경우 headers에 메타데이터(JWT)를 보내서 확인한다.

JWT(JSON Web Token)

• JWT 구조
  

헤더(header)

• 토큰의 타입과 해시알고리즘 정보가 들어있다.
• 헤더의 내용은 BASE64 방식으로 인코딩해서 JWT의 가장 첫 부분에 기록
  -예시   {"alg": "HS256", "typ": "JWT"}

내용(payload)

• 내용에는 exp와 같이 만료시간을 나타내는 공개 클레임과 클라이언트와 서버간 협의하에 사용하는 비공개 클레임의 두가지 요소를 조합하여 작성한 뒤 BASE64 인코딩하여 두번째 요소로 위치한다.
• 예시   {"user-id": 1, "exp": 1539517391}
• 정보들을 주고 받을 때 내용이 들어가야하며, 헤더에 들어가는 내용이기 때문에 중요한 개인정보나 데이터 등을 넣으면 안된다. 예를들어 user-id가 아닌 실제 아이디명을 넣거나 이메일 등을 넣어서 암호화하는 경우 보안상의 문제가 생길 수 있다.

서명(signature)

• JWT가 원본 그대로라는 것을 확인할 때 사용하는 부분
• 시그니쳐는 BASE64URL 인코드된 header와 payload 그리고 JWT secret(별도 생성)을 헤더에 지정된 암호 알고리즘으로 암호화하여 전송한다.(복호화가능)
• 프론트엔드가 JWT를 백엔드 API 서버로 전송하면 서버에서는 전송받은 JWT의 서명 부분을 복호화하여 서버에서 생성한 JWT가 맞는지 확인한다.
• 마치 계약서의 위변조를 막기 위해 서로 사인하는것과 같다고 보면 된다.
• 주의할 점은 header와 payload는 BASE64 인코딩한 것이므로(암호화아님) 누구나 원본을 볼 수 있으니 개인정보를 담아서는 안됨.