그림으로 배우는 Http & Network Basic 8장, 누가 액세스하고 있는지를 확인하는 인증에 대해 정리한 포스트입니다.

인증이란?

컴퓨터는 네트워크 저편에 누가 있는지 알수가 없기 때문에 등록된 본인만이 알고 있는 정보나 등록한 본인만이 가지고 있는 정보 등으로 확인할 필요가 있습니다.
HTTP/1.1 에서는 아래 인증 방식을 사용할 수 있습니다.

  • BASIC 인증
  • DIGEST 인증
  • SSL 클라이언트 인증
  • 폼 베이스 인증

BASIC 인증

BASIC 인증 은 웹 서버와 대응하고 있는 클라이언트 사이에서 이뤄지는 인증 방식 입니다.

  • HTTP/1.0에 구현된 인증 방식으로 현재에도 일부 사용되고 있음

BASIC 인증의 개요

  1. BASIC 인증이 필요한 리스소에 리퀘스트가 있을 경우, 서버는 401과 함께 인증 방식(BASIC)과 Request-URI의 보호 공간을 식별하기 위한 문자열(realm)을 WWW-Authenticate 헤더 필드에 포함해서 리스폰스를 반환
  2. 401을 받은 클라이언트는 유저 ID와 패스워드를 Base64 형식으로 인코드해서 Authorization 헤더 필드에 포함해 리퀘스트 송신
    • 유저 ID가 guest이고 패스워드가 guest인 경우 연결하면 guest:guest가 되고 인코드하면 위와같이 변환됨
    • 일반적으로 브라우저가 알아서 자동으로 해줌
  3. Authorization 헤더 필드를 포함한 리퀘스트를 수신한 서버는 인증 정보가 정확한지 여부를 판단하고 정확하면 요청받은 리소스 반환

암호화를 하지 않기 때문에 복호화가 쉬운 특징이 있습니다.

  • 즉, HTTPS 등에서 암호화되지 않은 통신 경로 상에서 도청될 경우 ID, 패스워드를 빼앗길 수 있음

BASIC인증은 일반 브라우저에서 로그아웃을 할 수 없다는 문제도 있기 때문에 사용상의 문제가 있고, 보안 등급도 높지 않아 많이 사용되지 않는 방식입니다.

DIGEST 인증

DIGEST 인증은 챌린지 리스폰스 방식을 사용하고 있어 BASIC 인증과 같이 패스워드를 평문 그대로 보내지 않습니다.

챌린지 리스폰스

  • 챌린지 리스폰스 방식은 최초에 상대방에게 인증 요구를 보내고 상대방 측에서 받은 챌린지 코드를 사용해서 리스폰스 코드를 계산하여 이것으로 인증을 하는 방식
    • BASIC인증에 비해 패스워드 누출 가능성이 적음
  • BASIC 인증의 약점을 보완하며 HTTP/1.1에 소개된 인증

DIGEST 인증의 개요

  1. 인증이 필요한 리소스에 리퀘스트가 있을 경우 서버는 401과 함께 챌린지 리스폰스 방식의 인증에 필요한 챌린지 코드(nonce)를 WWW-Authenticate 헤더 필드에 포함해서 리스폰스 반환
    • realm과 nonce는 반드시 WWW-Authenticate에 포함되어야 함
    • nonce는 리스폰스를 반환할 때마다 생성되는 유일한 문자열
  2. 클라이언트는 DIGEST 인증을 위해 필요한 정보를 Authorization 헤더 필드에 포함해서 리스폰스를 반환
    • username, realm, nonce, uri, response 는 반드시 포함해야 함
    • realm, nonce는 서버에서 받은 것을 사용
    • username은 지정된 realm에서 인증 가능한 사용자 이름
    • uri(digest-uri)는 Request-URI에 있는 URI
    • response는 Request-Digest라고 불리는데 패스워드 문자열을 MD5로 계산한 것이고, 이것이 리스폰스 코드입니다.
      • 생성 규칙은 복잡하니 RFC2617을 참조
  3. Authorization 헤더 필드를 포함한 리퀘스트를 받은 서버는 인증 정보가 정확한지 판단하고 정확할 경우 Request-URI의 리소스를 포함한 리스폰스를 반환
    • Authentication-Info 헤더 필드에 인증이 성공했다는 정보를 포함할 수도 있음(Optional)

DIGEST인증은 BASIC 인증보다야 높은 보안 등급을 제공하지만 HTTPS의 클라이언트 인증 등과 비교하면 낮습니다.

  • 도청을 방지하는 보호 기능을 제공하지만 위장을 방지하는 기능은 제공하지 않음

DIGEST 인증도 사용상의 문제와 보안 등급이 낮아 그다지 사용되고 있지 않습니다.

SSL 클라이언트 인증

SSL 클라이언트 인증은 HTTPS의 클라이언트 인증서를 이용한 인증 방식입니다.

  • 사전에 등록된 클라이언트에서의 엑세스인지 아닌지를 확인
  • ID와 패스워드를 사용한 인증 방식은 이 정보가 도난되었을 때 제 3자가 위장을 하는 경우가 있을 수 있음

SSL 클라이언트 인증을 할 때에는 사전에 클라이언트에 클라이언트 증명서를 베포하고 인스톨 해둘 필요가 있습니다.

  1. 인증이 필요한 리소스의 리퀘스트가 있었을 경우, 서버는 클라이언트에게 클라이언트 증명서를 요구하는 Certificate Request라는 메시지를 송신
  2. 유저는 송신하는 클라이언트 증명서를 선택하고 이것을 Client Certificate라는 메시지로 송신
  3. 서버는 클라이언트 증명서를 검증하고 그 결과가 정확하다면, 클라이언트의 공개키를 취득
  4. HTTPS 에 의한 암호를 개시

SSL클라이언트 인증은 이후 나올 폼 베이스 인증과 함께 2-factor 인증의 하나로 이용됩니다.

  • 2-factor 인증이란 예를 들어 패스워드라는 한 개의 요소만이 아닌 이용자가 가진 다른 정보를 병용해서 인증을 하는 방법
  • 예를들어 SSL 클라이언트 인증으로 컴퓨터를 인증하고(1), 패스워드로 유저의 본인 확인(2) 하여 올바른 액세스라는 것을 확인 할 수 있습니다.

SSL 클라이언트 인증에서는 클라이언트 인증서를 이용하기 때문에 비용이 발생합니다(그것도 상당히).

폼 베이스 인증

폼 베이스 인증은 클라이언트가 서버 상의 웹 애플리케이션에 자격 정보(Credential)을 송신하여 그 자격 정보의 검증 결과에 따라 인증을 하는 방식입니다.

  • HTTP 프로토콜로서 사양이 정의되어 있는 인증 방식은 아닙니다.
  • 웹 애플리케이션에 따라 제공되는 인터페이스나 인증의 방법이 다양
  • 대부분의 경우 사전에 등록해 둔 자격 정보인 유저 ID, Password를 웹 애플리케이션 측에 송신하고 검증 결과를 토대로 성공 여부를 결정

대부분은 폼 페이스 인증으로 인증을 하고 있습니다.

  • HTTP가 표준으로 제공하는 BASIC 인증이나 DIGEST 인증은 사용상/보안의 문제로 거의 사용되지 않음
  • SSL 클라이언트 인증도 도입 비용, 운용 비용으로 널리 쓰이지 못함

공통 사양이 결정되어 있지 않기 때문에 웹 사이트별로 다른 구현을 하고 있지만 일반적으로 세션 관리를 위해 쿠키를 사용하는 방법이 자주 사용됩니다.

  1. 폼 베이스 인증 자체는 서버 측의 웹 애플리케이션 등에 의해서 클라이언트가 송신해온 유저 ID와 패스워드가 사전에 등록하고 있는 것과 일치하는지 어떤지를 검증하면서 이루어집니다.
  2. Stateless 프로토콜인 HTTP에서는 방금 전에 인증을 성공한 유저라는 상태를 프로토콜 레벨에서 유지할 수가 없음
  3. 세션 관리와 쿠키를 사용해 상태 관리 기능을 보충

폼 베이스 인증

  1. 서버에 자격 정보(ID, 패스워드 등)을 포함한 리퀘스트를 송신
    • 보통은 POST 메소드가 사용되어 엔티티 바디에 자격 정보 저장
    • HTML 폼 화면 표시와 입력 데이터의 송신에는 HTTPS 통신을 이용
  2. 서버 측은 유저를 식별하기 위해 세션 ID를 발행
    • 클라이언트가 보낸 자격 정보를 검증하여 인증
    • 유저의 인증 상태를 세션 ID와 연관지어 서버 측에 기록
    • Set-Cookie 헤더 필드에 세션 ID를 저장해서 리스폰스 반환
  3. 서버 측에서 세션 ID를 받은 클라이언트는 쿠키로 저장
    • 서버에 리퀘스트를 송신할 때 브라우저가 자동으로 쿠키를 송출

Reference

그림으로 배우는 HTTP & Network Basic