다이제스트 인증(2) - 실제 다이제스트 인증과 보안

점점 번역이 이해하기 더 어려워질 정도로 직역형태다..

1. 실제 상황에 대한 고려

TL;DR

1. 다이제스트 인증 요구 qop: 가장 강력한 인증 매커니즘 선택하기
2. 오류 처리: 400 Bad Request
3. 보호 공간 realm: 일반적으로 원 서버에 의해 할당되는 문자열
4. URI 다시 쓰기: 프락시는 구문만 고쳐서 URI를 다시 쓰기도 한다
5. 캐시: must-revalidate나 public

1.1 다중 인증 요구 qop

• 서버는 한 리소스에 대해 여러 인증을 요구할 수 있다.
• 보통은 WWW-Authenticate에 qop필드에 쉼표로 구분하여 인증방법을 보내준다.
• 클라는 자신이 지원할 수 있는 가장 강력한 인증 메커니즘을 선택해야 한다.
• 다양한 인증 옵션을 제공할 때, 클라가 강력한 인증 메커니즘을 지원하지 못한다면, 사용자에게 보안에 대해 경고를 해야 한다.

1.2 오류 처리

• 다이제스트 인증에서, 지시자나 그 값이 적절하지 않거나, 요구된 지시자가 빠져있는 경우 400 Bad Request
• 로그를 남기자 비밀번호가 반복적으로 실패할 경우, 공격자의 비밀번호 추측의 시도가 있을 수 있으므로 로그를 남기는게 좋다.
• URI 지시자가 가리키는 리소스가 요청줄에 명시된 리소스와 같음을 확인해야한다. (중간 프락시가 변조할 수도 있음)
  • 요청줄에 명시된 리소스는 domain필드에 같이 명시해준다.

1.3 보호 공간 realm

• 영역 값은, 접근한 서버의 루트 URL과 결합하여, 보호 공간을 정의한다.

• 영역은 보호 영역의 집합으로 분할할 수 있도록 해준다. (보호 영역으로 따로 구분해둔다..)

  번역이해가 어려워서 나름 위 문장대로 이해함.. 원문: 영역은 서버의 보호된 리소스들을 자신만의 인증제도와 인가 데이터베이스 어느 한쪽 혹은 양쪽 모두를 가진 보호 영역의 집합으로 분할 할 수 있도록 해준다.

• 영역의 값은 일반적으로 원 서버에 의해 할당되는 문자열이다. (인증 제도에 추가적인 의미를 더한다.)

• 보호공간은 어떤 자격이 자동으로 적용되는 영역을 결정한다.

  • 이전 요청이 인가되면, 같은 자격은 인증제도, 매개변수, 사용자 설정 중 한가지 이상에 의해 정해진 시간 동안 재사용 될 것이다.

• 보호공간의 구체적인 계산은 인증 메커니즘에 달려있다.

  1. 기본 인증
  • 클라는 요청 URI와 그 하위의 모든 경로는 같은 보호 공간에 있는 것으로 가정한다.
  • 클라는 이 공간에서 서버로부터의 또 다른 인증 요구를 기다리지 않고, 미리 리소스에 대한 인가를 받을 수 있다.
  2. 다이제스트 인증
  • WWW-Authenticate: domain 필드는 보호 공간을 보다 엄밀하게 정의한다.
  • domain 필드는 작은 따옴표로 묶인 URI의 공백으로 분리된 목록이다.

domain = "'/cart' '/main'"

• 이 domain 목록의 모든 URI와 논리적으로 그 하위에 위치한 모든 URI는 같은 보호 공간에 있는 것으로 가정한다.
• 만약 domain 필드가 없거나 빈 값이라면, 인증을 요구하는 서버의 모든 URI는 그 보호 공간에 있는 것이다.

1.4 URI 다시 쓰기 (feat. 프락시)

• 프락시는 가리키는 리소스의 변경 없이 구문만 고쳐서 URI를 다시 쓰기도 한다.
• 예
  • 호스트 명은 정규화괴거나 IP주소로 대체될 수 있다.
  • 문자들은 % escape 형식으로 대체될 수 있다.
  • 특정 원서버로부터 가져오는 리소스에 영향을 주지 않는, 타입에 대한 추가 속성이 URI의 끝에 붙거나 중간에 삽입될 수 있다.
• 프락시가 URI를 변경할 수 있는 동시에 다이제스트 인증은 URI 값의 무결성을 검사하므로 다이제스트 인증은 이러한 변경에 의해 실패할 수 있다.

1.5 캐시

• 어떤 공유가 Authorization 헤더를 포함한 요청과 그에 대한 응답을 받은 경우, 두 Cache-Control 지시자 must-revalidate나 public 중 하나가 응답에 존재하지 않는 한 다른 요청에 대해 그 응답을 반환해서는 안된다.
• 만약 원서버의 응답이 must-revalidate Cache-Control 지시자를 포함한 경우,
  • 캐시는 그 응답의 엔터티를 다음 요청에 대한 응답을 위해 활용할 것이다.
  • 그러나 원 서버가 새 요청을 인증할 수 있도록, 우선 그 요청의 헤더를 이용해서 재검사를 수행해야한다.
• 만약 원서버의 응답이 public Cache-Control 지시자를 포함한 경우, 응답 엔터티는 그 다음에 오는 임의의 요청에 대한 응답으로 반환될 수 있다.

2. 보안에 대한 고려사항

TL;DR

1. 헤더 부당 변경: 양종단 암호화 / 디지털 서명
2. 재전송 공격: 매 트랜잭션마다 유일한 난스값
3. 다중 인증 매커니즘: 가장 강력한 인증 제도만을 유지하는 프락시 서버 사용
4. 사전 공격: 복잡한 비밀번호사용 및 비밀번호 만료 정책
5. 악의적인 프락시와 중간 공격: SSL을 사용하는 것
6. 선택 평문 공격: 선택적 c난스 사용 / 만료매커니즘 / 강력 비밀번호
7. 비밀번호 저장: -

1. 헤더 부당 변경

• 헤더 부당 변경에 대해 항상 안전한 시스템을 제공하기 위해서 양 종단 암호화나 헤더에 대한 디지털 서명이 필요할 것이다.

2. 재전송 공격

• 재전송 공격이란, 누군가 어떤 트랜잭션에서 엿들은 인증자격을 다른 트랜잭션을 위해 사용하는 것을 말한다.
• GET 요청에 대한 이슈이긴 하지만 POST나 PUT 요청에 대한 재전송 공격에 대해서도 항상 잘 동작하는 예방책은 필수적으로 가지고 있어야 한다.
• 재전송 공격을 완전히 피할 수 있는 한 방법은 매 트랜잭션마다 유일한 난스 값을 사용하는 것이다.
  • 이 구현에서는 매 트랜잭션마다 서버는 유일한 난스를 타임아웃 값과 함께 발급한다.
  • 발급된 난스 값은 그때의 트랜잭션과 주어진 타임아웃 값의 기간 동안만 유효하다.

3. 다중 인증 메커니즘

• 서버가 다중 인증 제도를 지원할때, 선택지를 제공할 것이다. 클라에게 가장 강력한 인증 메커니즘을 선택해야 할 의무가 있는 것은 아니기 때문에, 결국 인증의 강도는 선택지 중 가장 약한 것과 같다고 보아야 한다.
• 클라가 언제나 가능한 한 가장 강력한 인증제도를 선택하면 문제가 해결하면 되지만, 현실적으로 불가능하다면, 가장 강력한 인증 제도만을 유지하는 프락시 서버를 사용하여 해결하는 것이다.
  • 그러나 이런 접근은 오직 모든 클라가 우리가 선택한 강력한 인증 제도를 지원할 수 있다고 알려진 경우에만 실현 가능하다.

4. 사전 공격 dictionary

• 사전공격은 전형적인 비밀번호 추측 공격이다.
• 악의적인 사용자는 트랜잭션을 엿들을 수 있고, 난스/응답 쌍에 대해 (흔히 구할 수 있는) 비밀번호 추측 프로그램을 사용할 수 있다.
• 크래킹하기 어렵도록 상대적으로 복잡한 비밀번호를 사용하는 것과 괜찮은 비밀번호 만료 정책 외에는 실질적으로 없다.

5. 악의적인 프락시와 중간 공격 Man in the Middle Attack

• 리다이렉션 기술과 차단 프락시의 도입으로 사용자는 그의 요청이 프락시를 통과한다는 것조차 눈치 채지 못하고 한다.

• 만약 이들 프락시 중 하나가 악의적이거나 보안이 허술하다면, 클라는 중간자 공격에 취약한 상태가 될 가능성이 있다.

• 해결할 좋은 방법은 없지만, 가능한 해결책은,

  1. 클라가 사용자에게 인증의 강도를 시각적으로 보여주는 것
  2. 클라가 언제나 가능한 한 가장 강력한 인증을 선택하도록 설정하는 것

  등이 있다.

• 공격을 방어하는 제일 좋은 방법은 SSL을 사용하는 것이다.

6. 선택 평문 공격

• 다이제스트 인증을 사용하는 클라는 응답을 생성하기 위해 서버가 제공한 난스를 사용한다.
• 그러나 악의적인 서버나 프락시가 있을 중간에 있을 경우 클라 응답 게산을 하기 위한 난스를 제공할 수 있다. = 선택적 평문 공격

1. 미리 계산된 사전 공격

   • 사전공격과 선택 평문 공격의 조합
   1. 공격서버는 미리 결정된 난스와 자주 쓰이는 비밀번호들로 응답의 집합을 생성하고, 사전을 만든다.
   2. 공격 서버/프락시는 트래픽을 차단하고 미리 결정된 난스를 클라로 전송하기 시작한다.
   3. 클라로부터 응답을 받을 때, 공격자는 대응되는 항목을 사전에서 찾는다.
   4. 대응되는 것이 있으면, 공격자는 특정 사용자의 비밀번호를 손에 넣은 것

2. 자동화된 무차별 대입 공격

   • 많은 컴퓨터를 동원하여 주어진 범위에서 가능한 모든 비밀번호를 열거한다.

• 이런 공격으로 인한 위협을 방어하는 방법
  • 서버에서 제공된 난스 대신 선택적 c난스 지시자를 사용하여 응답할 수 있도록 한다.
  • 만료 메커니즘이나 강력한 비밀번호를 강제하는 정책이 있으면 더 높은 방어가 가능

7. 비밀번호 저장

• 다이제스트 인증 메커니즘은 사용자 응답을 서버 내부에 저장된 것과 비교한다.
• 비밀번호가 유출되는 문제를 완화하는 몇가지 방법
  1. 비밀번호 파일이 평문으로 된 비밀번호를 포함하고 있다고 생각하고 안전하게 보호한다. (?)
  2. 영역 이름이 유일함을 보장하며, 비밀번호 파일이 유출되더라도, 피해를 특정 영역으로 국소화한다.
  • 호스트와 도메인을 포함한 완전한 영역 이름을 이 요구를 만족한다.

• HTTP 완벽가이드  책을 보고 이해한 내용을 정리 한 글입니다.

참고자료

• RFC7235-realm 

Related