[Network] HTTP 인증

[ HTTP 인증 ]

HTTP 에서 이용할 수 있는 인증 방식에 대해 공부해보겠습니다.

• BASIC 인증
• DIGEST 인증
• SSL 클라이언트 인증
• 폼 베이스 인증

이 밖에도 통합 Windows 인증 등이 있지만 이 글에서는 위 4가지 인증방식에 대해서만 알아보겠습니다.

 

HTTP 인증은 대단한 방법이 있는게 아닌 HTTP 통신을 할때, 특정 헤더를 추가해 정보를 넘겨준다거나, 보안과 관련된 정보를 추가해 넘겨주는 방식을 사용하게 됩니다. 아래의 글을 읽으시면서 각 인증방식들이 HTTP통신을 할때 어떤 정보들을 추가해서 통신을 하는지 차이점을 살펴 보며 읽어보시면 좀 더 도움이 되실 수 있을거 같습니다.

[ BASIC 인증 ]

BASIC 인증은 웹 서버와 대응하고 있는 클라이언트 사이에서 이뤄지는 인증 방식입니다.

 

클라이언트 리퀘스트 송신

GET /private/ HTTP/1.1 
Host: hackr.jp

 

 

1. 상태 코드 401로 응답해서 인증이 필요하다는 것을 전달

HTTP/1.1  401 Authorization Required
Date:Mon, 19 Sep 2011 08:38:32 GMT
Server: Apache/2.2.3 (Unix)
WWW-Authenticate: Basic realm="Input Your ID and Password"

 

BASIC 인증이 필요한 리소스에 리퀘스트가 있을 경우에는 서버는 상태 코드 401 Authorization Required와 함께 인증의 방식(BASIC)과 Request-URI의 보호 공간을 식별하기 위한 문자열(realm)을 WWW-Authenticate 헤더 필드에 포함해서 리스폰스를 반환합니다.

 

 

2. 유저ID와 패스워드를 Base64 형식으로 인코드한 것을 송신

Get /private/ HTTP/1.1
Host: hacker.jp
Authorization: Basic Z3Vlc3Q6Z3Vlc3Q=

 

상태 코드 401을 받은 클라이언트는 BASIC 인증을 위해서 유저 ID와 패스워드를 서버에 송신할 필요가 있습니다.

송신하는 문자열은 (유저ID:패스워드) 형태이며 문자열을 Base64이라 불리는 형식으로 인코드 한 것입니다.

 

 

3. 인증 성공 시에는 상태 코드 200으로 응답하고 실패했을 경우에는 다시 상태코드 401로 응답

HTTP/1.1  200 OK
Date:Mon, 19 Sep 2011 08:38:35 GMT
Server: Apache/2.2.3 (Unix)

Authorization 헤더 필드를 포함한 리퀘스트를 수신한 서버는 인증 정보가 정확한지 여부를 판단합니다. 인증 정보가 정확하면 Request-URI 리소스를 포함한 리스폰스를 반환합니다.

 

BASIC 인증 문제점

Base64라는 인코딩 형식을 사용하고 있지만 이것은 암호화는 아니기 때문에 아무런 부가 정보 없이도 복호화가 가능합니다. 즉, 도청의 위험이 있습니다.

BASIC 인증을 하면, 일반 브라우저에서는 로그아웃을 할 수 없다는 문제도 있습니다.

 

 

[ DIGSET 인증 ]

BASIC 인증의 약점을 보안하기 위해 나왔으며 DIGSET 인증에는 챌린지 리스폰스 방식이 사용되고 있어서 BASIC 인증과 같이 패스워드를 있는 그대로 직접 보내는 일은 없습니다.

 

챌린지 리스폰스 방식

최초에 상대방에게 인증 요구를 보내고 상대방 측에서 받은 챌린지 코드를 사용해서 리스폰스 코드를 계산합니다. 이 값을 상대에게 송신하여 인증을 하는 방법입니다.

리스폰스 코드라는 패스워드와 챌린지 코드를 이용해서 계산한 결과를 상대에게 보내기 때문에 BASIC 인증과 같은 방식에 비하면 패스워드가 누출될 가능성이 줄어듭니다.

 

 

리퀘스트송신 (클라이언트 → 서버)

GET /digest/ HTTP/1.1
Host: hacker.jp

 

 

 

1. 인증이 필요하다는 것을 전달하기위해 상태 코드 401로 응답하는 것과 함께 패스워드와 챌린지 코드(nonce)를 송신 (서버 → 클라이언트)

HTTP/1.1 401 Authorization Required
WWW-Authenticate: Digest realm="DIGEST", 
nonce="MOSQZ0itBAA=44abb6784cc9cbfc605a5b0893d36f23de95fcff", algorithm=MD5, qop="auth"

 

인증이 필요한 리소스에 리퀘스트가 있을 경우에는 서버는 상태 코드 401 Authorization Required와 함께 리스폰스 방식의 인증에 필요한 챌린지 코드(nonce)를 WWW-Authenticate 헤더 필드에 포함해서 리스폰스를 반환합니다.

WWW-Authenticate 헤더 필드에 반드시 포함되어야 하는 정보는 "realm"와 "nonce" 두 개입니다.

 

 

2. 패스워드와 챌린지 코드에서 리스폰스 코드(response)를 계산해서 송신 (클라이언트 → 서버)

GET /digest/ HTTP/1.1
Host: hacker.jp
Authorization: Digest username="guest", realm="DIGEST", 
nonce="MOSQZ0itBAA=44abb6784cc9cbfc605a5b0893d36f23de95fcff", url="/digest/", algorithm=MD5,
response="df56389ba3f7c52e9d7551115d67472f", qop=auth, nc=00000001, cnonce="082c875dcb2ca740"

 

클라이언트는 DIGEST 인증을 위해 필요한 정보를 Authorization 헤더 필드에 포함해서 리스폰스를 반환합니다.

• 반드시 포함되어야 하는 정보는 "username", "realm", "nonce", "uri", "response"입니다.
• username은 지정된 realm에서 인증 가능한 사용자 이름입니다.
• uri는 Request-URI에 있는 URI지만 프록시에 의해 변경되는 경우도 있기 때문에 여기에 복사해 놓습니다.
• responses는 패스워드 문자열을 MD5로 계산한 것으로, 리스폰스 코드입니다.

 

3. 인증 성공 시에는 상태 코드 200으로 응답하고, 실패했을 경우에는 다시 상태 코드 401로 응답 (서버 → 클라이언트)

HTTP/1.1  200 OK
Authentication-Info: rspauth="f218e9ddb407a3d16f2f7d2c4097e900", 
cnonce="082c875dcb2ca740", nc=00000001, qop=auth

 

• Authorization 헤더 필드를 포함한 리퀘스트를 받은 서버는 인증 정보가 정확한 것인지 아닌지를 판단합니다.
• 인증 정보가 정확한 경우에는 Request-URI의 리소스를 포함한 리스폰스를 반환합니다.

 

DIGEST 문제점

• DIGEST 인증은 BASIC 인증에 비해서 높은 보안 등급을 제공하지만 HTTPS에 비하면 낮습니다.
• DIGEST 인증에서는 패스워드의 도청을 방지하기 위한 보호 기능은 제공하고 있지만 이외에 위장을 방지하는 기능은 제공하고 있지 않습니다.

 

[ SSL 클라이언트 인증 ]

SSL 클라이언트 인증은 HTTPS의 클라이언트 인증서를 이용한 인증 방식입니다.

사전에 등록된 클라이언트에서의 액세스인지 아닌지를 확인할 수 있습니다.

예를 들면, 유저 ID와 패스워드 정보가 도난되었을 때에 제 3자가 위장을 하는 경우를 방지하기 위한 대책 중에 하나로 사용됩니다.

 

SSL 클라이언트 인증 수순

SSL 클라이언트 인증을 할 때에는 사전에 클라이언트에 클라이언트 증명서를 배포하고 인스톨 해둘 필요가 있습니다.

1. 인증이 필요한 리소스의 리퀘스트가 있었을 경우에는 서버는 클라이언트에게 클라이언트 증명서를 요구하는 "Certificate Request"라는 메시지를 송신합니다.
2. 유저는 송신하는 클라이언트 증명서를 선택합니다. 그리고 클라이언트는 클라이언트 증명서를 "Client Certificate"라는 메시지를 송신합니다.
3. 서버는 클라이언트 증명서를 검증하여 검증 결과가 정확하다면 클라이언트의 공개키를 취득합니다. 그 이후에 HTTPS에 의한 암호를 개시합니다.

 

SSL 클라이언트 인증은 2-factor 인증에서 사용

SSL클라이언트 인증은 대부분 폼 베이스 인증과 합쳐서 2-factor 인증의 하나로서 이용되고 있습니다.

 

2-factor 인증

패스워드라는 한 개의 요소만이 아닌 이용자가 가진 다른 정보를 병용해서 인증하는 방법

1. SSL 클라이언트 인증을 사용하여 클라이언트의 컴퓨터를 인증
2. 패스워드를 사용하여 유저의 본인 확인

 

SSL 클라이언트 문제점

클라이언트 증명서를 이용하기 위해서는 많은 비용이 필요합니다.

증명서를 구입하는 비용이나, 서버의 운영자가 자신의 인증 기관을 만들어서 안전하게 운용하기 위해 들어가는 비용이 추가로 필요합니다.

 

[ 폼 베이스 인증 ]

클라이언트가 서버 상의 웹 애플리케이션에 자격 정보(Credential)를 송신하여 그 자격 정보의 검증 결과에 따라 인증하는 방식입니다.

대부분의 경우에는 사전에 등록해 둔 자격 정보인 유저ID, 메일주소 와 패스워드를 입력해서 이것을 웹 애플리케이션측에 송신하고 검증 결과를 토대로 검증 성공 여부를 결정합니다.

 

세션 관리와 쿠키

폼 베이스 인증은 표준적인 사양이 결정되어 있지 않지만 일반적으로 사용되고 있는 방법으로는 세션 관리를 위해서 쿠키를 사용하는 방법이 있습니다.

HTTP는 스테이트리스(stateless)프로토콜 이기 때문에 세션 관리와 쿠키를 사용하여 상태 관리 기능을 보충합니다.

 

1. 자격 정보{유저 ID, 패스워드} (클라이언트 → 서버)
   • 클라이언트와 서버에 유저 ID나 패스워드 등의 자격 정보를 포함한 리퀘스트를 송신합니다.
2. 세션 ID를 쿠키로 송신 (서버 → 클라이언트)
   • 서버 측은 유저를 식별하기 위해 세션 ID를 발행합니다.
   • 클라이언트에서 수신한 자격 정보를 검증하는 것으로 인증을 하고, 그 유저의 인증 상태를 세션 ID와 연관지어 서버 측에 기록합니다.
   • 클라이언트 측에 송신할 때는 Set-Cookie 헤더 필드에 세션 ID를 저장해서 리스폰스를 반환합니다.
3. 쿠키로 세션 ID를 송신 (클라이언트 → 서버)
   • 서버 측에서 세션 ID를 받은 클라이언트는 쿠키로 저장해 둡니다.
   • 다음번에 서버에 리퀘스트를 송신하는 때에는 브라우저가 자동으로 쿠키를 송출하기 때문에 세션 ID가 서버에 송신됩니다.

여기에서 소개한 구현 방법은 어디까지나 하나의 예이기 때문에 다른 방법으로 구현된 것도 있습니다.

 

오늘도 즐거운 하루 되세요!!

참고자료

그림으로 배우는 HTTP&Network Basic