[💻 코드스테이츠 FE 44기]해싱, 토큰

✔️ 시작

해싱, 세션의 한계를 보완한 토큰에 대해 학습했다.

---

📍 알게된 점

👾 해싱 (Hashing)

• 가장 많이 쓰이는 암호화 방식 중에 하나
• 복호화가 가능한 다른 암호화 방식들과 달리, 암호화만 가능
• 해시 함수(Hash Function)를 사용해 암호화를 진행

특징

• 항상 같은 길이의 문자열 리턴
• 서로 다른 문자열에 동일한 해시 함수를 사용하면 반드시 다른 결과값이 나온다.
  (서로 다른 문자열 >> 다른 결과 값)
• 동일한 문자열에 동일한 해시 함수를 사용하면 항상 같은 결과값이 나온다.
  (동일한 문자열 >> 같은 결과 값)

비밀번호	해시 함수(SHA1) 리턴 값
‘password’	‘5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8’
‘Password’	‘8BE3C943B1609FFFBFC51AAD666D0A04ADF83C9D’
‘kimcoding’	‘61D17C8312E8BC24D126BE182BC674704F954C5A’

🔗 SHA1 함수 직접 사용해 보기

레인보우 테이블과 솔트(Salt)

• 항상 같은 결과값이 나온다는 특성을 이용해 해시 함수를 거치기 이전의 값을 알아낼 수 있도록 기록해 놓은 표인 레인보우 테이블이 존재한다.
• 레인보우 테이블에 기록된 값의 경우 유출이 되었을 때 해싱을 했더라도 해싱 이전의 값을 알아낼 수 있으므로 보안상 위협 될 수 있다.

이때 활용할 수 있는 것이 솔트(Salt) 이다.

• 솔트는 소금이라는 뜻으로, 말 그대로 소금을 치듯 해싱 이전 값에 임의의 값을 더해 데이터가 유출되더라도 해싱 이전의 값을 알아내기 더욱 어렵게 만드는 방법이다. (다른 임의의 값을 더한다.)

비밀번호	해시 함수(SHA1) 리턴 값
‘password’ + ‘salt’	‘C88E9C67041A74E0357BEFDFF93F87DDE0904214’
‘Password’ + ‘salt’	‘38A8FDE622C0CF723934BA7138A72BEACCFC69D4’
‘kimcoding’ + ‘salt’	‘8607976121653D418DDA5F6379EB0324CA8618E6’

해싱의 목적

복호화가 불가능한 암호화 방식인데 사용하는 이유는 바로
데이터 그 자체를 사용하는 것이 아닌, 동일한 값의 데이터를 사용하고 있는지 여부만 확인하는 것이 목적이다.

• 해싱한 값끼리 비교해서 일치 하는지 확인 확인한다.
• 민감한 데이터를 다루어야 하는 상황에서 데이터 유출의 위험성은 줄이고
• 데이터의 유효성을 검증하기 위해서 사용되는 단방향 암호화 방식

🪙 토큰(Token)

기존 세션 기반 인증이 가지고 있던 한계를 극복하고자 고안 됐다.
(서버 부담을 줄이기 위해)

• 사용자 인증 정보(Authentication)와 권한 정보(Authorization)를 포함한 정보를 담은 암호화된 문자열
• 웹 애플리케이션에서 많이 사용되는 인증 방식 중 하나
• 사용자의 인증 정보를 서버가 아닌 클라이언트 측에서 저장할 수 있다.
• 세션의 인증 방식과 비교했을 때 서버의 부하나 메모리 부족 문제를 줄일 수 있다.

장점

무상태성

• 서버가 유저의 인증 상태를 관리하지 않는다.
• 서버는 비밀 키를 통해 클라이언트에서 보낸 토큰의 유효성만 검증하면 되기 때문에 무상태적인 아키텍처를 구축할 수 있다.

확장성

• 다수의 서버가 공통된 세션 데이터를 가질 필요가 없다(서버를 확장하기 더 용이)

어디서나 토큰 생성 가능

• 토큰 생성/검증이 하나의 서버에서 이루어지지 않아도 되기에 토큰 생성만을 담당하는 서버를 구축할 수 있다.(잘 활용하면 여러 서비스 간의 공통된 인증 서버를 구현할 수 있다.)

권한 부여에 용이

• 인증 상태, 접근 권한 등 다양한 정보를 담을 수 있기에 사용자 권한 부여에 용이(잘 활용해 어드민 권한 부여 및 정보에 접근할 수 있는 범위도 설정할 수 있다.)

JWT (JSON Web Token)

• 토큰 기반 인증 구현 시 대표적으로 사용하는 기술
• JSON 객체에 정보를 담고 이를 토큰으로 암호화해 전송할 수 있는 기술
• 클라이언트가 서버에 요청을 보낼 때 인증 정보를 암호화된 JWT 토큰으로 제공하고,
  서버는 이 토큰을 검증해 인증정보를 확인할 수 있다.

JWT의 구성

• .으로 나눠지 세 부분이 존재한다.
• (ex - aaaa.bbbb.cccc) 각각 Header, Payload, Signature라고 한다.

1. Header

• HTTP의 헤더처럼 해당 토큰 자체를 설명하는 데이터가 담긴다.
• 토큰의 종류, 시그니처를 만들 때 사용할 알고리즘을 JSON 형태로 작성

{
  "alg": "HS256",
  "typ": "JWT"
}

base64 방식으로 인코딩하면 JWT의 첫 번째 부분인 Header가 완성된다.

2. Payload

• TTP의 페이로드와 마찬가지로 전달하려는 내용물을 담고 있는 부분이다.
• 정보에 접근 가능한지에 대한 권한, 유저의 이름과 같은 개인정보, 토큰의 발급 시간 및 만료 시간 등의 정보들을 JSON 형태로 담는다.

{
  "sub": "someInformation",
  "name": "phillip",
  "iat": 151623391
}

JSON 객체를 base64로 인코딩하면 JWT의 두 번째 부분인 Payload가 완성된다.

base64 방식은 원한다면 얼마든지 디코딩할 수 있는 인코딩 방식이다.

• 비밀번호와 같이 노출되어서는 안 되는 민감한 정보를 담지 않도록 해야 한다.
  🔗 직접 사용해 보기

3. Signature

• 토큰의 무결성을 확인할 수 있는 부분이다.
• Header와 Payload가 완성 되었을 경우 Signature는 이를 서버의 비밀 키(암호화에 추가할 salt)와 Header에서 지정한 알고리즘을 사용해 해싱한다.

// HMAC SHA256 알고리즘을 사용한다면 Signature는 아래와 같은 방식으로 생성
HMACSHA256(base64UrlEncode(header) + '.' + base64UrlEncode(payload), secret);

속이기 위해 토큰의 Payload를 변조하는 등의 시도해도 토큰을 발급할 때 사용한 Secret을 정확하게 알고 있지 못한다면 유효한 Signature를 만들어낼 수 없기에 서버는 Signature를 검증하는 단계에서 올바르지 않은 토큰임을 알아낼 수 있다.

토큰 인증 방식의 한계

Signature을 사용해 위조된 토큰을 알아낼 수 있지만, 토큰 자체가 탈취된다면 토큰 인증 방식의 한계가 드러난다.

무상태성

• 인증 상태를 관리하는 주체가 서버가 아니므로, 토큰이 탈취되어도 해당 토큰을 강제로 만료시킬 수 없다.(토큰이 만료될 때까지 사용자로 가장해 계속해서 요청 보낼 수 있다.)

유효 기간

• 토큰이 탈취되는 상황을 대비해 유효 기간을 짧게 설정하면, 사용자는 토큰이 만료될 때마다 다시 로그인을 진행해야 하기 때문에 좋지 않은 사용자 경험을 제공한다.
  (유효 기간을 길게 설정하면 탈취될 경우 더 치명적으로 작용할 수 있다. - 무상태성)

토큰의 크기

• 토큰에 여러 정보를 담을 수 있는 만큼, 많은 데이터를 담으면 그만큼 암호화하는 과정도 길어지고 토큰의 크기도 커지기 때문에 네트워크 비용 문제가 생길 수 있다.

토큰 인증의 한계를 극복하기 위해 다양한 방법들

Access Token

• 서버에 접근하기 위한 토큰으로 앞서 다룬 토큰과 비슷한 역할을 한다. (보안을 위해 보통 24시간 정도의 짧은 유효기간이 설정되어 있다.)

Refresh Token

• 서버 접근을 위한 토큰이 아닌 액세스 토큰이 만료되었을 때 새로운 액세스 토큰을 발급받기 위해 사용되는 토큰(액세스 토큰보다 긴 유효기간을 설정한다.)
• 리프레시 토큰도 모든 문제를 해결해 주지 않기 때문에 세션처럼 서버에 저장하고 이에 대한 상태를 관리하기도 한다.

두 가지의 각기 다른 토큰을 사용하는 경우, 액세스 토큰이 만료되더라도 리프레시 토큰의 유효기간이 남아 있다면 사용자는 다시 로그인을 할 필요 없이 지속해서 인증 상태를 유지할 수 있다.

---

✏️ 마치며

이전에 쿠키, 세션을 학습했고 오늘 토큰에 대해 학습했다.

모두 보안에 대한 문제를 해결하기 위해 보완된 방법이라도
완벽하게 문제를 해결 할 수 없다.

개발가자 구현하려는 서비스에 따라 어떤 인증 방식이 더 적적할지 판단 할 수 있어야겠다.