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

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

목차
  • 1
    실제 상황에 대한 고려
    다중인증요구 / 오류 / realm(보호공간) / URI 다시쓰는.. / 캐시
  • 2
    보안에 대한 고려사항
    헤더 부당변경 / 재전송 공격 / 다중인증 매커니즘 / 사전공격 / 악의적인 프락시와 중간자 공격 / 선택 평문 공격 / 비밀번호 저장

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


1. 실제 상황에 대한 고려

TL;DR

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

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의 공백으로 분리된 목록이다.
        1
        domain = "'/cart' '/main'"
  • 이 domain 목록의 모든 URI와
    논리적으로 그 하위에 위치한 모든 URI는
    같은 보호 공간에 있는 것으로 가정한다.

  • 만약 domain 필드가 없거나 빈 값이라면,
    인증을 요구하는 서버의 모든 URI는 그 보호 공간에 있는 것이다.

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

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

1.5 캐시

  • 어떤 공유가 Authorization 헤더를 포함한 요청과 그에 대한 응답을 받은 경우,
    Cache-Control 지시자 must-revalidatepublic 중 하나가 응답에 존재하지 않는 한
    다른 요청에 대해 그 응답을 반환해서는 안된다.
  • 만약 원서버의 응답이 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. 영역 이름이 유일함을 보장하며, 비밀번호 파일이 유출되더라도,
        피해를 특정 영역으로 국소화한다.
        • 호스트와 도메인을 포함한 완전한 영역 이름을 이 요구를 만족한다.


참고자료

Share
📚