기본 인증

기본 인증

목차

TL;DR



인증 🔐

  • 완벽한 인증이란 없다. 비밀번호는 유출될수있고, 신분증은 위조될 수 있다.
  • 하지만 당신에 대한 여러 데이터는 당신이 누구인지 판단하는데 도움이 된다.

1.1 HTTP의 인증요구/응답 프레임워크

  • HTTP는 사용자 인증을 하는 데 사용하는 자체 인증요구/응답 프레임워크를 제공한다.
  • 웹앱이 HTTP 요청 메세지를 받으면,
    서버는 요청을 처리하는 대신에,
    현재 사용자가 누구인지를 알 수 있게 비밀번호 같이,
    개인정보를 요구하는 인증요구로 응답할 수 있다.
  • 사용자가 다시 요청을 보낼때는 인증정보를 첨부해야한다.
  • 인증 정보가 맞지 않으면 서버는 클라에 다시 인증요구를 보내거나 에러를 낼 수 있다.

1.2 인증 프로토콜과 헤더

  • HTTP는 필요에 따라 고쳐 쓸 수 있는 제어 헤더를 통해,
    다른 인증 프로토콜에 맞추어 확장할 수 있는 프레임워크를 제공한다.

  • HTTP에는

    1. 기본인증
    2. 다이제스트 인증

    이라는 두가지 공식적인 인증 프로토콜이 있다.

  • 미래에는, 사람들이 HTTP 인증요구/응답 프레임워크를 사용해 새로운 프로토콜을 고안해 낼 수 있을 것이다.

    현대에 HTTP의 인증요구/응답 프로토콜을 사용하는 인증 프로토콜로는 OAuth가 있다.
    OAuth는 모바일 기기같은 다양한 어플리케이션에서 API 인증을 위해 사용하는 최신 인증 프로토콜이다. (RFC6749)

  1. 요청 단계 - 인증정보 없음
  2. 인증 요구 - 401과 함께 요청 반려. WWW-Authenticate 헤더에 해당 영역을 설명해 놓는다.
  3. 인증 단게 - Authorization 헤더를 함께 보냄
  4. 성공 단계 - 성공
1
WWW-Authenticate: Basic realm="Access to the staging site"

1.3 보안영역

  • HTTP가 어떻게 각 리소스마다 다른 접근 조건을 다루는지 알아보자.
  • 웹 서버는 기밀문서를 보안 영역 realm 그룹으로 나눈다.
  • 보안 영역을 저마다 다른 사용자 권한을 요구한다.


1. 기본 인증 👮‍♀️

  • 기본 인증은 가장 잘 알려진 HTTP 인증 규약이다.
  • 거의 모든 주요 클라와 서버에 기본 인증이 구현되어 있다.
  • 기본인증에서, 웹 서버는 클라의 요청을 거부하고 유효한 사용자 이름과 비밀번호를 요구할 수 있다.
  • 서버는 401 상태코드와, 클라가 접근하려고 했던 보안 영역을 WWW-Authenticate에 기술해서 응답하여, 인증요구를 시작한다.

1.1 Base-64 사용자 이름/비밀번호 인코딩 🧞‍♂️

  • HTTP 기본 인증은
    사용자 이름과 비밀번호를 콜론:으로 이어서 합치고,
    base-64 인코딩 메서드를 사용해 인코딩한다.

cf__1 Base-64 인코딩

  • base-64 인코딩은 8비트 바이트로 이루어져 있는 시퀀스를 6비트 덩어리의 시퀀스로 변환한다.
    각 6비트 조각은 대부분 문자와 숫자로 이루어진 특별한 64개의 문자 중에서 선택된다.
  • base-64 인코딩은 바이너리, 텍스트, 국제 문자 데이터를 문자열로 받아서 전송할 수 있게,
    그 문자열을 전송 가능한 문자인 알파벳으로 변환하기 위해 발명됐다.
  • base-64 인코딩은 국제 문자나 HTTP 헤더에서 사용할 수 없는 문자(큰따옴표, 콜론, 캐리지 리턴)을 포함한 사용자 이름이나 비밀번호를 보내야할 때 유용할 수 있다.


1.2 프락시 인증 🐝

  • 중개 프락시 서버를 통해 인증할 수도 있다.

  • 프락시 서버에서 접근 정책을 중앙 관리할 수 있는 장점이 있음

  • 상태코드: 407

  • Proxy-Authenticate (like WWW-Authenticate)

  • Proxy-Authorization (like Authorization)



1.3 기본 인증의 보안 결함 🤦‍♀️

  • 기본 인증은 악의적이지 않은 누군가가 의도치 않게 리소스에 접근하는 것을 막는데 사용하거나,
    SSL 같은 암호 기술과 혼용한다.

1. 누구나 디코딩할 수 있다.

  • 기본인증은 쉽게 디코딩할 수 있는 형식으로 네트워크에 전송한다.
  • 메모하기 어렵지 않은 일반 문자열로 보내진다.
  • base-64로 인코딩된 비밀번호는 사실상 비밀번호 그대로 보내는 것과 다름없다.
  • HTTP 트랜잭션을 SSL 암호화 채널을 통해 보내거나
    보안이 더 강화된 다이제스트 인증 같은 프로토콜을 사용하는 것이 좃다.

2. 재전송 공격을 예방하지 않는다.

  • 복잡한 방식으로 인코딩 되어있더라도, 해당 인코딩 문자열을 캡쳐한 다음,
    그대로 원 서버에 보내서 인증을 성공하고 서버에 접근할 수 있다.
  • 기본인증은 재전송 공격을 예방하기 위한 어떤 일도 하지 않는다.

3. 한번 뚫리면..

  • 사용자는 대부분의 사이트에 같은 아이디와 비밀번호를 사용한다.
  • 한번 도용되면 중요한 사이트에서도 접근할 수 있다.

4. 기본인증의 정상동작 보증 못함

메세지의 인증헤더를 건드리지는 않지만,
그 외 다른 부분을 수정해서 트랜잭션의 본래 의도를 바꿔버리는
프락시나 중개자가 중간에 개입하는 경우,
기본 인증은 정상적인 동작을 보장하지 않는다.

5. 가짜 서버

  • 기본인증은 가짜 서버의 위장에 취약하다.
  • 가짜 서버에 연결되어 있지만, 사용자는 검증된 서버에 연결되어있다고 믿고, 개인정보를 노출할 수 있다.

기본인증은 다른 사람들이 보지 않기를 원하긴 하지만,
보더라도 치명적이지 않은 경우에는 여전히 유용하다.
기본 인증보다 더 복잡하고 강력한 보안 관련 속성인 다이제스트 인증을 다음 포스팅에서 알아보자.



참고자료

📚