[HTTP 완벽가이드] 13장 다이제스트 인증

다이제스트 인증은 기본 인증에서 결함을 수정한 인증 방식으로 널리 쓰이지는 않지만, 여전히 유용한 정보이다.

다이제스트 인증이 가장 안전한 프로토콜은 아니다. 하지만 기본 인증 보다는 강력하다.

하지만 안전한 HTTP트렌젝션을 위한 많은 요구사항을 만족하려면, TSL와 HTTPS가 더 적합한 프로토콜이다. 

 

1. 기존 인증보다 나은 개선점

a. 비번을 네트워크 평문으로 보내지 않는다

b. 인증 체결을 가로채는 악의적인 사람을 차단한다 

c. 메시지 내용 위조를 막을 수 있다

d. 알려진 공격을 막을 수 있다

 

1.1 비번 지키미

비번을 네트워크로 보내는 대신, 클라이언트는 비번을 비가역적으로 뒤섞은 '지문' 혹은 '요악'을 보낸다. 클라이언트 & 서버는 둘다 비번을 알고있기 때문에 대응이 가능하기 때문에 이런 작업이 가능하다. 그래서 요약만 주어진 상태에서는 원 비번을 알아내기 어렵게 된다.

 

 

 

 

1.2 단방향 요약

요약은 '정보 본문의 압축'이며, 단방향 함수로 동작한다.

일반적으로 입력 가능한 무한 가지의 모든 입력값을 압축 가능한 범위안에서 요약한다.

인기있는 요약 함수는 MDS가 있는데 임의의 바이트 배열을 원래 길의에 상관 없이 128비트 요약으로 변환한다. 

 

요약이 중요한 이유는, 비번을 모른다면 서버에 보낸 요약을 추측하기 위해서 많은 시간을 사용하게 된다는 것이다. 

즉 단방향 요약은 비번을 그대로 전송해야 할 필요성을 지워준다.

 

1.3 재전송 방지를 위한 난스(nonce) 사용

요약 비번은 그 자체로 비번이기 때문에 요약을 가로채 사용할 수 있기 때문에 문제가 된다.

이런 재전송 공격을 방지하기 위해 서버는 클라이언트에게 난스(1밀리초 마다 또는 인증마다 변경되는 증표)를 건낸다.

난스를 비번에 섞어 난스가 바뀔때 요약도 바뀌게 만들면, 재전송 공격을 막아주는데 저장된 비번 요약은 특정 난스값에 대해서만 유효하기 때문이다.

 

다이제스트 인증은 기존 헤더에 새 옵션이 추가된 버전의 헤더를 사용한다. (ex Authorizatoin-info)

 

2. 요약  계산

다이제스트 인증의 핵심은 공개된 정보, 비밀정보, 시한부 난스 값을 조합한 단방향 요약이다.

MD5 (Message Digest Algorithm 5)
MD5는 해시 함수의 일종으로, 데이터를 입력받아 고정된 크기의 해시 값을 생성하는 알고리즘입니다.
주로 데이터 무결성 검증이나 암호화되지 않은 데이터의 고유 식별자를 생성하는 데 사용됩니다.

MD5-sess
기본 MD5 방식에 세션 ID를 추가하여 보안성을 강화한 방식

 

다이제스트 인증은 여러가지 인증 요약 알고리즘을 선택 할 수 있다. RFC2617에서 제안된 두 알고리즘은 MD5 와 MD5-sess 이고, MD5가 기본 방식이다.

단방향 해시 함수는 데이터의 MD5를 계산하고,

요약함수는 콜론으로 연결된 비밀 데이터와 일반 데이터의 MD5를 계산한다.

 

각각의 알고리즘을 활용한 보안 데이터의 형태

MD5 알고리즘을 사용한 보안 데이터 = <사용자> : <영역> : <비번> 

MD5-sess 알고리즘을 사용한 보안 데이터 = MD5(<사용자> : <영역> : <비번>) : <난스> : <난스> 

 

메시지 관련 데이터의 형태 ( URL, 요청 메서드, 메시지 엔터티 본문과 같은 메시지 자체의 정보를 나타내는 데이터)

qop 가 정의되지 않은 경우 = <요청 메서드> : <uri 지시자 값>

qop 가 auth 인 경우 = <요청 메서드> : <uri 지시자 값>

qop 가 auth-int 인 경우 = <요청 메서드> : <uri 지시자 값> : 단방향 해시 함수(<요청 엔터티 본문>)

 

- 요청 메서드는 HTTP 요청 메서드

- uri 지시자 값은 요청줄에서 가져온 요청 URL로 항상 일치 해야 한다.

 

2.1 다이제스트 인증 세션

인증 세션은 또 다른 보호 공간을 가진 서버로 부터 인증 요구를 받을때 까지 지속된다.

 

일반적인 인증요구는 트렌젝션이 완료되기 전에 요청/인증요구 사이클을 필요로 한다.

만약 클라이언트가 요청 받기 전 Authroizaiton 헤더를 계산할 수 있다면, 클라이언트는 요청/인증요구 단계를 거치지 않고 미리 제공 가능하다. 이것은 성능 개선에 도움을 주며, 사전인가라고 불린다. 

 

2.2 다이제스트 인증에서의 사전 인가

다이제스트 인증에서의 사전인가는 난스가 있어 조금 복잡 하다.

서버는 임의의 난스를 생성하기 때문에 인증요구를 받기 전에는 클라이언트가 올바른 인증 헤더인지 알 방법이 없기 때문이다.

 

이걸 해결하기 위해 여러가지 방법이 있다. 

1. 서버가 다음 난스를 authentication-info 성공 헤더에 담다 미리 보내는 방법

2. 짧은 시간동안 같은 난스 재사용이 가능하도록 허용하는 방법

3. 클라이언트와 서버가 동기화 되어있으며, 예측가능한 난스 생성 알고리즘을 사용하는 방법

 

다음 난스 미리 생성하기 

다음 난스를 미리 생성하는 방식으로 사전인가를 사용하면,

요청/인증요구 사이클에서 벗어날 수있지만, 서버에 다중 요청을 파이프라이닝 하는 능력은 실질적으로 쓸모가 없어진다. 왜냐면 다음 요청을 보내기 전에는 반드시 다음 난스 값을 받아야 하기 때문이다. 

파이프라이닝은 회전 지연 회피를 위한 기술이기 때문에 성능상 불이익은 더 커진다. 

 

제한된 난스 사용

예를 들면 서버는 특정 시간 또는 횟수 동안 재사용을 허락할 수 있다. 

클라이언트는 난스를 미리 알 수있어 요청+인가를 함께해 파이프라닝을 할 수 있다.

 

하지만 난스를 재사용하면 공격이 쉬워져 보안성이 감소된다. 난스 재사용의 수명에 대한 고민이 필요하다. 

카운터 증가, IP주소 검사 등 공격 방어의 기능이 추가적으로 있지만, 취약점 제거는 불가능 하다.

 

동기화된 난스 생성

제 3자가 예측 할 수 없는 공유된 비밀키에 기반해 클라이언트와 서버가 순차적으로 같은 난스를 생성하도록 시간적으로 동기화된 난스 샌성 알고리즘을 사용 할 수있다. 이 알고리즘들은 다이제스트 인증 명세의 범위를 넘어서는 것이다. 

 

2.3 난스 선택

난스의 성능, 보안, 편의성은 사용자가 어떻게 선택하느냐에 따라 달려있다. 

RFC 2617은 가상의 난스 공식을 제안 했는데 

BASE64(타임스탬프 단방향 해시함수 ( 타임스탬프 ":" ETag ":" 개인키))
타임스탬프 : 서버에서 생성된 시간 또는 반복 불가능한 임의의 값
ETag : 요청된 엔터티에 대한 헤더값
개인키 : 서버만이 알고있는 값

 

서버는 클라이언트 인증 헤더를 받은 뒤, 위의 공식에서 해시 부분을 재계산 -> 클라이언트 헤더의 난스와 일치 하지 않거나, 시간이 오래되면 요청을 거절한다 

 

2.4 상호 인증

RFC 2617 클라이언트가 서버를 인증할 수있도록 다이제스트 인증을 확장 했다. 

상호인증은 서버가 authentication-info 헤더를 통해 클라리이언트에게 요약을 전달하는 행위를 의미한다. 

하위호환성을 고려해 선택사항으로 남겨져 있지만, 현대적으로는 반드시 구현해야 한다.

 

 

3. 보호수준(Quality of Protection) 향상

qop 필드는 요약 헤더의 세가지 헤더 ( www-authenticate, authorization, authentication-info) 에 모두 존재 할 수 있다. 

클라이언트와 서버가 어떤 기법을 어떤 수준으로 사용할지 협상 할 수 있게 해준다.

 

예를 들면, 전송속도가 느리더라도, 메시지 본문의 무결성을 검사할 수 있다. 

 

서버는 www-authenticate 헤더에 qop 옵션을 쉼표로 구분된 목록의 형태로 보내면,

클라이언트는 옵션 중 지원할 수 있으면 동시에 자신의 요구에 맞는 것을 선택,

authorization 헤더에 qop 필드를 담아 돌려 보낸다.

 

선택사항으로 이야기 하고있지만 과거와 호환을 위한것이지 현대적인 구현은 qop옵션은 필수로 들어가야 한다.

 

3.1 메시지 무결성 보호

qop = 'auth-int' ( 즉 무결성 보호 )일때, 계산되는 단방향 해시 함수(엔터티 본문)는, 메시지가 아닌, 엔터티 본문의 해시이다.

전송 인코딩이 적용되기도 전에 먼저 계산되고, 수신자에 의해 제거된다.

멀티파트 경계와 각 파의 임베딩된 헤더를 포함 한다는 것에 주의 해야한다. 

 

3.2 다이제스트 인증 헤더

다이제스트 인증은 선택적인 Authentication-Info 헤더를 추가했다. 이 헤더는 3단계 핸드셰이크를 완성하고 다음법 사용할 난스를 전달하기 위해 인증 성공 후에 전송된다.

 

4. 실제 상화에 대한 고려

4.1 다중 인증요구

서버는 한 리소스에 여러 인증을 요구 할 수 있는데, 서버는 기본 및 다이제스트 인증요구 모두를 보내게 될 것이다. 이런 다중 인증 요구에 직면 할때 클라이언트는 자신이 지원가능한 가장 강력한 인증 메커니즘을 선택해야 한다. 

 

4.2 오류 처리 

다이제스트 인증에서 404 bad request인 경우, 로그인이 실패했을 경우를 기록하는 것이 좋다. 왜냐하면 반복된 실패는 공격자가 비번 추측 시도를 하고 있음을 의미하기 때문이다. 

또한 인증 서버는 uri 지시자가 가리키는 리소스가 요청줄에 명시된 리소스와 같은지 확인해야한다.

 

4.3 보호 공간

특정 리소스에 대한 인증 범위를 정의하는 개념으로 리소스와 인증 자격 정보의 연결 범위를 지정한다. 하나의 보호 공간에서는 같은 인증을 사용하는 식으로 이해하면 편하다. 

 

a. 클라이언트(브라우저)는 Protection Space가 동일한 리소스에 대해 인증 정보를 재사용한다. 

b. Protection Space를 통해 특정 리소스에 대한 접근을 제한하고 인증을 요구한다. 

 

4.4 URL 다시 쓰기

프락시는 가리키는 리소스의 변경 없이 구문만 고쳐서 URL을 다시 쓰기도 하는데

- 호스트 명이 정규화되거나, IP주소로 대체 될 수 있다. 

- 문자들은 '%' escape 형식으로 대체될 수 있다.

- 리소스에 영향을 주지 않는 타입에 대한 추가 속성이 URL에 끝이나 중간에 삽입 될 수있다. 

 

프락시가 URl을 변경할 수 있는 동시에, 다이제스트 인증은 URL값의 무결성을 검사하므로, 실패 할 수있다. 

 

4.5 캐시응답

만약 원 서버의 응답이 'must-revalidate' cache-control 을 포함한 경우, 캐시는 응답의 엔터티를 다음 요청에 대한 응답을 위해서 사용 할 것이다.

그러나 원서버가 새 요청을 인증 할 수있도록 요청의 헤더를 이용해 재검사를 수행해야 한다. 

 

만약 원서버의 응답이 public cache-control 을 포함한 경우, 응답 엔터티는 다음에오는 임의의 요청에 대한 응답으로 반환 될 수있다. 

 

5. 보안

RFC 2617 은 http 인증 제도에 내재된 보한 위헙의 일부에 대해 정리했다. 

 

5.1 헤더 부당 변경

헤더 부당 변경에 대한 보안 방식으로는 양 종단 암호화 또는 헤더에 대한 디지털 서명이 필요하다. (두개의 조합이면 더 좋음)

다이제스트 인증은 쉽게 조작 못하는 인증에 초점이 되어있지만, 그 보호가 데이터 까지 확장 하는 것은 아니다.

 

5.2 재전송 공격

누군가가 특정 트랜잭션에서 갈취한 인증 자격을 다른 트랜잭션에서 사용하는 것을 의미한다. 

클라리언트의 IP주소,타임스탬프, 리소스의 ETag, 개인키에 대한 요약을 포함하는 난스를 서버가 생성하도록 하면 문제의 해결책이 된다.

 

하지만 난스 샌성시 클라이언트의 IP주소를 사용하게 되면, 같은 사용자로부터의 요청이 다른 프락시를 통과하게 될 수 도 있는 프락시 팜은 사용 할 수 없게 된다. 그리고 IP를 조작하는게 어려운 일도 아니다.

 

재전송 공격을 피하는데 가장 좋은 방법은 매 트랜잭션 마다 유일한 난스값을 사용하는 것이 좋다. 서버에 부하는 사소한 수준

 

5.3 다중인증 메커니즘

서버가 다중 인증 제도(기본과 요약을 모두 지원한다거나?)를 지원할 때 www-authenticate 헤더를 통해 선택지를 제공 할 것이다. 

클라이언트가 가장 강력한 인증 제도를 선택하는 것이 제일 좋지만 , 의무는 아니기에 

가장 강력한 인증제도만을 유지하는 프락시 서버를 사용하는 것이다. 

 

그치만.. 사내 네트워크 같은 경우에만 실행 가능하다.

 

5.4 사전공격

사전 공격은 전형적인 비번 추측 공격이기 때문에 가장 좋은 해결 방법으 상대적으로 복잡하 비번을 사용하는것,

괜찮은 비번 만료 정책을 사용하는 것 외에는 없다.

 

5.5 악의적인 프락시 & 중간자 공격

프락시 중 하나가 악의적이거나 보안이 허술하다면 클라리언트는 중간자 공격에 취약한 상태가 될 가능성이 있다. 프락시의 신뢰도에 흠집을 낼 수 있는 것은 역설적이게도 프락시 자신의 확장 인터페이스 이다. 

공격을 방어할 유일한 방법은 ssh를 활용하는 것이다. 

 

5.6 선택 평문 공격

다이제스트인증을 사용하는 클라이언트는 응답을 생성하기 위해 서버가 제공한 난스를 사용한다. 보안이 허술하면 클라이언트가 응답계산을 하기 위한 난스를 제공할 수있다. 응답을 계산하기 위해 알려진 키를 사용하는 것은 응답의 암호 해독을 쉽게 한다. ( = 선택적 평문 공격)

 

a. 미리 예상된 사전 공격

사전 공격과 선택적 평문 공격의 조합으로, 공격서버는 미리 결정된 난스와 자주 쓰이는 비번들로 응답의 집합을 생성하고 사전을 만든다. 공격 서버는 트래픽을 차단하고 미리 결정된 난스를 클라이언트로 전송하고, 응답을 받을때 대응되는 항목을 생성된 사전에서 찾고, 대응되는 것이 있다면 특정 사용자의 비번을 얻어낼 수 있게 된다. 

 

b. 자동화된 무차별 대입 공격

많은 컴퓨터를 동원해 주어진 범위에서 가능한 모든 비번을 열거하는 공격이다. 

 

클라이언트가 서버에서 제공된 난스 대신 클라이언트 난스 지시자를 사용해 응답을 생성할 수 있도록 설정하는것과 합쳐서 

강력한 비번은 강제하는 정책과 좋은 비번 만료 메커니즘이 더해지면 위협을 완전 경감시킬 수 있다. 

 

5.7 비번 저장 

다이제스트 인증 비번 파일이 유출 되지 않도록 해야한다.