Digest

다이제스트 인증의 개선점

다이제스트 인증은 널리 쓰이고 있지는 않다. 그러나 기본 인증에 내재된 보안 위험 때문에, HTTP 설계자들은 RFC2617에서 "기본 인증을 사용하는 오늘날의 모든 서비스는 가능한 한 다이제스트 인증으로 전환해야 한다" 고 조언하고 있다.

요약 사용

- 비밀번호를 보내는 다신, 클라이언트는 비밀번호를 비가역적으로 뒤섞은 '지문' 혹은 '요약'을 보낸다.
- 클라이언트와 서버는 둘다 비밀번호를 알고 있으므로, 서버는 클라이언트가 보낸 요약이 비밀번호와 알맞게 대응하는지 검사할 수 있다.
- 요약 함수는 매우 긴 자릿수의 숫자를 만들어내기 때문에, 찍어서 맞추는 것은 불가능하다

단방향 요약

- 요약 함수 중 하나인 MD5는 임의의 바이트 배열을 원래 길이와 상관없이 128비트 요약으로 변환한다
- 128비트의 MD5출력은 32글자의 16진수 문자로 표현되며, 각 문자는 각각 4비트의 값을 의미한다
- 요약 함수는 보통 암호 체크섬으로 불리며, 단방향 해시함수이거나 지문함수이다

난스(nonce) 사용

- 비밀번호를 몰라도 비밀번호 요약을 가로채 계속해서 공격하는 재전송 공격을 막기 위해 만들어졌다
- 서버는 클라이언트에게 난스라고 불리는 증표를 건네준다
- 컴퓨터 보안 측면을 고려해서, 난스의 계산식은 현재 시각을 포함한다
- 클라이언트는 받은 난스를 비밀번호와 섞는다. 때문에 요약도 바뀌어서 보내지게 된다0 

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

- 서버가 난스 값을 생성한다.
- 서버는 난스를 WWW-Authenticate 인증요구 메시지에 담아, 서버가 지원하는 알고리즘 목록과 함께 클라이언트에 전송한다 (영역, 난스, 알고리즘을 보낸다)
- 클라이언트는 알고리즘을 선택하고 비밀번호를 가지고 요약을 생성한다.
- 클라이언트는 Authrizatioin 메시지에 요약을 담아서 서버에게 보낸다. (요약, 선택한 알고리즘 + 서버도 인증하길 원한다면 클라이언트 난스)
- 서버는 클라이언트가 한것처럼 요약을 계산해서 클라이언트의 요약과 서버의 요약이 같은지 확인한다.
- 만약 클라이언트가 난스를 보내 인증을 요구하면 서버는 클라이언트에게 보낼 요약을 만든다. 또한 서버도 클라이언트에게 보낼 난스를 미리 만들어 넘겨줄 수 있다. 

요약 계산

 H(d)와 KD(s,d) 알고리즘
 H(d) : 단방향 해시 함수
 KD(s,d) : 요약 함수. s는 비밀(secret)를, d는 데이터(data)를 말한다
 H(<데이터>) = MD5(<데이터>)
 KD(<비밀>,<데이터>) = H(연결(<비밀>:<데이터>)) 

사용자 이름, 비밀번호, 보호영역, 난스와 같은 비밀 보호 정보 덩어리

A1의 정의

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

URL, 요청 메서드, 메시지 엔터티 본문과 같은 메시지 자체의 정보를 나타낸다

A2의 정의

qop	A1
정의되지 않음	<요청메서드>:<url 지시자 값>
auth	<요청메서드>:<url 지시자 값>
auth_int	<요청메서드>:<url 지시자 값>:H(<요청 엔터티 본문>)

차트 시트

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

사전(preemptive) 인가

만약 클라이언트가 다음 난스가 무엇이 될지 미리 알고 있어서, 서버가 물어보기 전에 올바른 Authorization 헤더를 생성할 수 있다면, 이 요청/인증요구 사이클은 생략할 수 있다.

클라이언트가 새 WWW-Authenticate인증요구를 기다리지 않고 올바른 난스를 취할 수 있는 방법이 몇 가지 있다

- 서버가 다음 난스를 Authentication-Info 성공 헤더에 담아서 미리 보낸다
- 서버가 짧은 시간 동안 같은 난스를 재사용하는것을 허용한다
- 클라이언트가 서버가 동기화되어 있고 예측 가능한 난스 생성 알고리즘을  사용한다

RFC 2417이 제안한 난스 공식 :BASE64(타임스탬프":"ETag":"개인 키))

상호 인증

RFC 2417은 클라이언트가 서버를 인증할 수 있도록 다이제스트 인증을 확장했다.
서버가 공유된 비밀 정보에 근거한 올바린 응답 요약을 생성할 수 있도록, 클라이언트 난스(c난스) 값을 제공하여 가능해진다
이후 서버는 이 요약을 Authentication-Info 헤더를 통해 클라이언트에 전달한다.

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

서버는 우선 WWW-Authenicate헤더에 qop옵션을 쉼표로 구분된 목록 형태로 내보낸다. 그 후 클라이언트는 그 옵션들 중 지원할 수 있으면서 동시에 자신의 요구에도 맞는 것을 선택하고, 그것을 Authentization헤더의 qop필드에 담아 돌려준다 RFC 2617은 기본저으로 두 가지 초기 보호수준 값을 정의하고 있다. 하나는 인증을 의미하는 "auth"이고 다른 하나는 인증 및 메시지 무결성 보호를 의미하는 "auth-int"이다

메시지 무결성 보호

무결성 보호가 적용되었을 때 (qop="auth-int") 계산되는 H(엔터티 본문)는, 메시지 본문의 해시가 아닌 엔터티 본문의 해시이다. 이것은 송신자에 의해 어떠한 전송 인코딩이 적용되기도 전에 먼저 계산되고 그 후 수신자에 의해 제거된다.

실제 상황에 대한 고려

다이제스트 인증 작업을 할 때 고려해야 할 것 이 몇 가지 있다.

다중 인증요구 - 서버는 한 리소스에 대해 여러 인증을 요구 할 수 있다.
오류 처리 - 인증이 적절하지 않았을 때는 400 Bad Request를 반환하며, 로그로 기록하는것이 좋다.
보호 공간(Protection Space) - 기본인증에서, 클라이언트는 요청 URL와 그 하위의 모든 경로는 같은 보호 공간에 있는 것으로 가정한다.
URL 다시 쓰기 - 프락시는 가리키는 리소스의 변경 없이 구문만 고쳐서 URL을 다시 쓰기도 한다. 다이제스트 인증은 이러한 변경으로 실패할 수 있다.
캐시 - 어떤 공유 캐시가 Authotization 헤더를 포함한 요청과 그에 대해 응답을 받은 경우, 두 Cache-Control 지시자 중 하나가 응답에 존재하지 않는 다른 요청에 대해 그 응답을 반환해서는 안된다.

보안에 대한 고려사항

RFC 2617은 HTTP 인증 제도에 내제된 보안 위협의 일부를 정리하는 일을 해냈다. 그중 몇 가지를 설명한다.

0재전송 공격 - 재전송 공격을 완전히 피할 수 있는 한 방법은 매 트랜잭션마다 유일한 난스 값을 사용하는 것이다
다중 인증 메커니즘 - 클라이언트가 언제나 가능한 한 가장 강력한 인증 제도를 선택하도록 해야 한다
사전(dictionary) 공격 - 크래킹하기 어렵도록 상대적으로 복잡한 비밀번호를 사용한다
악의적인 프락시와 중간자 공격(Man-in-the-Middle Attack) - SSL을 사용한다
선택 평문 공격 - 클라이언트가 서버에서 제공된 난스 대신 선택적인 c난스 지시자를 사용하여 응답을 생성할 수 있도록 한다.
비밀번호 저장 - 영역 이름이 유일함을 보장하며, 비밀번호 파일이 유출되더라도 피해를 특정 영역으로 국소화한다.