Korean Institute of Information Technology
[ Article ]
The Journal of Korean Institute of Information Technology - Vol. 17, No. 2, pp.143-150
ISSN: 1598-8619 (Print) 2093-7571 (Online)
Print publication date 28 Feb 2019
Received 24 Jan 2019 Revised 22 Feb 2019 Accepted 25 Feb 2019
DOI: https://doi.org/10.14801/jkiit.2019.17.2.143

IUWT 기반 토큰 인증 기술

강희복* ; 장행천* ; 장창수**
*전남대학교 컴퓨터공학과
**전남대학교 컴퓨터공학과 교수(교신저자)
IUWT Based Token Authentication Technology
Hee-Bog Kang* ; Haeng-Cheon Jang* ; Chang-Soo Jang**

Correspondence to: Chang-soo Jang Chonnam University 2th gong-hakgwan 4 flor, Daehakro 50 Yeosu-si, Jeollanam-do. 59626, Korea, Tel.: +82-61-659-7251, Email: csjang@chonnam.ac.kr

초록

웹 서비스에서 사용자 인증을 지속시키는 방법으로는 쿠키, 세션, 토큰이 있다. 토큰 방식은 서버가 발행한 토큰에 첨부된 서명의 변조 여부만 체크하여 사용자를 인식하는 방식이며 OAuth(Open Authorization)기반과 Claim(사용자 속성)기반으로 구분한다. JWT(Json Web Token)은 Claim 기반 토큰의 표준이며 IUWT(Internet Protocol & Universally Unique Identifier Web Token) 토큰은 JWT 토큰 형식을 따른다. 본 논문에서는 토큰에 암호화 된 IP 주소와 UUID를 포함하고 서버에서 클라이언트가 제공한 IP 주소와 UUID를 비교하는 방법을 사용하여 토큰이 도용되었는지 여부를 신속하게 판단 할 수 있는 IUWT 토큰 인증 기술을 제안한다. OAuth 및 JWT와 달리 탈취된 토큰은 만료기간이 남았더라도 인증을 무효화 시킬 수 있고, SSL(Secure Socket Layer) 보안통신 환경을 요구하지 않으므로 보안서버 구축에 어려움이 있는 소규모 서비스에도 적합하다.

Abstract

In web services, persist user authentication using cookie, session and tokens. The token method is a recognizing the tampering of the signature attached to the token issued by the server on OAuth and Claim. JWT token is the standard for Claim based tokens, and IUWT token follow the JWT token form. In this paper, we propose an IUWT token authentication technology which can quickly determines whether a token is stolen by using the method of including the encrypted IP address and UUID in the token and comparing the IP address and UUID provided by the client in the server. Unlike OAuth and JWT, the forgotten token can invalidate the authentication even if the expiration period is left, and it is suitable for small-sized service that has difficulty in building security server because it does not require SSL secure communication environment.

Keywords:

token, oauth, jwt, iuwt, user authentication, ssl, encrypted ip, uuid

Ⅰ. 서 론

아이디와 패스워드를 이용한 사용자 인증은 시스템 구현이 간단하여 컴퓨터 시스템의 가장 오래된 기본적 인증방식이다. 이 방식은 사용자의 기억에 의존하므로 복잡한 패스워드를 사용하기 어렵다는 한계가 있어서 단순하거나 반복적인 기호를 사용하는 경향으로 인해 사전 공격(Dictionary attack)에 노출될 수 있고 스푸핑(Spoofing), 스누핑(Snooping), 스니핑(Sniffing) 공격에 노출될 수 있다. 사용자 인증을 일정기간 유지하는 방법으로 쿠키(Cookie), 세션(Session), 토큰(Token) 등이 이용되고 있다.

토큰 방식은 로그인 과정에서 사용자의 정당성이 확인되면 서버에서 특정 문자열을 인코딩하고 해시로 서명하여 토큰을 생성하고 브라우저를 통해 클라이언트에 전달한다. 토큰은 사용자의 상태를 서버에 보관하지 않고 클라이언트 측에서 들어오는 요청만으로 토큰의 변조 여부를 확인하여 사용자를 인증하기 때문에 서버의 확장성을 높일 수 있다.

토큰은 OAuth 기반과 Claim 기반으로 구분하며 JWT(Json Web Token)는 Claim 기반을 적용하고 있다. OAuth 토큰은 무의미한 문자열로 고유 식별자를 만들어서 토큰을 발급하고 사용자 인증이 필요할 때마다 인증 서버의 DB에 접근하여 유효성을 확인하는 과정을 거치지만 쿠키 보다 보안이 강화되었고 세션 보다 서버의 메모리 자원을 절약한다. JWT 토큰은 내부에 사용자 정보가 포함되어 있어서 OAuth 토큰과 비교할 때 서버의 사용자 정보에 접근하기 위한 리소스를 절약할 수 있지만 토큰의 길이가 길어지는 단점을 갖고 있다.

인증 서버에 의존하지 않는 토큰 방식은 웹 서비스와 웹 서비스간의 API에 주로 이용되며 모바일 앱과 클라우드 환경에서 사용자 로그인을 최소화 하기 위한 인증 계속성을 제공한다. 본 논문에서 제시한 IUWT 토큰 인증 방식은 로그인 등으로 본인이 확인되면 클라이언트 IP 주소 암호화 및 UUID를 생성하여 토큰 내부에 저장하고, 토큰이 사용될 때 토큰 내부의 암호화된 IP 주소와 토큰을 사용한 IP 주소를 비교하여 토큰의 탈취 여부를 빠르게 판단하고 인증의 지속 여부를 결정한다. IUWT 토큰 방식은 SSL 환경을 요구하지 않으므로 보안 서버 운영이 곤란한 소규모 웹 서비스[1]에도 적합하다


Ⅱ. 관련 연구

2.1 OAuth 인증

OAuth 토큰 인증 방식은 사용자 정보가 포함되지 않은 서명된 문자열을 이용하여 사용자 인증을 수행하고 다른 웹 사이트에도 접근 권한을 부여할 수 있는 공통적인 수단을 제공하는 개방형 표준이다[2]. 이 방식은 아마존, 구글, 페이스북, 트위터, 마이크로소프트웨어 등에서 사용하고 있다. OAuth 토큰 인증 방식이 사용되기 전에는 인증 방식의 표준이 없었기 때문에 아이디와 비밀번호를 사용하는 기본적 인증 방식을 사용하거나 개발 업체마다 각자의 방법으로 사용자 인증을 수행하였다.

OAuth 토큰 인증 방식은 2007년 12월 OAuth Core 1.0 스펙이 선언되었고 2010년 IETF OAuth워킹그룹에 의해 OAuth 1.0 프로토콜 표준안(RFC5849)이 발표 되었다[3]. 현재는 개발자의 편리성과 단순성을 고려하여 만든 OAuth 2.0 표준안(RFC6749)이 2012년에 발표되었으며[4], IoT 인증을 위한 표준작업[5]이 계속 진행 중이다.

SNS(Social Networking Service)와 OAuth 인증 방식을 결합하여 한번의 사용자 인증으로 여러 SNS 계정 연동관리를 할 수 있다. 이러한 연동 서비스 인증 과정에서 CSRF(Cross Site Request forgery) 공격을 받을 수 있다. CSRF 공격자는 탈취한 OAuth 토큰을 이용하여 피해자의 SNS 계정과 공격자의 SNS 계정을 연동할 수 있고, 공격자는 사용자의 권한을 도용하여 웹 서버의 삭제, 업데이트 기능을 실행할 수 있게 된다. SNS 이용 증가에 따른 로그인 횟수를 줄이려는 OAuth 토큰의 연동 기능을 고려할 때 CSRF 공격에 대한 방어는 OAuth 토큰 자체로는 해결할 수 없고 서버에서 다양한 공격 패턴에 대응해야 하는 문제점이 있다[6].

2.2 JWT 인증

JWT는 Claim 기반 토큰이며, JSON 객체로서 클라이언트와 서버 간에 정보를 전달할 수 있는 작고 독립적인 방법을 정의하는 공개 표준(RFC7519)이다[7]. 토큰에 저장된 정보는 JSON 형태로 정의한다. 하지만 JSON은 개행문자(‘\n’ 등)가 포함되어 있기 때문에 브라우저의 헤더에 그냥 넣기 불편하다. 따라서 해당 JSON 문자열은 Base64Url 인코딩을 통해 하나의 문자열로 변환한 후 사용한다.

Google, Apple 등에서 사용하는 JWT 토큰은 다음과 같은 이점이 있다.

1) Reliable : HMAC 알고리즘 또는 RSA 해시 알고리즘을 사용하는 공개키, 개인키를 이용하여 서명되었기 때문에 검증되었고 신뢰도가 높다.

2) Compact : 크기가 작기 때문에 POST 파라메터 혹은 HTTP Header를 통한 빠른 전송을 할 수 있다.

3) Self-contained : 사용자에 대한 정보가 들어있기 때문에 데이터베이스에 두번 이상의 쿼리를 사용할 필요가 없다.

2.3 JWT 구조

JWT는 그림 1과 같이 Header, Payload, Signature 세 개의 영역으로 구성되며 Header와 Payload는 Base64Url로 인코딩하고 Signature은 Secret 키를 이용하여 헤더에 지정된 해시 알고리즘으로 서명한다. 토큰은 각 영역을 마침표(.)으로 구분하여 하나의 문자열을 이룬다. 형태는 xxxx.yyyy.zzzz로 표현된다.

Fig. 1.

JWT structure

Claim 형태의 Payload는 이름과 값의 여러 쌍으로 이루어져있다. 이름은 Reserved, Public, Private로 구분되며 Reserved 이름은 iss, sub, aud, exp, nbf, iat, jti 등이 등록되어 있는데 사용 여부는 선택적이다.

디코딩 하면 값을 바로 확인할 수 있는 구조이기 때문에 서버에서 데이터베이스를 검색할 필요 없이 사용자 정보를 즉시 사용할 수 있다.

Signature = HMAC256(“base64encode(header)+.”+ base64encode(payload), secret key)

서명된 Signature는 발신자를 확인하고 Payload의 변경 여부를 확인하는데 사용된다. Secret 키는 서버의 비밀 값이므로 토큰은 서버만이 생성할 수 있고 서버만이 검증할 수 있다.

token = base64Encode(header) +“.”+ base64Encode(payload) +"." + base64Encode(signature)

2.4 토큰 방식의 단점

2.4.1 탈취 시 신분위장

토큰 방식의 단점은 토큰 자체를 공격자가 탈취한 경우, 이를 재전송하면 공격자가 사용자의 신분으로 쉽게 위장할 수 있다. 이런 문제를 해결하기 위하여 TOTP(Time-based One Time password) 방식으로 난수화된 일회용 패스워드를 사용하는 방법도 있다[8]. 그러나 TOTP의 경우 클라이언트와 서버가 동일한 난수를 발생시켜야 하고 패스워드를 공유해야 하는 불편이 따른다.

2.4.2 만료기간까지 삭제 불가

토큰은 서버에서 서명 변조 여부만 체크한 후 로그인 상태를 유지시키므로 탈취되어 사용된 경우라도 토큰의 만료기간까지는 사용자의 지위를 갖게 되며 임의로 토큰을 삭제할 기준이 없다. 토큰의 탈취 여부를 즉시 체크하는 요소가 필요하다.

2.4.3 Refresh 토큰 사용

JWT는 Access 토큰의 만료기간을 짧게 하고 ReFresh 토큰의 만료기간을 길게 발급한 후 Access 토큰이 만료되었을 때 Refresh 토큰을 요구하여 별도의 로그인 절차 없이 Access 토큰을 재발급하는 방법을 사용하여 Access 토큰의 부정 사용을 최소화하고 있다. 그러나 두 종류의 토큰 발행은 자원 낭비가 되므로 Access 토큰만으로 탈취된 경우 즉시 인증을 무효화 할 수 있는 방안이 필요하다.

본 논문은 쉽게 획득할 수 있는 사용자의 접속 IP 주소를 암호화하고 인증된 사용자를 특정할 수 있는 UUID를 생성하여 토큰을 발행함으로써 공격자가 토큰을 획득하더라도 토큰 내부에 있는 UUID 값과 공격자의 브라우저에서 획득한 IP 주소가 불일치 할 경우 재 인증을 요구하는 방법을 적용함으로써 공격을 무효화 시킨다.


Ⅲ. 사용자를 특정하는 IUWT 기반 인증 기술

본 논문에서 제안하는 IUWT 토큰 인증은 JWT 토큰에서 발생할 수 있는 공격자의 토큰 탈취 후 재사용에 따른 사용자 신분 위장을 무효화하는 IP 주소 및 UUID 기반 토큰을 제시한다. 서명 부분의 변조 여부를 일차적으로 확인하는 것은 JWT와 동일하다.

IUWT 기반 인증의 특징은 토큰을 탈취한 후 변조하지 않고 토큰의 만료기간까지 부정 사용할 수 있는 가능성을 즉시 무효화 시키는데 있다. 무효화 대상을 판단하는 방법은 IP 주소와 UUID를 이용한다. IP 주소는 클라이언트가 웹 서비스를 요청할 때 Remote 주소 정보를 제공하는 기능을 이용한다. 로그인이 성공한 시점의 IP 주소를 AES 알고리즘으로 암호화하여 토큰 내부에 저장하기 때문에 토큰이 탈취되더라도 IP 주소를 판독하지 못한다. 토큰을 탈취한 부정 사용자가 웹 서비스를 요청할 때 웹 서버가 획득한 Remote 주소와 토큰 내부의 IP 주소가 불일치할 경우 토큰을 즉시 무효화 시키고 로그인을 요구한다. IP 주소가 수시로 바뀌는 모바일의 경우에는 토큰 내부의 UUID와 로그인이 성공할 때 발급한 UUID용 쿠기(Cookie)를 비교함으로써 토큰 탈취 여부를 판단한다.

3.1 UUID 생성

네트워크 상에서 서로 모르는 개체들을 식별하기 위해서는 각각 고유의 이름이 필요하다. 동시 다발적이고 독립적으로 개발되고 있는 시스템들에게 고유성을 완벽하게 보장하기 위해서 탄생한 것이 범용고유식별자(UUID)이며 국제기구에서 RFC4122 표준으로 정하고 있다[9].

UUID는 16옥텟(octet)의 숫자(128bit) 이다. 표준 형식에서 32개의 십육진수로 표현되며 4개의 하이픈을 포함하여 36개 문자로 된 8-4-4-4-12라는 5개 그룹으로 구성되어 있다. 본 논문에서는 Unique한 UUID를 생성할 목적으로 단순한 랜덤 숫자용 버전-4를 적용하였다. UUID의 5개 그룹은 그림 2와 같이 구성되어 있다.

Fig. 2.

UUID structure

3.2 Remote Address

웹 서버 앞에 L4 같은 Load Balancer 또는 Proxy Server, Caching Server 등이 있는 경우 클라이언트 IP 주소는 L4 또는 Proxy IP 주소를 얻게 되는데 이는 원하는 결과가 아니다. 인터넷 공유기를 사용하여 여러 클라이언트가 동시에 웹 서버에 접속한 경우에도 클라이언트 IP 주소는 원하는 결과를 얻을 수 없다[10].

본 논문에서는 토큰의 Payload 부분 중 Private 영역에 IP 주소와 UUID를 암호화하여 동시에 저장한다.

IP 주소는 로그인할 때 웹 서버에서 파악된 값이면 Public IP, Local IP 관계없이 AES 알고리즘으로 암호화하여 토큰 내부에 저장된다. 클라이언트의 User_Agent를 이용하여 운영체제와 브라우저를 식별하고 모바일이 아닌 경우 IP 주소를 비교하여 토큰의 탈취 여부를 판단한다.

IP 주소 암호용 키는 서버의 secret 키를 해시하여 사용한다.

skey = substr(hash('sha256', secret key, true), 0, 32)
ip = $_SERVER[‘REMOTE_ADDRESS’]
ip_encrypt = aes256encrypt(ip,skey)

3.3 IUWT 토큰 발급

사용자가 브라우저로 서버에 접속한 후 서버에서 요구하는 사용자 정보를 등록하거나 토큰 없이 로그인할 때 서버는 사용자의 IP 주소 및 UUID 포함된 토큰을 클라이언트에 전송한다. IP 주소와 UUID는 AES encrypt를 이용하여 암호화하고 토큰 내부에 포함하며, UUID용 쿠키는 따로 평문으로 생성하여 클라이언트에 전송한다.

클라이언트가 웹 서비스를 요청할 때 서버는 토큰을 파싱하여 서명 변조여부 및 IP 주소 및 UUID 일치 여부를 확인하여 사용자 인증을 유지시킬 것인지 무효화할 것인지 판단한다. 인증이 무효화 되면 로그인을 다시 호출한다.

s = HMAC256(Header+Payload, Secret)
signature = base64_encode(s)

함수 HMAC256는 서명생성 함수이며 공개 가능한 Header와 Payload는 base64 인코딩하고 서버의 Secret 키를 이용하여 서명하고 토큰을 생성한다. Payload는 ID, Expires, IP 주소, UUID, Level 등으로 구성되어 있다.

그림 3은 IUWT 기반 토큰 인증의 개념을 도식화한 것으로 클라이언트가 서버에 처음 연결될 때 브라우저는 토큰 정보를 서버에 전송한다. 서버가 브라우저로 부터 토큰을 전송 받지 못한 경우 서버는 UUID를 쿠키로 생성하여 브라우저를 통해 클라이언트로 전송하여 해당 클라이언트에 범용고유식별자를 부여한다. 이처럼 로그인 여부와 관계없이 Unique한 UUID를 먼저 부여하면 사용자 인증이 필요 없는 쇼핑 카트 등에서 동일인 인식 기준으로 활용할 수 있다. 또한 UUID가 발급된 후 토큰을 사용할 때 토큰 내부의 UUID와 쿠키로 인식한 UUID가 상이할 경우 토큰이 탈취된 것으로 간주하여 인증을 무효화 시킬 수 있다.

Fig. 3.

IUWT base token issue

3.4 로그인

사용자가 브라우저로 서버에 접속하면 브라우저에 IUWT 토큰이 존재하지 않거나 토큰의 만료기간이 경과한 경우 및 자동 로그인이 거절된 경우에는 로그인 화면을 브라우저에 노출시킨다.

사용자는 로그인 화면에 아이디와 패스워드를 입력하고 서버에 전송한다. 서버는 사용자 아이디와 패스워드를 이용하여 데이터베이스를 검색하고 사용자를 인증한다.

로그인이 성공한 경우 IP 주소 및 UUID가 포함된 Payload를 구성하고 토큰 발행 방법에 따라 IUWT 토큰을 브라우저를 통해 클라이언트에 전송한다.

3.5 IUWT 기반 토큰 포맷

그림 4를 보면 Payload 부분에 IP 주소 값이 AES 알고리즘으로 암호화되어 base64 디코딩으로 IP 주소를 식별할 수 없다는 것을 알 수 있다. 토큰 탈취 후 ARP(Address Resolution Protocols) 스푸핑 공격을 하더라도 토큰 내부의 IP 주소 값을 알 수 없으므로 IP 주소 변조 여부를 쉽게 파악할 수 있다.

Fig. 4.

IUWT base token format

서명 검증은 IUWT 토큰을 Parsing하여 Header와 Payload를 마침표로 연결한 후 서버의 Secret 키를 이용하여 HMAC256 해시 방법으로 Signature을 생성하고 다시 base64로 encode하여 얻은 값과 Parsing하여 얻은 서명의 일치 여부를 비교한다.

Signature = HMAC256(base64enc(Header) + “.” + base64enc(Payload), Secret key)
Signature_encoded = base64_encode(Signature)

3.6 IUWT의 장점

제안하는 IUWT 토큰의 장점은 4가지가 있다. 첫 번째는 토큰의 탈취 여부를 쉽게 확인할 수 있는 기능이다. 토큰의 내부에 있는 IP 주소 및 UUID 정보와 웹 서비스 환경에서 취득한 IP 주소 및 UUID 정보의 동일성을 비교함으로써 상이한 정보가 얻어진 경우 탈취로 간주하여 토큰의 만료기간에 관계없이 사용자 인증을 무효화 한다.

두 번째는 토큰 내부의 IP 주소와 UUID가 plaintext 상태로 노출되지 않도록 비밀 키로 암호화하여 유통함으로써 토큰 내부를 Base64 디코딩으로는 정확한 정보를 얻지 못하게 하는 기능이다. 비교대상을 알 수 없는 상태에서 탈취되어 재사용한 토큰은 서버의 토큰 비교 기능으로 쉽게 구별되어 무효화 시킬 수 있으며 별도의 SSL 보안통신 환경을 요구하지 않는다.

세 번째는 토큰의 신뢰도가 높아지기 때문에 만료기간을 늘려 사용자 인증을 최소화 할 수 있다. Access 토큰만 이용하여 토큰의 탈취 여부를 판단할 수 있으므로 ReFresh 토큰을 발행할 필요가 없어서 토큰 인증 방식의 메커니즘을 단순화 시킬 수 있다.

네 번째는 단순 반복적인 인증이 요구되는 IoT 인증에 적합하다. IoT에 주로 사용되는 OAuth 토큰 방식은 데이터가 짧다는 잇점이 있지만 데이터 축적이 반복될수록 서버 인증의 오버헤드가 발생한다. IUWT 토큰은 IoT 고유의 UUID를 기반으로 내부 정보를 포함시킴으로써 반복적인 데이터 축적 작업의 오버헤드를 줄일 수 있다.


Ⅳ. 안정성 분석

본 논문에서 제안하는 IUWT 토큰 인증 방식의 안전성을 분석하기 위해 SSL(Secure Socket Layer) 보안 통신 환경을 구축하고, 아파치 2.2.14 웹서버, PHP 5.4.45 및 MySQL 5.1.39을 사용하였으며 curl을 사용하여 웹 서버의 접속을 단순 반복적으로 수행하였다. 사용자 정보 인증 시 발생하는 MySQL 사용 리소스와 IUWT 토큰 내부의 Claim 정보를 이용하여 인증을 유지할 때의 리소스를 비교하였다. IUWT 토큰은 서명 변조 여부를 검사하는 일차적 기능과 암호화된 IP 주소와 Remote 주소를 비교하고 모바일 사용자의 경우 암호화된 UUID와 쿠키의 UUID를 비교하여 인증 무효화 율을 분석하였다.

4.1 로그인과 IUWT 인증 비교

4.1.1 로그인

로그인 페이지에 접속하여 아이디와 비밀번호를 입력한 후 사용자 인증 페이지로 이동하여 MySQL 연결, DB 선택, 테이블 검색을 통해 아이디 및 비밀번호 일치 여부를 검증하는 과정과 토큰을 생성하는 과정을 수행하였는데 평균 처리속도는 0.09375초이며 0.14MB의 메모리를 사용하였다.

4.1.2 IUWT 인증

IUWT 토큰을 header와 payload, signature 부분으로 파싱한 후 다시 header와 payload를 결합하여 signature 해시 값을 얻고, signature 값을 base64 엔코딩한 값과 토큰을 파싱하며 얻은 signature 값을 대조하여 서명 변조 여부를 판단하였다.

IP 주소는 복호화 과정을 거친 후 Remote 주소 값과 대조하였다. 서명 확인과 IP 주소 복호화 및 대조 작업에 걸린 시간은 최초에는 0.046875초 측정되었고 0.17MB의 메모리를 사용하였으나 회차가 거듭될수록 처리 속도는 0초에 가깝게 측정되었으며, 0.002MB의 메모리를 사용하였다. 테스트는 ARP 스푸핑 공격 방식으로 100회 실시하였고 100% 토큰 탈취를 판별하였다.

그림 5그림 6은 로그인과 IUWT 토큰 인증의 처리 속도와 리소스 사용량에 대한 비교를 표시한 것이다.

Fig. 5.

Process time of login and IUWT token

Fig. 6.

Using memory of login and IUWT token


Ⅴ. 결론 및 향후 과제

본 논문에서 제시한 IUWT는 JWT 규약을 따르면서 Payload에 IP 주소 및 UUID 정보를 포함시키고 AES 알고리즘으로 IP 주소와 UUID를 암호화 하였다. 토큰이 탈취되어 재사용될 경우 토큰 내부의 비교 값과 웹 서비스 환경에서 얻은 비교 값을 대조하여 인증을 즉시 무효화할 수 있었다.

IUWT 인증 방식은 IP 주소 및 UUID를 이용하여 사용자 인증 범위를 특정할 수 있는 기술이며 추가적인 계산 절차를 필요로 하지 않는다. 실험적 평가를 통해 제안된 기법이 토큰이 탈취되었을 때 토큰의 만료기간에 구애 받지 않고 인증을 즉시 무효화하는 탈취 인식 능력이 효과적이라는 결과를 보였다. 토큰 탈취 인식능력이 높고 SSL 보안 통신을 요구하지 않는 점은 서버의 오버헤드를 줄일 수 있다. 사용자 인증 연속성이 필요한 모바일 인증과 Iot 기기의 서버 등록 시에 활용하면 정보의 신뢰도를 높일 수 있다.

다만 CSRF 공격으로 IUWT 토큰을 탈취당하지 않은 상태에서 공격의 희생자가 될 경우, 토큰 변조와 IP 주소 및 UUID의 상이점을 발견할 수 없으므로 IUWT 토큰만을 이용하여 공격자를 막을 수는 없다. 이러한 CSRF 공격에 대응하여 IUWT 토큰 은 FROM의 Hidden 값에 랜덤 토큰을 추가로 발행하고 Http Header에 동일 값을 쿠키로 저장시킨 후 Request가 있을 때 두 값을 비교토록 하였다.

References

  • Byung-kil Byun, "All-IP User Authentication and Authorization Mechanism by OTP in the SSL-VPN System", Journal of Korean Institute of Information Technology, 9(9), p139-146, Sep.), (2011.
  • Whitson Gordon, "Understanding OAuth; What happens when you log into a site with Google, Twitter or Facebook", https://lifehacker.com, [accessed: Oct. 15. 2018].
  • E. Hammer-Lahav, "The OAuth 1.0 Protocol", IETF, RFC5849, Apr.), (2010.
  • D. Hart, "The OAuth 2.0 Authorization Framework", IETF, RFC6749, Oct.), (2012.
  • H. Tschofenig, "The OAuth 2.0 Internet of Things (IoT) Client Credentials Grant", draft-tschofenig-ace-oauth-iot00.txt, Jul.), (2014.
  • Alexei Czeskis, Alexander Moshchuk, Tadayoshi Kohno, and Helen J. Wang, "Ligntweight server support for browser-base CSRF protection", Proceedings of the 22nd international conference on World Wide Web, Rio de Janeiro, Brazil, p273-284, May), (2013. [https://doi.org/10.1145/2488388.2488413]
  • RFC7519, JSON Web Token, Https://tools.ietf.org/html/rfc7519, [accessed: Aug. 01, 2018].
  • RFC6238, TOTP, Time-Based One-Time Password Algorithm, Https://tools.ietf.org/html/rfc6238, [accessed: Oct. 15. 2018].
  • RFC4122, UUID, https://tools.ietf.org/html/rfc4122, [accessed: Sep. 01. 2018].
  • L. Kavisankar, and C. Chellappan, "A mitigation model for TCP SYN flooding with IP spoofing", 2011 International Conference on Recent Trends in Information Technology (ICRTIT), Chennai, Tamil Nadu, India, p251-256, Jun.), (2011. [https://doi.org/10.1109/ICRTIT.2011.5972435]
저자소개
강 희 복 (Hee-Bog Kang)

2015년 2월 : 전남대학교 컴퓨터공학과(공학석사)

2018년 2월 : 전남대학교 컴퓨터공학과(박사수료)

관심분야 : 컴퓨터네트워크, 클러스터링, 웹서비스

장 행 천 (Haeng-Chon Jang)

1993년 2월 : 서울과학기술대학교 시각디자인학과(미술학사)

1999년 8월 : 서울과학기술대학교 산업디자인학과(미술학석사)

2015년 3월 ~ 현재 : 전남대학교 컴퓨터공학과(박사과정)

관심분야 : 상거래, 웹서비스

장 창 수 (Chang-Soo Jang)

1980년 2월 : 조선대학교 전자공학과(공학사)

1982년 8월 : 건국대학교 전자공학과(공학석사)

1997년 2월 : 서강대학교 컴퓨터공학과(공학박사)

1984년 ~ 현재 : 전남대학교 컴퓨터공학과 교수

관심분야 : 병렬처리구조, 컴퓨터네트워크, DSP

Fig. 1.

Fig. 1.
JWT structure

Fig. 2.

Fig. 2.
UUID structure

Fig. 3.

Fig. 3.
IUWT base token issue

Fig. 4.

Fig. 4.
IUWT base token format

Fig. 5.

Fig. 5.
Process time of login and IUWT token

Fig. 6.

Fig. 6.
Using memory of login and IUWT token