3. 동작 방식

다이제스트 인증은 클라이언트와 서버 간의 "챌린지-응답" 방식으로 동작한다. 클라이언트가 인증이 필요한 리소스를 요청하면, 서버는 401 Unauthorized 응답과 함께 챌린지(영역(realm), nonce 등 포함)를 보낸다. 클라이언트는 사용자 이름, 비밀번호, 챌린지 값을 이용하여 응답(response)을 생성하고, 이를 서버에 전송한다. 서버는 자신이 가진 정보와 클라이언트가 보낸 응답을 비교하여 인증 성공 여부를 결정한다.^[14]

일반적인 다이제스트 인증 과정은 다음과 같다.

1. 클라이언트 요청 (인증 정보 없음): 클라이언트가 인증이 필요한 페이지를 요청한다. (일반적으로 사용자 이름과 비밀번호는 보내지 않음)

2. 서버 응답 (401 Unauthorized): 서버는 401 "Unauthorized" 응답 코드로 응답하고, 인증 영역(realm)과 nonce를 클라이언트에게 제공한다.

3. 클라이언트 사용자 인증: 브라우저는 사용자에게 인증 영역을 표시하고, 사용자 이름과 비밀번호를 입력받는다. (사용자는 이 단계에서 인증을 취소할 수 있다.)

4. 클라이언트 요청 (인증 정보 포함): 사용자 이름과 비밀번호가 입력되면, 클라이언트는 응답 코드를 포함한 인증 헤더를 추가하여 동일한 요청을 다시 서버에 보낸다.

5. 서버 응답 (인증 성공 또는 실패): 서버는 클라이언트가 보낸 인증 정보를 확인한다. 인증에 성공하면 페이지를 반환하고, 실패하면 다시 401 응답 코드를 반환한다.

RFC 2617에 제시된 예시를 기반으로, "auth"(인증) 보호 품질 코드를 사용하는 일반적인 트랜잭션은 다음과 같다.

; 클라이언트 요청 (인증 없음):

```http

GET /dir/index.html HTTP/1.0

Host: localhost

```

(개행 문자, 캐리지 리턴 뒤에 줄 바꿈이 온다).^[15]

; 서버 응답:

```http

HTTP/1.0 401 Unauthorized

Server: HTTPd/0.9

Date: Sun, 10 Apr 2014 20:26:47 GMT

WWW-Authenticate: Digest realm="testrealm@host.com",

qop="auth,auth-int",

nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",

opaque="5ccc069c403ebaf9f0171e9517f40e41"

Content-Type: text/html

Content-Length: 153

401 Unauthorized.

3. 1. RFC 2617 (MD5)

• algorithm="MD5" (또는 미지정): HA1 = MD5(사용자 이름:영역:비밀번호)
• algorithm="MD5-sess": HA1 = MD5(MD5(사용자 이름:영역:비밀번호):논스:cnonce)

• qop="auth" (또는 미지정): HA2 = MD5(메서드:다이제스트URI)
• qop="auth-int": HA2 = MD5(메서드:다이제스트URI:MD5(entityBody))

• qop="auth" 또는 "auth-int": 응답 = MD5(HA1:논스:논스카운트:cnonce:qop:HA2)
• qop 미지정: 응답 = MD5(HA1:논스:HA2) (RFC 2069 방식)

3. 1. 1. 기본 계산

• HA1 = MD5(사용자 이름:영역:비밀번호)
• HA2 = MD5(메서드:다이제스트URI)
• 응답 = MD5(HA1:논스:HA2)

• algorithm="MD5" (또는 미지정): HA1 = MD5(사용자 이름:영역:비밀번호)
• algorithm="MD5-sess": HA1 = MD5(MD5(사용자 이름:영역:비밀번호):논스:cnonce)

• qop="auth" (또는 미지정): HA2 = MD5(메서드:다이제스트URI)
• qop="auth-int": HA2 = MD5(메서드:다이제스트URI:MD5(entityBody))

• qop="auth" 또는 "auth-int": 응답 = MD5(HA1:논스:논스카운트:cnonce:qop:HA2)
• qop 미지정: 응답 = MD5(HA1:논스:HA2) (RFC 2069 방식)

3. 1. 2. qop (보호 품질) 사용 시

• HA1: 사용자 이름, 영역(realm), 비밀번호를 조합한 MD5 해시값이다.
• 논스(nonce): 서버에서 생성한 임의의 값이다.
• 논스카운트(nc): 클라이언트가 생성한 논스 카운터 값.
• cnonce: 클라이언트에서 생성한 임의의 논스 값.
• qop: 보호 품질(quality of protection) 값 ("auth" 또는 "auth-int").
• HA2: 메서드와 다이제스트 URI를 조합한 MD5 해시값.

• HA1 = MD5( "Mufasa:testrealm@host.com:Circle Of Life" ) = 939e7578ed9e3c518a452acee763bce9
• HA2 = MD5( "GET:/dir/index.html" ) = 39aff3a2bab6126f332b942af96d3366
• 응답 = MD5( "939e7578ed9e3c518a452acee763bce9:dcd98b7102dd2f0e8b11d0f600bfb0c093:00000001:0a4f113b:auth:39aff3a2bab6126f332b942af96d3366" ) = 6629fae49393a05397450978507c4ef1

3. 1. 3. MD5-sess 알고리즘

3. 2. RFC 7616 (SHA-256, SHA-512-256)

4. 보안 고려 사항

HTTP 다이제스트 인증은 MD5를 이용한 단방향 함수를 사용하므로, 출력값만으로는 원래 입력을 알아내기 어렵다. 그러나 암호가 단순하면 무차별 대입 공격(사전 공격, 레인보우 테이블 등을 이용)으로 모든 입력을 대조해 일치하는 출력을 찾을 수 있다.<sup>[8]</sup>

HTTP 방식은 1993년 CERN의 필립 핼럼-베이커가 설계했으며, HMAC 같은 후속 개선 사항은 반영되지 않았다. 암호화에 MD5 해시 함수가 사용되지만, 2004년에는 충돌 공격이 암호가 알려지지 않은 경우에 영향을 주지 않는다고 여겨졌다.<sup>[9]</sup> 그러나 2006년에 다른 MD5 응용에도 의문이 제기되었다.<sup>[10]</sup>

4. 1. 장점

• 보안 강화:
• 비밀번호가 서버로 평문으로 전송되지 않는다.
• 비밀번호는 다이제스트에 직접 사용되지 않고, `HA1 = MD5(사용자 이름:영역:비밀번호)` 형태로 사용된다.
• RFC 2617에 클라이언트 논스가 도입되어, 선택 평문 공격을 방지한다.
• 서버 논스는 타임스탬프를 포함하여, 재전송 공격을 방지한다.
• 일반 비밀번호가 어떤 서버로도 전송되지 않기 때문에 피싱을 방지한다.

4. 2. 단점

• 웹사이트는 최종 사용자에게 제시되는 사용자 인터페이스를 제어할 수 없다.<sup>[12]</sup>
• RFC 2617의 많은 보안 옵션은 선택 사항이다. 서버에서 품질 보호(qop)를 지정하지 않으면 클라이언트는 보안이 저하된 레거시 RFC 2069 모드로 작동한다.<sup>[12]</sup>
• 다이제스트 액세스 인증은 중간자(MITM) 공격에 취약하다. 예를 들어, 공격자는 클라이언트에게 기본 액세스 인증 또는 레거시 RFC 2069 다이제스트 액세스 인증 모드를 사용하도록 지시할 수 있다. 또한, 다이제스트 액세스 인증은 클라이언트가 서버의 신원을 확인할 수 있는 메커니즘을 제공하지 않는다.<sup>[12]</sup>
• 서버는 비밀번호 자체 대신 HA1 = MD5(사용자 이름:영역:비밀번호)를 저장할 수 있다. 그러나 저장된 HA1이 유출되면 공격자는 유효한 응답을 생성하고 비밀번호에 액세스하는 것만큼 쉽게 영역 내 문서에 액세스할 수 있다. 따라서 HA1 값은 일반 텍스트 비밀번호가 포함된 파일만큼 안전하게 보호되어야 한다.<sup>[12]</sup>
• 다이제스트 액세스 인증은 비밀번호를 저장할 때 bcrypt와 같은 강력한 비밀번호 해시의 사용을 방지한다. (비밀번호 또는 다이제스트된 사용자 이름, 영역 및 비밀번호를 복구할 수 있어야 하므로).<sup>[12]</sup>
• MD5 알고리즘은 FIPS에서 허용되지 않으므로, HTTP 다이제스트 인증은 FIPS 인증 암호화 모듈과 함께 작동하지 않는다.<sup>[13]</sup>

5. 구현

아파치 HTTP 서버에서는 `.htdigest` 파일을 이용하여 다이제스트 인증을 설정할 수 있다.<sup>[16]</sup> 이 파일은 사용자 이름, 영역, 비밀번호를 저장하는 플랫 파일이다.<sup>[16]</sup> 파일 이름은 `.htaccess` 구성에 지정되며, ".htdigest"가 표준 이름이다.<sup>[16]</sup> 대부분의 유닉스 계열 운영 체제에서 점(.)으로 시작하는 파일은 숨겨진 파일로 간주되기 때문에, 파일 이름은 점으로 시작한다.<sup>[16]</sup>

`.htdigest` 파일은 `htdigest` 셸 명령으로 관리되며, 사용자를 추가/업데이트하고 비밀번호를 올바르게 인코딩한다.<sup>[16]</sup> `htdigest` 명령은 dpkg의 '''apache2-utils''' 패키지, RPM의 '''httpd-tools''' 패키지에서 찾을 수 있다.<sup>[16]</sup>

`.htdigest` 파일의 형식은 다음과 같다.<sup>[16]</sup>

```text

user1:Realm:5ea41921c65387d904834f8403185412

user2:Realm:734418f1e487083dc153890208b79379

```

대부분의 웹 브라우저에서 다이제스트 인증을 지원한다. 다만, 일부 기능(예: `auth-int`, `MD5-sess` 알고리즘)은 지원되지 않을 수 있다. 다음은 다이제스트 인증을 지원하는 브라우저 목록이다.^{[17][18][19][20]}

• 아마야
• 게코 기반:
• 모질라 애플리케이션 스위트
• 모질라 파이어폭스
• 넷스케이프 7+
• iCab 3.0.3+
• KHTML 및 WebKit 기반:
• iCab 4
• Konqueror
• 구글 크롬
• 사파리
• 태즈먼 기반:
• 인터넷 익스플로러 for Mac
• 트라이던트 기반:
• 인터넷 익스플로러 5+
• 프레스토 기반:
• 오페라
• 오페라 모바일
• 오페라 미니
• 닌텐도 DS 브라우저
• 노키아 770 브라우저
• 소니 마일로 1의 브라우저
• Wii 인터넷 채널 브라우저

6. 다른 인증 프로토콜과의 비교

HTTPS를 통한 기본 인증은 HTTPS 네트워크 암호화를 사용하여 다이제스트 액세스 인증이 방지하도록 설계된 많은 위협을 해결한다. 그러나 HTTPS를 사용하더라도 최종 사용자가 자신의 암호를 신뢰할 수 없는 서버로 전송하는 것을 막기 위해 매번 올바른 URL에 접속하는지 확인해야 하므로, 피싱 공격에는 여전히 취약하다.^[8] 사용자가 이 작업을 제대로 수행하지 못하는 경우가 많아 피싱은 가장 흔한 형태의 보안 침해 중 하나가 되었다.^[8]

웹 기반 응용 프로그램에서 사용되는 강력한 인증 프로토콜은 다음과 같다.

• 공개 키 인증 (일반적으로 HTTPS / SSL 클라이언트 인증서를 사용)
• Kerberos 또는 SPNEGO 인증 (예: 통합 윈도우 인증 (IWA)으로 구성된 마이크로소프트 IIS에서 사용)
• Secure Remote Password 프로토콜 ( HTTPS / TLS 계층 내에서 사용 권장). 그러나 주요 브라우저에서는 구현되지 않았다.
• JSON 웹 토큰 (JWT) - JSON 기반 표준 RFC 7519. 일부 클레임을 어설션하는 액세스 토큰 생성을 위함.

참조

_[1] 문서 Moving DIGEST-MD5 to Historic, July 2011 https://datatracker.[...] 2011-07
_[2] 웹사이트 Bug 472823: SHA 256 Digest Authentication https://bugzilla.moz[...]
_[3] 웹사이트 Issue 1160478: SHA-256 for HTTP Digest Access Authentication in accordance with rfc7616 https://bugs.chromiu[...]
_[4] 웹사이트 Bug 472823: SHA 256 Digest Authentication https://bugzilla.moz[...]
_[5] 뉴스 IETF.org: RFC 7616 Username Hashing https://datatracker.[...] 2015-09-30
_[6] 웹사이트 Mozilla-central: support SHA-256 HTTP Digest auth https://hg.mozilla.o[...]
_[7] 웹사이트 Chrome Feature: RFC 7616 Digest auth: Support SHA-256 and username hashing https://chromestatus[...]
_[8] 문서 List of rainbow tables, Project Rainbowcrack http://project-rainb[...]
_[9] 웹사이트 Hash Collision Q&A http://www.cryptogra[...] Cryptography Research 2005-02-16
_[10] 웹사이트 On the Security of HMAC and NMAC Based on HAVAL, MD4, MD5, SHA-0 and SHA-1 https://eprint.iacr.[...] IACR
_[11] 웹사이트 DIGEST Authentication (4.0.4+) https://web.archive.[...] JBoss 2013-03-04
_[12] 간행물 HTTP Authentication: Basic and Digest Access Authentication: Storing passwords https://tools.ietf.o[...] IETF 1999-06
_[13] 웹사이트 Annex A: Approved Security Functions for FIPS PUB 140-2, Security Requirements for Cryptographic Modules http://csrc.nist.gov[...] National Institute of Standards and Technology 2014-01-31
_[14] 문서
_[15] 웹사이트 Hypertext Transfer Protocol -- HTTP/1.0: Request http://www.w3.org/Pr[...] W3C 1996-02-19
_[16] 웹사이트 htdigest - manage user files for digest authentication http://httpd.apache.[...]
_[17] 웹사이트 Bug 168942 - Digest authentication with integrity protection https://bugzilla.moz[...] 2002-09-16
_[18] 웹사이트 HTTP Digest Integrity: Another look, in light of recent attacks https://secure.vsecu[...] vsecurity.com 2010-01-05
_[19] 웹사이트 TechNet Digest Authentication https://technet.micr[...] 2013-08
_[20] 웹사이트 Opera admits defeat, switches to Google's Chromium https://www.extremet[...] Ziff Davis 2024-01-19
_[21] 문서 Moving DIGEST-MD5 to Historic, July 2011 https://datatracker.[...] 2011-07