🌊 Hashing
Hashing은 암호화 방식 중 하나로, 복호화가 가능한 다른 암호화 방식과 달리 해싱은 암호화만 가능하다.
해싱은 해시 함수(Hash Function)를 사용하여 암호화를 진행한다.
해쉬 함수의 특징
- 항상 같은 길이의 문자열을 리턴한다.
- 서로 다른 문자열을 동일한 해시 함수를 사용하면 반드시 다른 결과값을 반환한다.
- 동일한 문자열에 동일한 해시 함수를 사용하면 항상 같은 결과값이 나온다.
해쉬 함수 SHA1 생성기
https://www.convertstring.com/ko/Hash/SHA1
해싱의 목적
해싱은 복호화 불가능한 암호지만 비밀번호 또한 해싱하여 저장하므로 해싱값이 서로 확인하여 일치하는 지만 확인하면 되기 때문이다.
이처럼 데이터 유출의 위험성은 줄이면서 데이터의 유효성을 검증하기 위해 사용되는 단방향 암호화 방식이다.
레인보우 테이블과 솔트
레인보우 테이블
해쉬 함수(MD5, SHA1, SHA2)를 사용하여 만들어낼 수 있는 값들을 대량으로 저장한 값이다. 해쉬함수를 이용하여 저장된 비밀번호로 원래의 비밀번호를 추출하는데 사용한다. 항상 같은 결과값이 나온다는 특성을 이용하기 때문에 유출될 경우 해싱을 했더라도 해싱 이전의 값을 알아낼 수 있어 보안에 위협이 된다.
솔트
이 때 해싱 이전 값에 임의의 값(솔트)를 더해 데이터가 유출되더라도 해싱 이전의 값을 알아내기 어렵게 만들 수 있다. 솔트를 사용하면 솔트가 함께 유출된 것이 아니라면 암호화 이전의 값을 알아내는 것은 불가능에 가깝다.
🌊 Token
토큰 인증 방식은 최근에 많이 사용되는 인증 방식 중 하나로, 토큰을 클라이언트에 저장할 수 있다.
토큰은 유저의 인증 상태를 클라이언트에 저장할 수 있다.
토큰 인증의 장점
- 무상태성
- 확장성
- 어디서나 토큰 생성 가능
- 권한 부여에 용이
Token 흐름
- 사용자가 인증정보를 담아 서버에 로그인 요청
post /login - 서버는 DB에 저장된 사용자 인증 정보를 확인
- 인증에 성공했다면 사용자의 인증 및 권한 정보를 서버의 비밀 키와 함께 토큰으로 반환
- 생성된 토큰을 클라이언트로 전달한다.
→ HTTP Authorization 헤더를 사용하거나 쿠키로 전달 - 클라이언트는 전달 받은 토큰을 저장
→ Local Storage, Session Stroage, Cookie 등에 저장 - 클라이언트가 서버로 리소스를 요청시 토크를 함께 전달
→ HTTP Authorization 헤더를 사용하거나 쿠키로 전달 - 서버는 전달받은 토큰을 서버의 비밀 키를 통해 검증.
→ 토큰 위조 및 유효 기간을 확인한다. - 토큰이 유효하다면 클라이언트의 요청에 대한 응답 데이터 전송
JWT (JSON Web Token)
JWT는 JSON 객체에 정보를 담고 이를 토큰으로 암호화하여 전송하는 기술이다.
JWT의 구성
JWT는 Header, Payload, Signature가 .으로 나뉘어져있다.
JWT의 구성요소는 JSON형태로 작성한 후 base64 방식으로 인코딩하면 된다
1. Header
Header에는 HTTP 헤더처럼 해당 토큰 자체를 설명하는 데이터가 담겨 있다. 토큰의 종류, 시그니처를 만들 때 사용하는 알고리즘을 JSON형태로 작성한다.
{
"alg" : "OGU59"
"typ" : "JWT"
}
2. Payload
HTTP의 페이로드와 같이 전달하려는 내용물(접근 권한, 유저 이름, 개인정보, 토큰 발급 시간 및 만료 시간)을 JSON형태로 담는다.
{
"sub" : "someINformation",
"name" : "ogu",
"iat" : 1523614
}
3. Signature
Signature는 토큰의 무결성을 확인할 수 있는 부분. Signature는 서버의 비밀 키 (암호화에 추가할 salt)와 Header에서 지정한 알고리즘을 사용하여 해싱한다.
예를 들어 HMAC SHA256 알고리즘 사용시
HMACSHA256(base64UrlEncode(header) + '.' + base64UrlEncode(payload), secret);
토큰방식의 한계
- 무상태성
토큰이 탈취되어도 강제로 만료시킬 수 없다. 위조당할 수 있음. - 유효기간
토큰 탈취를 대비하여 유효기간을 짧게 설정하면 사용자는 토큰 만료 때 마다 재로그인 해야하므로 좋지 않은 사용자 경험을 제공한다. - 토큰의 크키
많은 데이터를 담으면 암호화 과정도 길어지고 토큰의 크기가 커져 네트워크 비용 문제가 생길 수 있다.
액세스 토큰과 리프레시 토큰
토큰 인증 한계를 극복하기 위한 방법 중 한 가지.
- Access Token
서버에 접근하기 위한 토큰. 보안을 위해 24시간 정도의 짧은 유효기간을 가짐 - Refresh Token
액세스 토큰이 만료되었을 때 새로운 액세스 토큰을 발급받기 위해 사용함. 액세스 토큰보다 긴 유효기간을 설정
'🐣 STUDY > HTTP, WEB' 카테고리의 다른 글
🌱 CSR과 SSR (0) | 2023.06.27 |
---|---|
🌱 [Web] cookie & session (0) | 2023.05.02 |
🌱 [HTTP/네트워크] 네트워크 기초 (2) | 2023.04.26 |
🌱 [사용자 친화 웹] 웹 표준 & 접근성 (2) | 2023.04.26 |
[기술면접] (1) | 2023.04.10 |