Hashing
해싱(Hashing)
가장 많이 쓰이는 암호화 방식 중 하나
암호화만 가능
해싱은 해시함수를 사용해 암호화를 진행한다.
- 해시함수 특징
- 항상 같은 길이의 문자열 리턴
- 서로 다른 문자열에 동일한 해시 함수를 사용하면 다른 결과값이 나옴
- 동일한 문자열에 동일한 해시함수를 사용하면 항상 같은 결과값이 나옴
레인보우 테이블 & 솔트(Salt)
항상 같은 결과값이 나오는 특성을 이용해 해함수를 거치기 이전의 값을 알아낼 수 있는 레인보우 테이블이 존재한다.
레인보우 테이블에 기록된 값의 경우는 유출되었을 때 해싱을 해도 해싱 이전의 값을 알아낼 수 있어 보안상 위협이 될 수 있다.
➡️ 이 경우 활용할 수 있는 솔트(Salt)가 있다.
솔트는 소금이라는 뜻으로 소금을 치듯 해싱 이전 값에 임의의 값을 더해 데이터가 유출돼도 해싱 이전의 값을 알아내기 어렵게 만드는 방법이다.
해싱 목적
해싱의 목적은 데이터 그 자체를 사용하는 것이 아닌, 동일한 값의 데이터를 사용하고 있는지의 여부를 확인하는 것이다.
해싱은 민감한 데이터를 다루어야 하는 상황에서 데이터 유출의 위험성은 줄이고 데이터 유효성을 검증하기 위해 사용되는 단방향 암호화 방식이다.
Token
토큰 인증 방식
토큰 인증 방식은 최근 웹 앱에서 많이 사용되는 인증 방식 중 하나
토큰을 사용하면 사용자의 인증 정보를 서버가 아닌 클라이언트 측에 저장할 수 있다.
웹 보안에서의 토큰은 인증과 권한 정보를 담고 있는 암호화된 문자열을 말한다.
토큰 인증방식 흐름
토큰 인증 방식의 장점
- 무상태성 : 서버가 유저의 인증 상태를 관리하지 않는다.
- 확장성 : 다수의 서버가 공통된 세션 데이터를 가질 필요가 없다.
- 어디서나 토큰 생성 가능 : 토크의 생성과 검증이 하나의 서버에서 이루어지지 않기 때문에 토큰 생성만을 담당하는 서버를 구축할 수 있다.
- 권한 부여 용이 : 토큰은 인증상태, 접근 권한 등 다양한 정보를 담을 수 있어 사용자 권한 부여에 용이하다.
JWT
JSON 객체에 정보를 담고 이를 토큰으로 암호화해 전송할 수 있는 기술
JWT 구성
.을 기준으로 3부분으로 존재한다.
- Header : 해당 토큰 자체를 설명하는 데이터가 담겨있다.
- 토큰의 종류, 시그니처를 만들때 사용할 알고리즘을 JSON형태로 작성한다.
- JSON 객체를 base64방식으로 인코딩하면 JWT의 Header가 된다.
- base64방식 : 원할때 디코딩할 수 있는 인코딩 방식, 민감정보는 담지 않도록 한다.
{ "alg": "HS256", "typ": "JWT" }
- Payload : 전달하려는 내용물을 담고 있는 부분
- 어떤 정보에 접근가능한지의 권한, 개인정보, 토큰의 정보들을 JSO형태로 작성한다.
- JSON 객체를 base64방식으로 인코딩하면 JWT의 Payload가 된다.
{ "sub": "someInformation", "name": "phillip", "iat": 151623391 }
- Signature : 토큰의 무결성을 확인할 수 있는 부분
- Header와 Payload가 완성되면 Signature는 서버의 비밀키와 Header에서 지정한 알고리즘을 사용해 해싱한다.
HMACSHA256(base64UrlEncode(header) + '.' + base64UrlEncode(payload), secret);➡️ 권한을 속이기 위해 토큰의 Payload를 변조해도 토큰을 발급할 때 사용하는 Secret을 정확하게 알고 있지 않으면 유효한 Signature를 만들어낼 수 없기 때문에 서버는 Signature를 검증하는 단계에서 올바르지 않은 토큰임을 알아낼 수 있다.
토큰 인증 방식의 한계
무상태성
인증상태를 관리하는 주체가 서버가 아니기 때문에, 토큰이 탈취돼도 해당 토큰을 강제로 만료시킬 수 없다.
유효 기간
토큰이 탈취되는 상황을 대비해서 유효 기간을 짧게 하면, 토큰이 만료될때마다 사용자가 다시 로그인을 해야하기 때문에 사용자 경험이 좋지 않다.
토큰의 크기
토큰에 많은 데이터를 담으면 그만큼 암호화하는 과정도 길어지고 토큰의 크기도 커져 네트워크 비용문제가 생길 수 있다.
액세스 토큰 & 리프레시 토큰
토큰 인증의 한계를 극복하기 위한 방법 중 하나로 액세스 토큰과 리프레시 토큰을 함께 사용한다.
Access Token
서버에 접근하기 위한 토큰
보안을 위해 보통 24시간 정도의 짧은 유효기간이 설정되어 있다.
Refresh Token
액세스 토큰이 만료되었을때 새로운 액세스 토큰을 발급받기 위해 사용되는 토큰
액세스 토큰보다 긴 유효기간을 설정한다.
💡 두 가지의 다른 토큰을 사용하는 경우, 액세스 토큰이 만료되더라도 리프레시 토큰의 유효기간이 남아있으면 사용자는 다시 로그인을 할 필요 없이 인증상태를 유지할 수 있다.
하지만 이 토큰마저 탈취되면 토큰의 긴 유효기간동안 악의적인 유저가 계속해 액세스 토큰을 생성하고 사용자의 정보를 해킹할 수 있다.
이를 대비해 리프레시 토큰을 세션처럼 서버에 저장하고 상태를 관리한다.
➡️ 결론은 이 세상에 완벽한 보안 방법은 없다.
개발자로서 내가 구현하려는 서비스에 어떤 인증방식이 가장 적절한지 판단하고 의사결정 할 줄 아는 것이 가장 중요하다.
출처, 참조 : 코드스테이츠
