다이제스트 인증
"절대로 비밀번호를 네트워크를 통해 보내지 않는다."는 특징을 가진 인증 방식이다. 때문에 비밀번호를 절대 평문으로 전송하지 않고 인증 체결을 가로채서 재현하려고 하는 공격 방식 등을 막는다. 클라이언트는 비밀번호를 보내는 대신에 지문 혹은 요약을 보낸다. 서버는 클라이언트가 제공한 요약과 서버가 내부적으로 계산한 요약이 일치하는 경우 클라이언트에게 문서를 제공하게 된다. 요약은 단방향 함수로 동작하며 MD5나 SHA 등을 통해 변환을 진행한다.
nonce 사용
단방향 요약을 통해 비밀번호 원문을 보내지 않더라도, 재전송 공격을 하게 된다면 마찬가지로 위험할 수 있다. 때문에 서버는 클라이언트에게 난스를 전달하는데, 난스란 대략 1밀리초마다 혹은 인증할 때마다 바뀌는 증표이다. 난스를 비밀번호에 섞게 되면 요약도 바뀌기 때문에 이로 인해 재전송 공격을 막을 수 있다. 서버는 WWW-Authenticate 인증요구 메시지를 통해 난스를 전달한다. 그리고 클라이언트가 이를 바탕으로 요약을 계산한 후 서버에 보내면, 서버에서는 서버가 계산한 요약과 일치하는지를 비교한다.
요약 계산
요약은 단방향 해시 함수 H, 요약 함수 KD로 계산된다. 비밀번호 등 보안 정보를 담고 있는 데이터 덩어리는 A1이라 칭하고, 요청 메시지의 비밀이 아닌 속성을 담고 있는 데이터 덩어리는 A2라 칭한다.
H 함수는 데이터의 MD5를 계산하고, KD 요약함수는 콜론으로 연결된 비밀 데이터와 일반 데이터를 MD5로 계산한다.
A1은 데이터 덩어리로, 사용자 이름, 비밀번호, 보호 영역, 난스와 같은 비밀 보호 정보로 이루어져 있다. A1을 계산하기 위해 MD5, MD5-sess가 사용되며 여러 정보를 콜론으로 연결하여 계산된다.
A2도 데이터 덩어리이지만, A1과는 달리 URL, 요청 메서드, 메시지 엔터티 본문과 같은 메시지 자체의 정보를 나타낸다. 마찬가지로 요약을 계산하기 위해 사용된다.
사전 인가
사전 인가는 기본 인증에서는 흔하다. 하지만 다이제스트 인증에서는 난스 기술이 재전송 공격을 저지하기 위해 만들어진 것이기 때문에 사전 인가를 처리하는 것이 복잡하다. 다이제스트 인증에서 사전 인가를 처리하기 위해 다음 방법을 사용한다.
- 서버가 다음 난스를 Authentication-Info 성공 헤더에 담아 미리 전송
- 서버가 짧은 시간 동안 난스 재사용을 허용
- 클라이언트와 서버가 동기화 되어있고 예측 가능한 난스 생성 알고리즘을 사용
보호 수준(Quality Of Protection) 향상
qop 필드는 요약 헤더의 세 가지 헤더 WWW-Authenticate, Authorization, Authentication-Info에 모두 존재할 수 있다. qop 필드는 클라이언트와 서버가 어떤 보호 기법을 어느 정도 수준으로 사용할 것인지 협상할 수 있게 한다.
실제 상황에 대한 고려
- 다중 인증요구 : 서버가 기본 및 다이제스트 인증요구를 모두 보낼 경우, 클라이언트는 자신이 지원할 수 있는 가장 강력한 인증 매커니즘을 선택해야 한다. 하지만 동시에 서버는 기본 인증을 제한적으로 사용하여 보안 우려를 줄여야 한다.
- 오류 처리 : 적절하지 않거나 요구된 지시자가 빠져있을 경우 요약이 맞지 않으면 로그인 실패를 기록하여 공격자가 비밀번호 추측을 시도하지는 않은지 확인해야 한다.
- 보호 공간 : 다이제스트 인증에서 인증요구의 WWW-Authenticate: domain 필드는 보호 공간을 보다 엄밀하게 정의한다. domain 목록의 모든 URI와 그 하위에 위치한 모든 URI는 같은 보호 공간에 있는 것으로 가정한다. 만약 domain 필드가 없거나 빈 값이라면, 인증을 요구하는 서벙릐 모든 URI는 보호 공간에 있는 것이다.
- URI 다시 쓰기 : 프락시는 가리키는 리소스의 변경 없이 구문만 고쳐서 URI를 다시 사용하기도 하는데, 다이제스트 인증은 URI 값의 무결성을 검사하기 때문에 다이제스트 인증은 이러한 변경에 의해 실패할 수 있다.
- 캐시 : Cache-Control 중 원 서버의 응답이 "must-revalidate" 지시자를 포함한 경우 원 서버가 새 요청을 인증할 수 있도록 우선 그 요청의 헤더를 이용해서 재검사를 수행해야 한다. 그리고 만약 "public"이 포함된 경우 응답 엔터티는 그다음에 오는 임의의 요청에 대한 응답으로 반환될 수 있다.
보안에 대한 고려사항
- 헤더 부당 변경 : 양 종단 암호화나 헤더에 대한 디지털 서명을 하면 좋다.
- 재전송 공격 : 특정 트랜잭션에서 엿들은 인증 자격을 다른 트랜잭션을 위해 사용하는 것을 의미. 매 요청마다 유일한 난스 값을 사용하는 것이 좋다.
- 다중 인증 메커니즘 : 서버가 다중 인증 제도를 지원할 때 클라이언트가 가장 강력한 인증 메커니즘을 선택할 의무가 없기 때문에 인증 강도가 가장 약하다고 볼 수 있다.
- 사전 공격 : 사용자가 상대적으로 단순한 비밀번호를 사용하고 서버도 단순한 난스를 사용하고 있다면 악의적인 사용자가 난스/응답 쌍에 대해 흔히 구할 수 있는 비밀번호 추측 프로그램을 사용할 수 있다.
- 악의적인 프락시와 중간자 공격 : 엿듣기 공격이 될 수도 있고 인증 제도 선택지를 모두 제거하고 가장 약한 인증 제도로 대체하게 될 수도 있다.
- 선택 평문 공격 : 서버에서 제공된 난스를 사용하는 것 대신 선택적인 c난스 지시자를 사용하여 응답을 생성할 수 있도록 설정할 수 있다.
- 비밀번호 저장 : 다이제스트 인증 비밀번호 파일이 유출되지 않도록 해야 한다
'개발' 카테고리의 다른 글
[항해 플러스] 프론트엔드 3기 수료 후기 (4) | 2025.01.11 |
---|---|
[HTTP 완벽 가이드] 14장 보안 HTTP 14.1~14.4 (0) | 2025.01.10 |
[HTTP 완벽 가이드] 12장 기본 인증 (1) | 2025.01.02 |
[HTTP 완벽 가이드] 11장 클라이언트 식별과 쿠키 (0) | 2025.01.02 |
[HTTP 완벽 가이드] 10장 HTTP/2.0 (0) | 2025.01.02 |