18. 다이제스트 인증

다이제스트 인증

• 다이제스트 인증은 기본인증과 호환되는 더 안전한 대체재로서 개발되었다.
• 널리 쓰이지는 않지만, 해당 개념은 보안 트랜잭션을 구현하고자 하는 이들에게 여전히 유용하다.
  • 현재는 잘 사용되어지고 있지는 않다.

다이제스트 인증의 특징

• 기본인증과 달리 해당 정보를 평문으로 보내지 않는다.
• 인증 체결을 가로채서 재현하려는 행위를 차단한다.
• 구현하기에 따라 메시지 내용의 위조를 막는 것도 가능하다.
• 몇몇 알려진 공격들에 대해 방어한다.

비밀번호를 안전하게 지키기위해 요약 사용하기

• 다이제스트 인증은 비밀번호를 절대 네트워크를 통해 보내지 않는다.
• 서버와 클라이언트 모두 비밀번호를 가지고 있고, 해당 비밀번호의 요약문을 전송한다.
  • 이 때, 세상에 모든 비밀번호를 시도해보지 않는이상 원래 비밀번호를 알기 힘들다.
• 동작원리
  • 클라이언트는 서버에 해당 데이터에 대한 요청을 보낸다.
  • 서버는 인증이 완료되기까지 문서 제공을 거부하고 클라이언트에 인증을 요구한다.
  • 클라이언트는 이름과 비밀번호를 입력하고 이를 요약 후 서버에게 보낸다.
  • 모든 사용자를 알고있는 서버는 받아온 요약과 서버가 가지고 있는 요약로직을 사용해 비교한다.
  • 인증이 완료되면 해당 문서를 클라이언트에게 보내준다.

단방향 요약

• 요약함수는 보통 암호 체크섬(crptographic checksums)으로 불린다.
  • 단방향 해시 함수
  • 지문 함수(fingerprint function)
• 일반적으로 입력 가능한 무한 가지의 모든 입력값들을 유한한 범위의 압축으로 변환한다.

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

• 단방향 요약은 비밀번호를 사용하지 않지만, 요약 자체가 비밀번호라고 해도 무방하다. 때문에 비밀번호를 모른다고 하더라도 요약을 가로채 서버로 몇번이고 전송 할 수 있다. 이러한 재전송 공격을 방지하기 위해 서버는 난스(nonce)라고하는 자주 변경(대략 1ms마다 or 인증할 때마다)되는 증표를 건네준다.
• 난스(nonce)를 비밀번호에 섞으면 난스 변경시 요약도 변경되는데 이로 인해 재전송 공격을 막아주게 된다.

다이제스트 인증 핸드셰이크

• 기존 헤더에 몇몇 새 옵션이 추가되었고, 선택 적인 헤더인 Authorization-Info가 추가 되었다.
• 1단계
  • 서버는 난스 값을 계산
• 2단계
  • 서버는 난스를 WWW-Authenticate 인증 요구 메시지에 담아 서버가 지원하는 알고리즘 목록과 함께 클라이언트에 전송한다.
• 3단계
  • 클라이언트는 알고리즘을 선택하고 비밀번호와 그 외 데이터에 대한 요약을 계산한다.
• 4단계
  • 클라이언트는 Authorization 메시지에 요약을 담아 서버에게 보낸다.
  • 만약, 클라이언트가 서버를 인증하길 원한다면 클라이언트 난스(nonce)를 보낼 수 있다.
• 5단계
  • 서버는 요약, 선택한 알고리즘, 그 외 보조 데이터를 받고 클라이언트가 했던 방식으로 요약을 진행한다.
  • 서버는 자신이 요약한 결과와 클라이언트가 보낸 요약을 비교해 일치하는지 확인한다.
  • 서버는 클라이언트가 미리 다음번 요약을 올바르게 생성할 수 있도록 다음번 난스를 미리 계산해서 클라이언트에게 넘겨줄 수도 있다.

---

요약 계산

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

요약 알고리즘 입력 데이터

• 단방향 해시 함수 H(d)
• 요약 함수 KD(s,d)
• s는 비밀(secret)을 의미한다.
• d는 데이터(data)를 의미한다.
• 비밀번호 등 보안 정보를 담고 있는 데이터 덩이리를 A1
• 요청 메시지의 비밀이 아닌 속성을 담고 있는 데이터 덩어리를 A2

H(d)와 KD(s,d) 알고리즘

• 기본값 : MD5
• RF2617에 제안된 알고리즘 : MD5, MD5-sess('sess'는 session을 뜻함)
• 그 외 여러 요약 알고리즘을 지원함

보안 관련 데이터(A1)

• 사용자 이름, 비밀번호, 보호영역, 난스와 같은 비밀 보호 정보로 이루어져 있다.
  • 메시지 자체가 아닌 비밀 정보와만 관련되어 있음을 명확히 이해해야 한다.
  • A1은 H, KD, A2와 마찬가지로 요약을 개산하기 위해 사용된다.

알고리즘	A1
MD5	A1 = <사용자>:<영역>:<비밀번호>
MD5-sess	A1 = MD5(<사용자>:<영역>:<비밀번호>):<난스>:<c난스>

메시지 관련 데이터(A2)

• URL, 요청 메서드(GET, POST, PUT, DELETE, ...), 메시지 엔터티 본문과 같은 메시지 자체의 정보
• 메시지 위조 방지를 위해 사용
• 방법1
  • HTTP 요청 메서드와 URL만 포함하는 것
  • pop="auth"일 때 사용
• 방법2
  • 메시지 무결성 검사를 제공하기 위해 엔티티 본문을 추가하는 것
  • pop="auth-int"일 때 사용
• uri 지시자 값
  • 반드시 요청 URI와 일치해야 한다.
  • URI가 absoluteURL이라면 uri 지시자 값도 반드시 absoluteURL이어야 한다.

qop	A2
정의되지 않음	<요청 메서드>:<uri 지시자 값>
auth	<요청 메서드>:<uri 지시자 값>
auth-int	<요청 메서드>:<uri 지시자 값>:H(<요청 엔터티 본문>)

요약 알고리즘 전반

• 방법1
  • qop옵션이 빠졌을 경우 사용
  • 비밀 정보와 난스가 붙은 메시지 데이터를 해시를 이용해 요약 계산한다.
• 방법2
  • qop옵션이 "auth"와 "auth-int"일 때 모두 사용
  • 난스 횟수, qop, c난스 데이터를 요약에 추가한다.

qop	요약 알고리즘	비고
정의되지 않음	KD(H(H1), <난스>:H(A2))	없어질 예정(Deprecated)
auth or auth-int	KD(H(H1), <난스>:<nc>:<c난스>:<qop>:H(A2))	이 방법을 선호

 

• 예시)

qop	알고리즘	펼쳐진 알고리즘
정의되지 않음	<정의되지 않음> MD5 MD5-sess	MD5(MD5(A1):<난스>:MD5(A2))
auth	<정의되지 않음> MD5 MD5-sess	MD5(MD5(A1):<난스>:<nc>:<c난스>:<qop>:MD5(A2))
auth-int	<정의되지 않음> MD5 MD5-sess	MD5(MD5(A1):<난스>:<nc>:<c난스>:<qop>:MD5(A2))

다이제스트 인증 세션

• WWW-Authenticate 에 대한 클라이언트 응답은 그 보호 공간에 대한 인증 세션을 시작한다.
• 인증 세션은 다른 서버로 부터 또 다른 WWW-Authenticate 인증 요구를 받을 때 까지 지속한다.
• 난스 값이 낡은 것일 수 있음을 감수하고 오래된 Authorization 헤더 정보를 채택할 수 있다. 아니면, 클라이언트가 다시 요청을 보내도록 새 난스 값과 함께 401 응답을 반환할 수도 있다.
  • "stale=true"로 정의하여 서버는 클라이언트에게 새 난스 값으로 요청을 다시 요청

사전(preemptive)인가

• 모든 트랜잭션이 완료되기 전에 요청/인증요구 사이클을 필요로하는데, 클라이언트가 다음 난스가 무엇이 될지 미리 파악하여 요청/인증요구 사이클을 생략하는 방법
• 방법
  • 서버가 다음 난스를 Authentication-Info 성공 헤더에 담아 미리 보내기
    • Authentication-Info: nextnonce="<난스 값>"
  • 서버가 짧은 시간동안 같은 난스를 재사용하는 것을 허용
    • 난스가 만료되면 서버는 401 Unauthorized인증 요구를 보냄
    • WWW-Authenticate는 다음과 같이 설정된다.
    • WWW-Authenticate: Digeset realm="<영역 값>" nonce="<난스 값>" stale=true
    • 해당 기능을 사용하면 재전송 공격이 성공하기 쉬워진다는 점을 고려해야 한다.
  • 클라이언트와 서버가 동기화되어 있고 예측 가능한 난스 생성 알고리즘을 사용
    • ex) 제 3자가 예측할 수 없는 공유된 비밀키에 기반하여 서버와 클라이언트가 동시에 난스를 생성할 수 있도록 시간적으로 동기화된 난스 생성 알고리즘을 사용

난스 선택

• RFC2617은 다음과 같은 가상의 난스 공식을 제안했다.

  BASE64(타임스탬프 H(타임스탬프 ":" ETag ":" 개인 키))

• 타임스탬프는 서버에서 생성된 시간 등 반복 불가능한 값이면 가능
• ETag는 요청된 엔터티에 대한 ETag 헤더값
• 개인키는 서버만이 알고 있는 값
• ETag를 포함하면 갱신된 리소스에 대한 재요청을 방지한다.

상호 인증

• 서버와 클라이언트가 난스와 c난스(Client 난스)를 이용하여 서로 인증하도록 다이제스트 인증을 진행하는 것.
• 응답 요약은 본문 정보(A2)가 다르다는 것을 제외하고는 큰 차이는 없다. 본문 정보(A2)가 다른이유는 응답에는 HTTP Method가 존재하지 않기 때문이다.
• 요청 요약

qop	A2
정의되지 않음	<요청 메서드>:<url 지시자값>
auth	<요청 메서드>:<url 지시자값>
auth-int	<요청 메서드>:<url 지시자값>:H2(<요청 엔터티 본문>)
* 응답 요약

qop	A2
정의되지 않음	:<url 지시자값>
auth	:<url 지시자값>
auth-int	:<url 지시자값>:H(<응답 엔터티 본문>)
* qop="auth"나 qop="auth-int"가 지정된 경우에는 반드시 응답 auth, c난스, 난스 횟수 지시자가 존재해야 한다.

---

보호 수준(Quality of Protection) 향상

• qop필드는 WWW-Authenticate, Authorization, Authentication-Info에 모두 존재 할 수 있다.
• qop필드는 클라이언트와 서버가 어떤 보호기법을 어느 정도 수준으로 사용할 것인지 협상할 수 있게 해주는 것이다.
• 일반적인 인증에는 "auth"를 사용하고 데이터의 무결성이 필요한 경우 "auth-int"를 사용한다.

메시지 무결성 보호

• 무결성 보호 적용시(qop="auth-int") 계산되는 H(엔터티 본문)는, 메시지 본문의 해시가아닌 엔터티 본문의 해시이다.
• 송신자에 의해 전송 인코딩이 적용되기도 전에 먼저 계산되고 그 후 수신자에 의해 제거 된다.
• 멀티파트 경계와 각 파트의 임베딩된 헤더를 포함한다는 것에 주의해야함.
• 멀티파트 경계란?
  • boundaryString을 의미한다.
• 각 파트란?
  • 멀티파트 경계로 구분되어진 영역을 의미
• 멀티파트의 임베딩된 헤더란?
  • 각 파트의 헤더정보

    Content-Type: multipart/form-data; boundary=boundarystring
    

--boundarystring # 멀티파트 경계
Content-Disposition: form-data; name="text" # 멀티파트의 임베딩된 헤더

This is the plain text part
--boundarystring # 멀티파트 경계
Content-Disposition: form-data; name="file"; filename="example.txt" # 멀티파트의 임베딩된 헤더
Content-Type: text/plain # 멀티파트의 임베딩된 헤더

This is the content of example.txt
--boundarystring-- # 멀티파트 경계의 마지막

```

다이제스트 인증 헤더

• 양쪽 모두 WWW-Authenticate헤더 인증 요구와 Authorization인가 응답을 포함한다.
• Authentication-Info는 선택적 헤더이다.

단계	기본인증	다이제스트 인증
인증요구	WWW-Authenticate: Baseic realm="<영역값>"	WWW-Authenticate: Digest realm="<영역 값>" nonce="<난스 값>" [domain="<URI 목록>"] [opaque="<불투명 토큰 값>"] [stale=true or false] [algorithm=<요약 알고리즘>] [qop="<qop 값의 목록>"] [<extension directive>]
응답	Authenticate: Basic <base64(user:pass)>	Authorization: Digest username="<사용자이름>" realm="<영역 값>" nonce="<난스 값>" uri=<요청 uri> response="<16진수 32자리 요약>" [opaque="<불투명 토큰 값>"] [cnonce="<난스 값>"] [cn=<16진수 8자리 난스 개수>] [algorithm=<요약 알고리즘>] [qop="<qop 값의 목록>"] [<extension directive>]
정보	없음	Authentication-Info: nextconce="<난스 값>" [qop="<qop 값의 목록>"] [rspauth="<16진수 요약>"] [cnonce="<난스 값>"] [nc=<>]

---

실제 상황에 대한 고려

다중 인증 요구

• 서버는 한 리소스에 대해 여러 인증을 요구 할 수 있는데, 클라이언트는 반드시 자신이 지원할 수 있는 가장 강력한 인증 메커니즘을 선택해야 한다.

오류처리

• 400 Bad Request : 지시자나 그 값이 적절하지 않거나 요구된 지시자가 빠져 있는 경우의 응답
• 로그인 실패시 실패를 기록하는 것이 좋다. 반복된 실패는 공격자의 시도 일 수 있기 때문이다.
• 서버는 uri지시자가 가리키는 리소스가 요청줄에 명시된 리소스와 같음을 확인해야 한다.
  • 만약 다르다면 400 Bad Request 에러를 반환

보호 공간(Protection Space)(Realm)

• 영역 값
  • 접근한 서버의 루트 URL과 결합되어, 보호 공간을 정의한다.
  • 원 서버에 의해 할당되는 문자
  • 영역은 보호된 리소스를 인증 제도와 인가 데이터베이스 둘 중하나 또는 양쪽 모두를 가진 보호 영역의 집합으로 분할할 수 있게 해준다.
• 보호 공간
  • 어떤 자격이 자동으로 적용되는 영역을 결정한다.
  • 이전 요청이 인가되면, 같은 자격은 인증 제도, 매개변수, 사용자 설정 중 한 가지 이상에 의해 정해진 시간 동안 재사용될 수 있다.
• 기본 인증
  • 요청 URI의 하위 요청은 같은 보호공간으로 간주한다.
• 다이제스트 인증
  • 인증요구의 WWW-Authenticate: domain필드는 보호 공간을 보다 엄밀하게 정의한다.
  • domain필드는 따옴표로 묶인 URI의 공백으로 분리된 목록으로 하위에 위치한 모든 RUI는 같은 보호 공간에 있는 것으로 간주한다.
  • domain필드가 공백이라면 인증을 요구하는 서버의 모든 URI는 그 보호 곤간에 있다는 것.

URI 다시 쓰기

• Proxy는 가리키는 리소스의 변경 없이 구문만 고쳐서 URI를 다시 쓰기도 한다.
  • 호스트명은 정규화되거나 IP주소로 대체될 수 있다.
  • 문자들은 "%" escape 형식으로 대체될 수 있다.
  • 원 서버로부터 가져오는 리소스에 영향을 주지 않는 타입에 대한 추가 속성이 URI의 끝에 붙거나 중간에 삽입될 수 있다.

캐시

• 공유 캐시가 Authorization헤더를 포함한 요청과 그에 대한 응답을 받은 경우 Cache-Control지시자가 응답에 존재하지 않는 한 다른 요청에 대해 그 응답을 반환해서는 안된다.
  • 서버의 응답이 "must-revalidate" Cache-Control지시자를 포함한 경우
    • 서버가 새 요청을 인증할 수 있도록, 해당 요청의 헤더를 이용해 재검사를 수행
  • 서버의 응답이 "public" Cache_Control지시자를 포함한 경우
    • 인증/인가 과정이 필요하지만, 해당 데이터는 cache해도 된다는 것을 의미하여 서버에서 응답하지 않고, cache한 내용을 읽는다.

---

보안에 대한 고려사항

Header 부당 변경

재전송 공격

• 누군가 어떤 트랜잭션에서 엿들은 인증 자격을 다른 트랜잭션을 위해 사용하는 것
• 대부분이 GET요청에 대한 이슈이지만, POST나 PUT요청에 대한 대비도 필수로 가져야 한다.
• 고유한 값(ex. IP주소, 타임스탬프, 리소스의 Etagl, 등)을 이용해 nonce를 생성하는 등 공격자에게 겨대한 난관이 될 수 있게 해야한다. 가능한 매 트랜잭션마다 유일한 nonce값을 사용하는 것은 서버에 부하를 가중시킬 수도 있지만, 사소한 수준일 것이다.

다중 인증 매커니즘

• 서버는 다중 인증 제도를 지원시 WWW-Authenticate 헤더를 통해 선택지를 제공한다.
• 클라이언트는 항상 강력한 인증 제도를 선택해야 할 의무가 없다.
  • 인증의 강도는 선택지 중 가장 약한 것과 같기 때문에 클라이언트는 가능한한 가장 강력한 인증 제도를 선택해 이 문제를 피할 수 있다.
  • 가장 강력한 인증 제도만을 유지하는 프락시 서버를 사용하는 방법도 있다. 단, 모든 클라이언트가 우리가 선택한 강력한 인증 제도를 지원한다고 알려진 경우에만 가능하다.(ex. 사내 네트워크)

사전( dictionary) 공격

• 전형적인 비밀번호 추측 공격
• 공격자가 크래킹하기 어렵도록 상대적으로 복잡한 비밀번호를 사용하는 것과 비밀번호 만료 정책 외에는 실질적으로 대응 방법이 없다.

악의적인 프락시와 중간자 공격(Man in the Middle Attack)

• 대부분 많은 트래픽이 Proxy를 거쳐가는데 Proxy 중 하나가 악의적이거나 보안이 허술하다면 중간자 공격에 취약할 수 밖에 없다. 엿듣기 공격일수도 인증 제도 선택지를 모두 제거하고 가장 취약한 인증 제도로 대체하는 것일 수도 있다.
• 이러한 문제를 해결하기 위해서는 SSL을 사용하는 것이 가장 효과적이다.

선택 평문 공격

• 미리 계산된 사전 공격
  • 사전 공격과 선택 평문 공격의 조합
    • 서버에서 결정난 난스와 자주 쓰이는 비밀번호로 응답 집합을 생성
    • 인코딩된 결과값과 사전에 있는 결과값이 일치하는지를 검사하여 비밀번호를 파악
• 자동화된 무차별 대입 공격
  • 컴퓨터를 동원해 가능한 모든 비밀번호를 열거

비밀번호 저장

• 비밀번호 파일이 평문으로 된 비밀번호를 포함하고 있다고 생각하고 안전하게 보호한다.
• 비밀번호 파일이 유출되더라도 피해를 특정영역으로 국소화 한다.