카테고리 없음

[TIL] 2023.3.8.

_서리__ 2023. 3. 8. 23:44

해싱

해싱은 복호화가가능한 다른 암호화 방식들과는 달리, 암호화만 가능하다.

해싱은 해시 함수를 사용해 암호화를 진행하는데 해시함수는 다음과 같은 특징이 있다.

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

해시함수 예시

레인보우테이블과 솔트

레인보우테이블이란 해시함수를 거치기 이전의 값을 알아낼 수 있도록 기록해놓은 표이다.

유출이 되었을때 해싱을 하더라도 해싱 이전의 값을 알아낼 수 있으므로 보안상 위협이 될 수 있다,

레인보우테이블 예시

이럴때 솔트를 이용할 수 있다. 솔트는 소금을 치듯 해싱 이전 값에 임의의 값을 더해 데이터가 유출되더라도 해싱 이전의 값을 알아내기 어렵게 만드는 방법이다.

 

해싱을 사용하는 이유는 데이터 그 자체를 사용하는 것이 아니라, 동일한 값의 데이터를 사용하고 있는지 여부만 확인 하는것이 목적이기 때문이다. 예를 들어 사이트 관리자는 사용자의 비밀번호를 알고 있을 필요가 없다.

 

토큰

토큰은 유저의 인증상태를 클라이언트에 저장할 수 있어서, 세션 인증방식에 비교해 서버의 부하나 메모리 문제를 줄일 수 있다,

웹 보안에서 토큰은 인증과 권한 정보를 담고있는 암호화된 문자열을 말한다.

1. 사용자가 인증정보를 담아 서버에 로그인 요청을 보낸다.

2. 서버는 데이터베이스에 저장된 사용자의 인증정보를 검증한다.

3. 인증에 성공했다면 해당 사용자의 인증 및 권한 정보를 서버의 비밀키와 함께 토큰으로 암호화 한다.

4. 생성된 토큰을 클라이언트로 전달한다.(Authorizatin헤더를 사용하거나, 쿠키로 전달하거나 등)

5. 클라이언트는 전달 받은 토큰을 저장한다.(Local Storage,Session Storage,Cookie 등)

6. 클라이언트가 서버로 리소스를 요청할 때 토큰을 함께 전달한다.(Authorizatin헤더를 사용하거나, 쿠키로 전달하거나 등)

7.서버는 전달 받은 토큰을 서버의 비밀키를 통해 검증한다. 위조되었는지, 유효기간이 지나지 않았는지...

8. 토큰이 유효하다면 응답데이터를 전송한다.

 

토큰 인증방식의 장점

  • 무상태성: 서버가 유저의 인증상태를 관리하징낳고, 클라이언트에서 보낸 토큰의 유효성만 검증하면 된다. 
  • 확장성: 다수의 서버가 공통된 세션 데이터를 가질 필요가 없다. 서버를 확장하기 좋음.
  • 어디서나 토큰 생성 가능: 토큰의 생성과 검증이 하나의 서버에서 이루어지지 않아도 되기때문에 토큰 생성만을 담당하는 서버를 구축할 수 있다. 여러 서비스간의 공통인증서버 구현 가능.
  • 권한부여에 용이:인증상태, 접근권한등 다양한 정보를 담아 권한 부여에 용이함. 어드민 권한 부여 및 정보에 접근할 수 있는 범위도 설정가능.

JWT

jWT는 다음 그림과 같이 .으로 나누어 존재함.

1.Header

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

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

이 JSON 객체를 base64방식으로 인코딩하면 Header완성!

**base64방식은 얼마든지 디코딩가능하다. 민감한 정보는 담지 말아야함

 

2.Payload

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

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

이 JSON 객체를 base64로 인코딩하면 JWT의 두번째 부분인 Payload 완성!!

 

3.Signature

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

 

만약, HMAC SHA256알고리즘을 사용한다면 Signature는 아래와 같은 방식으로 생성된다.

HMACSHA256(base64UrlEncode(header) + '.' + base64UrlEncode(payload), secret);

따라서 누군가 토큰의 Payload를 변조하는 등의 시도를 하더라도, 토큰을 발급할때 사용한 Secret을 알지 못하면 유효한 Signature를 만들 수 없다. 때문에 서버는 Signature를 검증하는 단계에서 올바르지 않은 토큰임을 알아낼 수 있다.

 

토큰 인증방식의 한계

시그니처를 이용해 위조된 토큰을 알아낼 수는 있지만, 토큰 자체가 탈취된다면 토큰 인증방식의 한계가 드러난다.

  • 무상태성: 인증을 관리하는 주체가 서버가 아니므로, 토큰이 탈취되어도 해당 토큰을 강제로 만료시킬 수 없다. 따라서 토큰이 만료될 때까지 사용자로 가장해 계속 요청을 보낼 수 있다.
  • 유효기간: 유효기간을 짧게 설정하면 매번 로그인해야하고 길게 설정하면 토큰이 탈취될 경우 더 위험하다.
  • 토큰의 크기: 많은 데이터를 담으면 암호화하는 과정도 길어지고 토큰의 크기도 커지기 때문에 네트워크 비용문제가 발생할 수 있다.

엑세스토큰과 리프레시토큰

Access Token 서버에 접근하기 위한 토큰, 24시간 정도의 짧은 유효기간

Refresh Token 엑세스 토큰이 만료되었을때 새로운 액세스 토큰을 발급받기 위해 사용되는 토큰. 액세스 토큰보다 긴 유효기간 설정,