다이제스트 인증(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