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

이 장에서는 다이제스트 인증의 이론과 실제에 대해 알아본다

 

---

 

1 . 다이제스트 인증의 개선점

 

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

 

 요약 사용 

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

 

 단방향 요약 

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

 

 난스(nonce) 사용 

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

 

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

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

 

2. 요약 계산

 

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

 

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

 

 보안 관련 데이터 A1 

 

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

 

알고리즘에 따른 A1의 정의

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

 

 메시지 관련 데이터 A2 

 

  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인증요구를 기다리지 않고 올바른 난스를 취할 수 있는 방법이 몇 가지 있다

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

 난스 선택 

 

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

 

 상호 인증 

 

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

 

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

 

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

 

 메시지 무결성 보호 

 

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

 

 다이제스트 인증 헤더 

 

4. 실제 상황에 대한 고려

 

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

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

 

5. 보안에 대한 고려사항

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

 

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