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

이 내용은 http 완변 가이드란 책을 읽고 정리한 내용입니다.

 

더 자세한 내용이 궁금하시면 책을 직접 읽어보시는 걸 추천합니다.

 

 

13장 다이제스트 인증

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

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

• 다이제스트 인증 특징
  • 비밀번호를 네트워크를 통해 평문으로 전송하지 않는다.
  • 인증 체결을 가로채서 재현하려는 악의적인 사람들을 차단한다.
  • 구현에 따라 메시지 내용 위조를 막을 수 있다.
  • 몇몇 잘 알려진 형태의 공격을 막는다.
• TLS와 HTTPS보다 안전한 프로토콜이라 볼 수는 없다.

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

• 다이제스트 인증에서 가장 중요한 것은 비밀번호를 네트워크를 통해 보내지 않는 것이다.
• 비밀번호를 보내는 대신에 클라이언트는 비밀번호를 비가역적으로 뒤섞은 fingerprint(지문) 또는 digest(요약)을 보낸다.
• 클라이언트와 서버는 둘다 비밀번호를 알고 있으므로, 서버는 클라이언트가 보낸 요약이 비밀번호와 알맞게 대응하는지 검사할 수 있다.
• 요약 함수는 매우 긴 자릿수의 숫자를 만들어내기 때문에, 찍어서 맞추는 것은 불가능하다

1.2 단방향 요약

• MD5는 인기 있는 요약 함수이다.
  • 요약 함수 중 하나인 MD5는 임의의 바이트 배열을 원래 길이와 상관없이 128비트 요약으로 변환한다
• 요약은 단방향 함수로 동작하고, 일반적으로 입력 가능한 무한 가지의 모든 입력값들을 유한한 범위의 압축으로 변환한다
• 요약함수는 보통 암호 체크섬이라고 불리고, 단방향 해시 함수이거나 지문 함수(fingerprint function)이다.

1.3 재전송 방지를 위한 nonce 사용

• 요약을 가로채서 서버로 재전송하는 재전송 공격을 방지하기 위해 서버가 클라이언트에게 난스를 건네준다.
• 서버는 클라이언트에게 난스라고 불리는 특별한, 그리고 자주 바뀌는 증표를 건네준다.
  • 난스를 비밀번호에 섞으면 난스가 바뀔 때마다 요약도 바뀌게 만들어준다. 이것은 재전송 공격을 막아준다.
• 난스는 WWW-Authenticate 인증요구에 담겨서 서버에서 클라이언트로 넘겨진다.

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

• 기본 인증에서 사용하는 것과 비슷한 헤더를 사용하는 강화된 버전의 인증이다.
• 기존 헤더에 몇몇 새 옵션이 추가되었고, 선택적인 헤더인 Authorization-Info가 새로 추가되었다.
• 단순한 과정

1. 서버가 난스를 생성한다.
2. 서버가 영역(realm), 난스, 알고리즘을 보낸다. (인증 요구)
3. 알고리즘을 선택하고 응답 요약을 생성한다.
4. 클라이언트가 요약을 담아서 서버에게 돌려준다. 만약 클라이언트가 서버 인증을 원한다면 클라이언트 난스를 생성하여 함께 보낼 수도 있다.
5. 서버는 클라이언트가 했던 그대로 요약을 계산한 다음 자신이 계산한 요약과 네트워크로 전송되어 온 요약이 일치하는지 확인한다. 만약에 클라이언트가 대칭적으로 서버에게 클라이언트 난스를 가지고 인증을 요구했다면, 클라이언트 요약이 만들어진다.

2 요약 계산

2.1 요약 알고리즘 입력 데이터

요약은 다음의 세 요소로부터 계산된다.

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

2.3 보안 관련 데이터(A1)

• A1은 사용자 이름, 비밀번호, 보호 영역, 난스와 같은 비밀 보호 정보로 이루어진 데이터 덩어리이다. (비밀 정보와만 관련)

알고리즘 A1

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

2.4 메시지 관련 데이터(A2)

• A2는 URL, 요청 메서드, 메시지 엔터티 본문과 같은 메시지 자체의 정보를 나타낸다.
• 메서드, 리소스, 메시지의 위조를 방지하기 위해 사용된다.

qop A1

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

2.5 요약 알고리즘 전반

H, KD, A1, A2를 사용해서 다이제스트를 산출한다.

qop 알고리즘 펼쳐진 알고리즘

정의되지 않음	<정의되지 않음>MD5MD5-sess	MD5(MD5(A1):<난스>:MD5(A2))
auth	<정의되지 않음>MD5MD5-sess	MD5(MD5(A1):<난스>:<nc>:<난스>:<qop>:MD5(A2))
auth_int	<정의되지 않음>MD5MD5-sess	MD5(MD5(A1):<난스>:<nc>:<난스>:<qop>:MD5(A2))

2.6 다이제스트 인증 세션

• 어떤 보호 공간(protection space)을 위한 WWW-Authenticate 인증요구에 대한 클라의 응답은, 그 보호 공간에 대한 인증 세션을 시작하게 함.보호 공간은 접근 중인 서버의 루트와 영역(realm)의 결합으로 정의됨.
• 인증 세션은 클라가 보호 공간의 다른 서버로부터 또 다른 WWW-Authenticate 인증요구를 받을 때까지 지속됨.
• 클라는 사용자 이름, 비밀번호, 난스, 난스 횟수(nc), 그리고 보호 공간 내 미래의 요청에 들어갈 Authorization 헤더를 만들기 위해 사용될 인증 세션과 연관된 알아보기 힘든 값들을 기억해야 함.
• 난스가 만료되면, 서버는 난스 값이 낡은 것임을 감수하고 오래된 Authorizastion 헤더 정보를 받아들이는 것을 택할 수 있음.
• 아니면, 서버는 클라가 다시 요청을 보내도록 새 난스 값과 401을 반환할 수 있음. 이때 이 응답에 stale=true로 정의하여 서버는 클라에게 사용자 이름과 비밀번호를 새로 입력할 필요가 없게 함.

2.7 사전(preemptive) 인가

• 클라이언트가 새 WWW-Authentication 인증 요구를 기다리지 않고 올바른 난스를 취득할 수 있는 방법
  • 다음 난스 미리 생성하기Authentication-Info 성공 헤더에 다음 난스 값을 실어서 보낸다.
    • 장점 : 사전 인가를 통해 요청/인증요구 사이클을 생략함으로써 트랜잭션 속도 향상
    • 단점 : 파이프라이닝이 쓸모 없어져(다음 요청 보내기 전에 반드시 다음 난스 값을 받아야 하므로 응답 올 때까지 기다려) 오히려 회전 지연으로 인한 성능상 불이익
  • 제한된 난스 재사용"난스를 10초동안 or 5번 재사용 허용" 이런 식으로 난스를 제한적으로 재사용한다.
    • 장점 : 클라이언트가 난스를 미리 알 수 있고, 응답과 관련 없어지므로 파이프라이닝을 할 수 있다.
    • 단점 : 재전송 공격 가능성이 올라가서 보안성이 감소된다.
  • 동기화된 난스 생성클라이언트랑 서버가 순차적으로 같은 난스를 생성할 수 있도록 시간적으로 동기화된 난스 생성 알고리즘을 사용한다.

2.8 난스 선택

• 난스 내용은 구현 의존적.
• RFC 2617이 가상의 난스 공식을 제안 - BASE64(time-stamp H(time-stamp ":" ETag ":" private-key))
• time-stamp - 서버에서 생성된 시간 혹은 반복 불가능한 값.
• ETag - 요청된 엔터티에 대한 ETag 헤더값.
• private-key - 서버만이 알고 있는 값.
• 서버는 클라 인증 헤더를 받은 뒤, 위 공식에서 해시 부분을 재계산하고 클라 인증 헤더의 난스와 일치하지 않거나 타임스탬프가 오래되었다면 요청을 거절함.
• 서버는 난스의 유효 기간을 제한할 수 있음.
• ETag를 포함하면 갱신된 리소스에 대한 재요청을 방지함.
• 클라 IP주소를 포함해도 되지만, 클라의 요청은 여러 프락시를 거칠 수 있기에 proxy farms을 망가뜨릴 수 있고, IP주소를 쉽게 속일 수 있다.
• 이전 난스나 요약을 받아들이지 않거나, 요청 메서드에 따라 다른 요소들을 사용하게 할 수도 있음

2.9 상호인증

• 클라이언트가 서버를 인증할 수 있도록 다이제스트 인증을 확장.
• 선택사항이지만 보안이 상당히 개선되므로 현대적인 클라이언트와 웹 서버라면 구현하는 게 권장된다.

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

• qop는 WWW-Authenticate, Authorization, Authentication-Info에 모두 존재할 수 있음.
• qop는 서버와 클라가 어떤 보호 기법을 어느 정도 수준으로 사용할 것인지 협상할 수 있게 해
  • 예로, 몇몇 트랜잭션은 전송 속도가 크게 떨어지는 것을 감수하고서도 메시지 본문의 무결성을 간단하게 검사하려고 할 수도 있음.
• 서버는 우선 WWW-Authenticate 헤더에 qop 옵션을 쉼표로 구분된 목록 형태로 내보냄.
• 클라는 그 옵션들 중 지원할 수 있으면서 자신의 요구에도 맞는 것을 선택. 그것을 Authorization 헤더의 qop 필드에 담아 돌려줌.
• 현대적인 요약 구현은 qop 옵션을 지원해야 한다.
• auth 는 인증을 의미. auth-int는 인증 및 메시지 무결성 보호를 의미.

3.1 메시지 무결성 보호

• auth-int일 때 계산된 H(request-entity-body) 은 메시지 본문의 해시가 아닌 엔터티 본문의 해시.
• 송신자에 의해 어떠한 전송 인코딩이 적용되기도 전에 먼저 계산되고 그 후 수신자에 의해 제거됨.
• 이때 여기에는 멀티파트 경계(multipart boundaries)와 각 파트의 임베딩된 헤더(embedded headers in each part of any multipart content type)를 포함.

3.2 다이제스트 인증 헤더

• 기본, 다이제스트 인증 프로토콜 모두 WWW-Authenticate 헤더에 담겨 전달되는 인증요구와, Authorization 헤더에 담겨 전달되는 인가 응답을 포함함.
• 다이제스트 인증은 여기에 선택적인 Authentication-Info 헤더를 추가. 이것은 핸드셰이크를 완성하고 다음번 사용할 난스를 전달하기 위해 인증 성공 후에 전송됨.