해싱
암호화만 가능
- 항상 같은 길이의 문자열을 리턴합니다.
- 서로 다른 문자열에 동일한 해시 함수를 사용하면 반드시 다른 결과값이 나옵니다.
- 동일한 문자열에 동일한 해시 함수를 사용하면 항상 같은 결과값이 나옵니다.
레인보우 테이블과 솔트(Salt)
레인보우 테이블에 기록된 값의 경우에는 유출이 되었을 때 해싱을 했더라도 해싱 이전의 값을 알아낼 수 있으므로 보안상 위협이 될 수 있습니다.
이때 활용할 수 있는 것이 솔트(Salt)
- 말 그대로 소금을 치듯 해싱 이전 값에 임의의 값을 더해 데이터가 유출되더라도 해싱 이전의 값을 알아내기 더욱 어렵게 만드는 방법입니다.
솔트를 사용하게 되면 해싱 값이 유출되더라도, 솔트가 함께 유출된 것이 아니라면 암호화 이전의 값을 알아내는 것은 불가능에 가깝다.
해싱의 목적
동일한 값의 데이터를 사용하고 있는지 여부만 확인하는 것이 목적
보통 비밀번호를 데이터베이스에 저장할 때, 복호화가 불가능하도록 해싱하여 저장
-> 해싱은 복호화가 불가능하므로 사이트 관리자도 정확한 비밀번호를 알 수 없게 됨
토큰
토큰을 사용하면 사용자의 인증 정보를 서버가 아닌 클라이언트 측에 저장
- 세션 기반 인증은 서버에서 유저의 상태를 관리
- 토큰은 유저의 인증 상태를 클라이언트에 저장할 수 있어서, 세션 인증 방식의 비교해 서버의 부하나 메모리 부족 문제를 줄일 수 있다.
토큰의 장점
무상태성: 서버는 비밀 키를 통해 클라이언트에서 보낸 토큰의 유효성만 검증하면 되기 때문에 무상태적인 아키텍처를 구축할 수 있다.
확장성: 다수의 서버가 공통된 세션 데이터를 가질 필요가 없다는 것도 토큰 기반 인증의 장점이다. -> 서버를 확장하기 더 용이함
어디서나 토큰 생성 가능: 토큰의 생성과 검증이 하나의 서버에서 이루어지지 않아도 되기 때문에 토큰 생성만을 담당하는 서버를 구축할 수 있다.
-> 여러 서비스 간의 공통된 인증 서버를 구현할 수 있습니다.
권한 부여에 용이: 토큰은 인증 상태, 접근 권한 등 다양한 정보를 담을 수 있기 때문에 사용자 권한 부여에 용이 이를 활용해 어드민 권한 부여 및 정보에 접근할 수 있는 범위도 설정할 수.
JWT
1. Header
토큰 자체를 설명하는 데이터가 담겨 있다. 토큰의 종류, 그리고 시그니처를 만들 때 사용할 알고리즘을 JSON 형태로 작성
{
"alg": "HS256",
"typ": "JWT"
}2. Payload
HTTP의 페이로드와 마찬가지로 전달하려는 내용물을 담고 있는 부분
어떤 정보에 접근 가능한지에 대한 권한, 유저의 이름과 같은 개인정보, 토큰의 발급 시간 및 만료 시간 등의 정보들을 JSON 형태로 담는 다.
{
"sub": "someInformation",
"name": "phillip",
"iat": 151623391
}3. Signature
버의 비밀 키(암호화에 추가할 salt)와 Header에서 지정한 알고리즘을 사용하여 해싱한다.
HMACSHA256(base64UrlEncode(header) + '.' + base64UrlEncode(payload), secret);
액세스 토큰(Access Token)과 리프레시 토큰(Refresh Token)
Access Token
액세스 토큰은 말 그대로 서버에 접근하기 위한 토큰
보안을 위해 보통 24시간 정도의 짧은 유효기간이 설정되어 있다.
Refresh Token
서버 접근을 위한 토큰이 아닌 액세스 토큰이 만료되었을 때 새로운 액세스 토큰을 발급받기 위해 사용되는 토큰
따라서 리프레시 토큰은 액세스 토큰보다 긴 유효기간을 설정한다.
