다이제스트 액세스 인증

HTTP
고집 압축 HTTPS 쿼크
요구 방식
옵션들 얻다 머리 포스트. 놓다 삭제 추적하다 연결하다 패치
헤더 필드
쿠키 ETAG 위치 HTTP 레퍼러 DNT X-Forwarded-For
응답 상태 코드
301 영구 이동 302 발견 303 기타 참조 403 금지 404 찾을 수 없음 451 법적 이유로 이용 불가
보안 접근 제어 방법
기본 액세스 인증 다이제스트 액세스 인증
보안 취약성
HTTP 헤더 주입 HTTP 요구 밀수 HTTP 응답 분할 HTTP 파라미터 오염
v t

다이제스트 액세스 인증은 웹 서버가 사용자 이름 또는 비밀번호와 같은 자격 증명을 사용자의 웹 브라우저와 협상하기 위해 사용할 수 있는 합의된 방법 중 하나입니다.온라인 뱅킹 거래 내역 등 중요한 정보를 전송하기 전에 사용자의 신원을 확인하는 데 사용할 수 있습니다.네트워크를 통해 전송하기 전에 사용자 이름과 비밀번호에 해시 함수를 적용합니다.반면 기본 액세스 인증에서는 해시 대신 쉽게 되돌릴 수 있는 Base64 인코딩을 사용하기 때문에 TLS와 함께 사용하지 않는 한 안전하지 않습니다.

기술적으로는 다이제스트 인증은 MD5 암호화 해시를 난스 값을 사용하여 리플레이 공격을 방지하는 애플리케이션입니다.HTTP 프로토콜을 사용합니다.

개요

다이제스트 액세스 인증은 원래 RFC 2069(HTTP로의 확장: 다이제스트액세스 인증)로 지정되어 있습니다.RFC 2069에서는 서버에 의해 생성된 난스 값에 의해 보안이 유지되는 기존 다이제스트 인증 방식을 대략적으로 규정하고 있습니다.인증 응답은 다음과 같이 형성됩니다(HA1 및 HA2는 문자열 변수의 이름입니다).

HA1 = MD5(사용자명:realm:password) HA2 = MD5(메서드:digestURI) 응답 = MD5(HA1:nonce:HA2)

MD5 해시는 16바이트 값입니다.응답 계산에 사용되는HA1 및 HA2 값은 각각 MD5 해시의 16진수 표현(소문자)입니다.

RFC 2069는 이후 RFC 2617(HTTP 인증: 기본 및 다이제스트 액세스 인증).RFC 2617에서는 다이제스트 인증에 대해 Quality of Protection(qop), 클라이언트에 의해 증가하는 난스 카운터 및 클라이언트에 의해 생성되는 랜덤난스 등 다수의 옵션보안 기능이 도입되었습니다.이러한 확장 기능은 예를 들어 선택된 일반 텍스트 공격 암호 분석으로부터 보호하도록 설계되었습니다.

알고리즘 디렉티브의 값이 "MD5" 또는 지정되지 않은 경우 HA1은

HA1 = MD5(사용자명:realm:password)

알고리즘 디렉티브의 값이 「MD5-sess」인 경우, HA1은

HA1 = MD5(MD5(사용자명:realm:password):nonce:cnonce)

qop 디렉티브의 값이 "auth"이거나 지정되지 않은 경우 HA2는

HA2 = MD5(메서드: digestURI)

qop 디렉티브의 값이 "auth-int"인 경우 HA2는

HA2 = MD5(메서드:digestURI:MD5(entityBody))

qop 디렉티브의 값이 "auth" 또는 "auth-int"인 경우 다음과 같이 응답을 계산합니다.

응답 = MD5(HA1:nonce:nonceCount:cnonce:qop:HA2)

qop 디렉티브가 지정되지 않은 경우 다음과 같이 응답을 계산합니다.

응답 = MD5(HA1: 난스:HA2)

위의 내용은 qop이 지정되지 않은 경우 보다 단순한 RFC 2069 표준을 따르는 것을 나타냅니다.

2015년 9월, RFC 7616은 RFC 2617을 대체하여 4개의 새로운 알고리즘(SHA-256, SHA-256-sess, SHA-512-256 및 SHA-512-256-sess)을 추가하였습니다.인코딩은 'MD5' 및 'MD5-sess' 알고리즘과 동등하며 MD5 해시 함수는 SHA-256 및 SHA-512-256으로 대체되었습니다.그러나 2021년 7월 현재 파이어폭스와 ^[2]크롬을 포함한 인기^[1] 브라우저 중 해시 함수로 SHA-256을 지원하는 브라우저는 없습니다.2021년 10월 현재 Firefox^[3] 93은 다이제스트 인증을 위해 공식적으로 "SHA-256" 및 "SHA-256-sess" 알고리즘을 지원합니다.단, 'SHA-512-256', 'SHA-512-256-sess' 알고리즘 및 사용자 이름 해시는 아직 지원되지 않습니다^[4].^[5]

MD5 보안이 다이제스트 인증에 미치는 영향

HTTP 다이제스트 인증에 사용되는 MD5 계산은 "일방향"을 의도하고 있습니다.즉, 출력만 알고 있으면 원래 입력을 판별하기가 어렵습니다.다만, 패스워드 자체가 너무 심플한 경우는, 가능한 모든 입력을 테스트해, 일치하는 출력(블루트 포스 공격)을 찾아낼 수 있습니다.아마도 MD5에서는 사전이나 적절한 룩업 리스트를 이용할 ^[6]수 있습니다.

HTTP 스킴은 1993년 CERN의 Phillip Hallam-Baker에 의해 설계되었으며 키 해시 메시지 인증 코드(HMAC) 개발 등 인증 시스템의 후속 개선 사항은 포함되지 않습니다.사용되는 암호화 구조는 MD5 해시 함수를 기반으로 하지만 2004년 충돌 공격은 보통 일반 텍스트(패스워드 등)^[7]가 불분명한 응용 프로그램에 영향을 주지 않는 것으로 생각되었습니다.다만, 2006년의^[8] 클레임으로 인해, 다른 MD5 애플리케이션에도 의문이 생깁니다.단, 지금까지 MD5 충돌 공격은 다이제스트^{[citation needed]} 인증에 위협이 되지 않는 것으로 판명되어 RFC 2617에서는 서버가 일부 충돌 및 재생 공격을 검출하는 메커니즘을 구현할 수 있습니다.

HTTP 다이제스트 인증 고려 사항

이점

HTTP 다이제스트 인증은 기존의 다이제스트 인증 방식보다 안전하도록 설계되어 있습니다.예를 들어, (예를 들면) CRAM-MD5보다 훨씬 강력합니다.(RFC 2617)

HTTP 다이제스트 인증의 보안 강점은 다음과 같습니다.

• 패스워드는 서버에 클리어 송신되지 않습니다.
• 암호는 다이제스트에 직접 사용되는 것이 아니라 HA1 = MD5(사용자 이름:realm:password)입니다.이것에 의해, 일부의 실장(JBoss등^[9])에서는, 클리어 텍스트 패스워드가 아닌 HA1을 보존할 수 있습니다(단, 이 어프로치의 단점을 참조해 주세요).
• 클라이언트 난스는 RFC 2617에서 도입되었습니다.이것에 의해, 클라이언트는, 인증 스킴을 위협할 가능성이 있는 무지개 테이블등의 선택된 플레인 텍스트 공격을 방지할 수 있습니다.
• 서버 난스에는 타임스탬프를 포함할 수 있습니다.따라서 서버는 재생 공격을 방지하기 위해 클라이언트가 제출한 난스 속성을 검사할 수 있습니다.
• 서버는 재사용을 방지하기 위해 최근에 발행되었거나 사용된 서버 난스 값 목록을 유지할 수도 있습니다.
• 일반 비밀번호는 올바른 서버든 아니든 서버에 전송되지 않기 때문에 피싱을 방지합니다(공개 키 시스템은 사용자가 URL이 올바른지 확인할 수 있어야 합니다).

단점들

다이제스트 액세스 인증에는 몇 가지 단점이 있습니다.

• 웹 사이트에서는 최종 사용자에게 제공되는 사용자 인터페이스를 제어할 수 없습니다.
• RFC 2617의 보안 옵션의 대부분은 옵션입니다.서버에 의해 Quality-of-Protection(qop)이 지정되지 않은 경우 클라이언트는 보안이 낮은 레거시 RFC 2069 모드로 동작합니다.
• 다이제스트 액세스 인증은 man-in-the-middle(MITM) 공격에 취약합니다.예를 들어, MITM 공격자는 클라이언트에 기본 액세스 인증 또는 레거시 RFC2069 다이제스트액세스 인증 모드를 사용하도록 지시할 수 있습니다.이를 더욱 확장하기 위해 다이제스트 액세스 인증은 클라이언트가 서버의 ID를 확인하는 메커니즘을 제공하지 않습니다.
• 서버는 암호 대신 HA1 = MD5(사용자 이름:realm:password)를 저장할 수 있습니다.그러나 저장된 HA1이 유출되면 공격자는 유효한 응답을 생성하고 암호 자체에 액세스할 수 있는 것처럼 쉽게 영역 내의 문서에 액세스할 수 있습니다.따라서 HA1 값 테이블은 일반 텍스트 비밀번호를 포함하는 파일처럼 안전하게 보호되어야 합니다.^[10]
• 다이제스트 액세스 인증을 사용하면 패스워드를 저장할 때 강력한 패스워드 해시(bcrypt 등)를 사용할 수 없습니다(패스워드, 요약 사용자 이름, 레름 및 패스워드는 회복 가능해야 합니다).

또한 FIPS에서는 MD5 알고리즘이 허용되지 않기 때문에 FIPS 인증^{[note 1]} 암호화 모듈에서는 HTTP 다이제스트 인증이 동작하지 않습니다.

대체 인증 프로토콜

지금까지 가장 일반적인 접근방식은 HTTP+를 사용하는 것입니다.HTML 양식 기반 인증 클리어 텍스트 프로토콜 또는 더 드물게 기본 액세스 인증.HTTPS 네트워크 암호화와 함께 사용되는 이러한 취약한 클리어 텍스트 프로토콜은 액세스 인증이 방지하도록 설계된 많은 위협을 해결합니다.단, 이 HTTPS의 사용은 최종 사용자가 매번 올바른 URL에 액세스하고 있는지 정확하게 검증하여 신뢰할 수 없는 서버에 패스워드를 송신하지 않도록 합니다.이것에 의해, 피싱 공격이 발생합니다.사용자가 이를 수행하지 못하는 경우가 많기 때문에 피싱이 보안 침해의 가장 일반적인 형태가 되었습니다.

가끔 사용되는 웹 기반 응용 프로그램의 강력한 인증 프로토콜은 다음과 같습니다.

• 클라이언트 증명서를 사용한 공개 키 인증(통상은 HTTPS/SSL 클라이언트 증명서를 사용해 실장).
• Kerberos 또는 SPNEGO 인증. 예를 들어 Integrated Windows Authentication(IWA; 통합 Windows 인증)용으로 설정된 Microsoft IIS에서 사용됩니다.
• Secure Remote Password Protocol(가능하면 HTTPS/TLS 계층 내).단, 이것은 어떤 메인스트림브라우저에서도 구현되지 않습니다.
• JSON Web Token(JWT)은 JSON 기반의 표준 RFC 7519로, 일정 수의 클레임을 아사트하는 액세스토큰을 작성하기 위한 것입니다.

설명 예

다음 예는 당초 RFC 2617에 기재되어 있으며, 각 요구 및 응답에 대해 예상되는 전문을 표시하기 위해 여기에 확장되어 있습니다.'auth'(인증) 품질 보호 코드만 대상으로 합니다.2005년 4월^[update] 현재 Opera 및 Konqueror 웹 브라우저만이 'auth-int'(정합성 보호를 통한 인증)를 지원하는 것으로 알려져 있습니다.사양에는 HTTP 버전 1.1이 기재되어 있습니다만, 다음과 같이 스킴을 버전 1.0 서버에 정상적으로 추가할 수 있습니다.

이 일반적인 트랜잭션은 다음 단계로 구성됩니다.

1. 클라이언트는 인증이 필요하지만 사용자 이름과 ^{[note 2]}비밀번호를 제공하지 않는 페이지를 요구합니다.일반적으로 이는 사용자가 단순히 주소를 입력하거나 페이지에 대한 링크를 따라 이동했기 때문입니다.
2. 서버는 인증 레름과 랜덤으로 생성된 난스라고 불리는 일회용 값을 제공하는 401 "Unauthorized" 응답 코드로 응답합니다.
3. 이 시점에서 브라우저는 인증 레름(통상은 액세스 하고 있는 컴퓨터 또는 시스템의 설명)을 사용자에게 표시하고, 유저명과 패스워드의 입력을 요구합니다.이 시점에서 사용자가 취소를 결정할 수 있습니다.
4. 유저명과 패스워드가 지정되면, 클라이언트는 같은 요구를 재발송신합니다만, 응답 코드를 포함한 인증 헤더를 추가합니다.
5. 이 예에서는 서버가 인증을 받아들여 페이지가 반환됩니다.사용자 이름이 유효하지 않거나 암호가 올바르지 않은 경우 서버는 "401" 응답 코드를 반환하고 클라이언트는 사용자에게 다시 메시지를 표시합니다.

클라이언트 요구(인증 없음)

얻다 /syslog/index.syslog HTTP/1.0 주인: 로컬 호스트 

(캐리지 리턴과 라인 ^[11]피드 형태로 새로운 라인에 의해 처리됩니다.

서버 응답

HTTP/1.0 401 무허가 서버: HTTPd/0.9 날짜: Sun, 2014년 4월 10일 20:26:47 GMT WWW-Authenticate:다이제스트 영역="testrealm@host.com", qop="auth, auth-int", nonce="dcd98b7102d2f0e8b11d0f600bfb0c093", opaque="5cc069c403ebaf9f0171e9517f40e41" 컨텐츠 유형: 텍스트/내용 길이 153!DOSCTYPE html> <bead> <bead> <bead> <bead charset="UTF-8" /> <title> </title> </head> </head> <h1> 401 미허가.</h1> </body> </body> </body>

클라이언트 요구(사용자명 "Mufasa", 비밀번호 "Circle Of Life")

얻다 /syslog/index.syslog HTTP/1.0 주인: 로컬 호스트 허가: 다이제스트 사용자 이름="Mufasa",                      realm="testrealm@host.com",                      nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",                      uri="/disc/index.disc",                      qop=auth,                      nc=00000001,                      cnonce="0a4f4gb",                      response="6629fae49393a05397450978507c4ef1",                      불투명="5cc069c403ebaf9f0171e9517f40e41" 

(이전처럼 빈 선으로 표시됨).

서버 응답

HTTP/1.0 200 네 알겠습니다 서버: HTTPd/0.9 날짜.: 2005년 4월 10일 (일) 20:27:03 GMT 콘텐츠 타입: 텍스트/메시지 콘텐츠 길이: 7984 

(제한된 페이지의 공백 행과 HTML 텍스트가 뒤에 이어집니다).

"response" 값은 다음과 같이 3단계로 계산됩니다.값이 조합된 경우 콜론으로 구분됩니다.

1. 사용자 이름, 인증 레름 및 패스워드를 조합한 MD5 해시가 계산됩니다.그 결과는 HA1이라고 불립니다.
2. 조합된 메서드와 다이제스트 URI의 MD5 해시가 계산됩니다.예를 들어 다음과 같습니다."GET"그리고."/dir/index.html"그 결과를 HA2라고 부릅니다.
3. 조합된 HA1 결과, 서버 난스(nonce), 요구 카운터(nc), 클라이언트 난스(cnonce), 보호 코드 품질(qop) 및 HA2 결과의 MD5 해시가 계산됩니다.그 결과 클라이언트에 의해 제공되는 "응답" 값이 생성됩니다.

서버는 클라이언트와 동일한 정보를 가지고 있기 때문에 동일한 계산을 수행하여 응답을 확인할 수 있습니다.위에 제시된 예에서 결과는 다음과 같이 형성된다.MD5()는 MD5 해시 계산에 사용되는 함수를 나타내고 백슬래시는 계속을 나타내며 표시된 따옴표는 계산에 사용되지 않습니다.

RFC 2617에 기재되어 있는 예를 실행하면 각 스텝에 대해 다음과 같은 결과가 나타납니다.

HA1 = MD5("Mufasa:testrealm@host.com:Circle Of Life" ) = 939e7578ed9e3c518a452acee763µ9 HA2 = MD5 ("GET:/dir/index.html") = 39aff3a2bab6126f332b96d3366 응답 = MD5 "9" (939e758a)6인치) = 6629fae49393a05397450978507c4ef1

이 시점에서 클라이언트는 서버 난스 값을 재사용하여(서버는 각 "401" 응답에 대해 새로운 난스만 발행함) 새로운 클라이언트 난스(cnonce)를 제공할 수 있습니다.이후 요청의 경우 16진수 요청 카운터(nc)는 마지막으로 사용한 값보다 커야 합니다.그렇지 않으면 공격자가 동일한 자격 증명을 사용하여 오래된 요청을 단순히 "재생"할 수 있습니다.발행한 난스 값마다 카운터가 증가하여 부정한 요구가 적절히 거부되도록 하는 것은 서버에 달려 있습니다.메서드, URI 및 카운터 값을 변경하면 응답 값이 달라집니다.

서버는 최근에 생성한 난스 값을 기억해야 합니다.또한 각 난스 값이 발행된 시점이 기억되고 일정 시간이 경과한 후 기한이 만료될 수도 있습니다.유효기간이 지난 값을 사용할 경우 서버는 "401" 상태 코드로 응답하고stale=TRUE인증 헤더에 접속합니다.이것은, 클라이언트는, 유저에게 다른 유저명과 패스워드의 입력을 요구하지 않고, 새로운 난스를 사용해 재발송신 할 필요가 있는 것을 나타냅니다.

서버는 기한이 지난 난스 값을 유지할 필요가 없습니다.인식되지 않은 값이 기한이 지났다고 가정할 수 있습니다.서버가 각 난스 값을 1회만 반환할 수 있지만, 이로 인해 클라이언트는 모든 요청을 반복해야 합니다.클라이언트가 서버 난스를 사용할 기회가 없기 때문에 서버 난스를 즉시 만료해도 작동하지 않습니다.

.htdigest 파일

.htdigest는 Apache HTTP 서버의 다이제스트 인증을 위한 사용자 이름, 영역 및 암호를 저장하는 데 사용되는 플랫 파일입니다.파일명은 .htaccess Configuration으로 지정되며 어떤 것이든 상관없습니다.단, ".htdigest"가 정식 이름입니다.대부분의 Unix 계열 운영체제는 점으로 시작하는 모든 파일을 숨김으로 간주하기 때문에 파일 이름은 점으로 시작합니다.이 파일은 대부분의 경우 사용자를 추가 및 갱신할 수 있는 셸 명령어 "htdigest"로 유지되며 패스워드를 올바르게 인코딩하여 사용할 수 있습니다.

"htdigest" 명령어는 dpkg 패키지 관리 시스템의 apache2-utils 패키지와 RPM 패키지 관리 시스템의 httpd-tools 패키지에 있습니다.

htdigest ^[12]명령어 구문:

htdigest [ -c ]passwdfile 렐름 사용자 이름

.htdigest ^[12]파일 형식:

user1: Realm: 5ea41921c65387d904834f8403185412 user2:영역: 734418f1e487083dc153890208b79379

SIP 다이제스트 인증

Session Initiation Protocol(SIP)은 기본적으로 동일한 다이제스트 인증 알고리즘을 사용합니다.RFC 3261에 규정되어 있습니다.

브라우저 구현

대부분의 브라우저에서는 auth-int 체크나 MD5-sess 알고리즘 등의 특정 기능을 제외하고 실질적으로 사양을 구현하고 있습니다.서버가 이러한 옵션의 기능을 처리할 필요가 있는 경우, 클라이언트는 인증할 수 없는 경우가 있습니다(단, Apache의 노트 mod_auth_digest는 RFC 2617도 완전하게 실장하고 있지 않습니다).

• 아마야
• 도마뱀붙이 기반: (auth-int^[13] 제외)
  • Mozilla 응용 프로그램 스위트
  • 모질라 파이어폭스
  • 넷스케이프 7+
• iCab 3.0.3+
• KHTML 및 WebKit 기반: (auth-int^[14] 제외)
  • iCab 4
  • 콘쿼러
  • 구글 크롬
  • 사파리
• 태즈먼 기반:
  • Mac용 Internet Explorer
• 트라이던트 베이스:
  • Internet Explorer 5+^[15] (auth-int 제외)
• 프리스토 기반:
  • 오페라
  • Opera 모바일
  • 오페라 미니
  • 닌텐도 DS 브라우저
  • Nokia 770 브라우저
  • Sony Mylo 1의 브라우저
  • Wii 인터넷 채널 브라우저

폐지

다이제스트 인증은 HTTPS를 통한 기본 인증에 비해 단점이 있기 때문에 다음과 같은 많은 소프트웨어에서 사용되지 않습니다.

• 비트버킷: https://bitbucket.org/blog/fare-thee-well-digest-access-authentication
• Symfony PHP 프레임워크: https://github.com/symfony/symfony/issues/24325

「 」를 참조해 주세요.

• AKA(보안)
• JSON Web 토큰(JWT)
• 기본 액세스 인증
• HTTP+HTML 폼베이스 인증

메모들

레퍼런스

외부 링크

• RFC 7235
• RFC 2617(RFC 7235에 의해 갱신)
• RFC 2069 (구식)