CH12. 기본 인증

[sukstar76]

12.1 인증

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

• HTTP는 사용자 인증을 하는 데 사용하는 자체 인증요구/응답 프레임워크를 제공한다.

• 웹 애플리케이션이 HTTP 요청 메시지를 받으면, 서버는 요청을 처리하는 대신에 현재 사용자를 식별할 수있는 '인증 요구'로 응답할 수 있다.
• 인증 요구 응답을 받은 사용자는 다시 요청을 보낼 때 인증 정보(사용자 이름과 패시워드)를 첨부해야 한다.

2) 인증 프로토콜과 헤더

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

단계	헤더	설명	메서드/상태
요청		첫 번째 요청에는 인증 정보가 없다	GET
인증 요구	WWW-Authenticate	서버는 사용자에게 인증을 요구하며 401 상태 정보로 요청을 반려한다.서버에는 각각 다른 비밀번호 영역이 있으므로 WWW-Authenticate 헤더에 해당 영역을 설명해 놓는다.	401 Unathorized
인증	Authorization	클라이언트는 요청을 다시 보내는데, 인증 알고리즘과 사용자 이름과 비밀번호를 기술한 Authorization 헤더를 함께 보낸다.	GET
성공	Authentication-Info	인증 정보가 정확하다면, 서버는 문서와 함께 응답한다.특정 인증 알고리즘은 선택적 헤더인 Authentication-Info에 인증 세션에 관한 추가 정보를 기술해서 응답하기도 한다.	200 OK

3) 보안 영역

WWW-Authenticate: Basic realm="Family"

• 웹 서버는 기밀문서를 보안 영역(realm) 그룹으로 나누며, 보안 영역은 저마다 다른 사용자 권한을 요구한다.

12.2 기본 인증

• 기본 인증은 가장 잘 알려진 HTTP 인증 규약이다.
• 원래 HTTP/1.0에 기술되어 있었지만, HTTP 인증의 상세 내용을 다루는 RFC 2617로 옮겨졌다.

1) 기본 인증의 예

1. 사용자가 자신의 가족사진인 /family/jeff.jpg 요청한다.
2. 서버가 WWW-Authenticate 헤더와 함께 개인 가족사진에 접근하는 데 필요한 비밀번호를 요구하는 401 Unauthorization Required 응답을 반환한다.
3. 브라우저가 401 응답을 받고 Family 영역에 관한 사용자 이름과 비밀번호를 요구하는 대화상자를 띄운다.
4. 사용자가 사용자 이름과 비밀번호를 입력하면, 브라우저는 그것들을 콜론으로 이어 붙이고(eg. admin:admin), base-64 방식으로 인코딩한 후에 Authorization 헤더에 그 값을 담아 다시 서버로 요청한다.
5. 서버가 사용자 이름과 비밀번호를 디코딩하고, 그 값이 정확한지 검사한 후, 문제가 없으면 HTTP 200 OK 메시지와 함께 요청 받았던 문서를 응답한다.

인증요구/응답	헤더 문법과 설명
인증요구(서버에서 클라이언트로)	각 사이트는 보안 영역마다 다른 비밀번호가 있을 것이다.realm은 요청 받은 문서 집합의 이름을 따옴표로 감싼 것으로, 사용자는 이 정보를 보고 어떤 비밀번호를 사용해야 하는지 알 수 있다.WWW-Authenticate: Basic realm=따옴표로 감싼 문서 집합 정보
응답(클라이언트에서 서버로)	사용자 이름과 비밀번호는 콜론으로 잇고, base-64로 인코딩해서 사용자 이름과 비밀번호에 쉽게 국제문자를 포함할 수 있게 하고, 네트워크 트래픽에 사용자 이름과 비밀번호가 노출되지 않게 한다.Authorization: Basic base-64로 인코딩한 사용자 이름과 비밀번호

• 기본 인증은 Authentication-Info 헤더를 사용하지 않는다.

• 기본 인증은 Authentication-Info 헤더를 사용하지 않는다.

2) Base-64 사용자 이름/비밀번호 인코딩

• Base-64 인코딩은 바이너리, 텍스트, 국제 문자 데이터(어떤 시스템에서는 문제를 일으킬 수 있는) 문자열을 받아서 전송할 수 있게, 그 문자열을 전송 가능한 문자인 알파벳으로 변환하기 위해 발명됐다.

12.3 기본 인증의 보안 결함

• 단순하고 편리하지만 안심할 수는 없다.
• 악의적이지 않은 누군가가 의도치 않게 리소스에 접근하는 것을 막는데 사용하거나, SSL 같은 암호 기술과 혼용한다.
• 기본인증은 사용자 이름과 비밀번호를 쉽게 디코딩할 수 있는 형식으로 네트워크에 전송하며 이는 누구나 디코딩할 수 있도록 쉽다.
• 보안 비밀번호가 디코딩하기에 더 복잡한 방식으로 인코딩 되었더라도 공격 예방에 도움되지 않는다.
• 중요 정보가 아니더라도 일반 사용자가 보기에는 위험해 보인다.
• 메시지의 인증 헤더를 건드리지 않지만, 그 외 다른 부분을 수정해서 트랜잭션의 본래 의도를 바꿔버리는 프락시가 개입하는 경우, 기본 인증의 정상
• 작동을 보장하지 않는다.
• 가짜 서버의 위장에 취약하다.

인증 스킴
일반적인 HTTP 인증 프레임워크는 여러 인증 스킴에 의해 사용됩니다. 스킴은 보안 강도와 클라이언트 또는 서버 소프트웨어에서 사용 가능성에 따라 달라질 수 있습니다.

가장 일반적인 인증 스킴은 아래에서 좀 더 자세하게 소개할 "Basic" 인증 스킴입니다. IANA는 인증 스킴의 목록을 유지하고 있으나, Amazon AWS와 같은 호스트 서비스에 의해 제공되는 다른 스킴도 존재합니다. 일반적인 인증 스킴은 아래를 포함합니다.

• Basic (RFC 7617를 보십시오. base64-encoded credentials. 더 많은 정보는 아래를 확인하십시오.),

• Bearer (RFC 6750를 보십시오. bearer tokens to access OAuth 2.0-protected resources),

• Digest (RFC 7616를 보십시오. Firefox에서는 md5 해싱만 지원합니다. SHA 암호화 지원을 위하여 bug 472823을 확인하십시오.),

• 다이제스트 액세스 인증은 MD5 해싱을 사용하여 사용자 이름, 비밀번호, HTTP 메서드 또는 요청된 URI가 일반 텍스트로 서버에 전송되지 않도록 합니다.

• HTTP 다이제스트 액세스 인증은 필요한 모든 호출에 대해 클라이언트가 더 복잡한 인증 형식입니다. 그러나 Digest는 암호화를 사용하지만 여전히 메시지 가로채기 공격에 취약합니다.

• 1단계: 클라이언트가 서버에 요청을 보냅니다.

• 2단계: 서버가 특수 코드(nonce라고 함, 즉 한 번만 사용되는 번호)로 응답하고 영역(해시)을 나타내는 또 다른 문자열로 클라이언트에게 인증을 요청합니다

• 3단계: 클라이언트는 이 nonce와 암호화된 버전의 사용자 이름, 암호 및 영역(해시)
  으로 응답합니다.

• 4단계: 클라이언트 해시가 사용자 이름, 암호 및 영역의 자체 해시와 일치해야함

• HOBA (RFC 7486 (draft)를 보십시오. HTTP Origin-Bound Authentication, digital-signature-based),

• HOBA는 HTML에 포함된 JavaScript 기반 인증을 사용하는 HTTP 인증의 디지털 서명 기반 설계이며 암호가 필요한 HTTP 인증 체계의 대안입니다

• 디지털 서명을 인증 메커니즘으로 사용하여 클라이언트는 인증하는 각 호스트에 대해 새로운 공개-개인 키 쌍을 만듭니다.

• 이러한 키는 HTTP 클라이언트용 HOBA에서 HTTP 프로토콜 또는 Javascript 인증 프로그램의 서버에 대해 자신을 인증하는 데 사용됩니다.

• 키는 공개 키 인증서에 저장되지 않고 "대신 PKIX[RFC5280]의 subjectPublicKeyInfo 구조에 저장됩니다.

• 이들은 일반적으로 "베어 키"이기 때문에 특히 이름 지정 및 신뢰 앵커와 관련하여 PKIX 인증서의 의미 오버헤드가 없습니다.

• 따라서 클라이언트 공개 키("CPK")에는 해당 개인 키를 소유한 사용자에 대해 공개적으로 표시되는 식별자나 클라이언트가 CPK를 사용하는 웹 출처가 없습니다." (12)

• HTTPS 클라이언트 인증.

HTTPS를 사용한 클라이언트 측 인증은 사용자가 PKC(공개 키 인증서) 또는 2단계 인증 항목을 소유해야 하는 강력한 인증 메커니즘입니다.
"SSL(Secure Sockets Layer)은 TCP/IP 연결을 위한 데이터 암호화, 서버 인증, 메시지 무결성 및 선택적 클라이언트 인증을 제공합니다." (5)

• 클라이언트가 보호된 리소스에 대한 액세스를 요청합니다.

• 웹 서버는 클라이언트에 인증서를 제공합니다.

• 클라이언트는 서버의 인증서를 확인합니다.

• 성공하면 클라이언트는 클라이언트의 자격 증명을 확인하는 서버에 사용자 이름과 암호를 보냅니다.

• 확인에 성공하면 서버는 클라이언트가 요청한 보호된 리소스에 대한 액세스 권한을 부여합니다.

• Mutual (draft-ietf-httpauth-mutual를 참조하십시오),

• AWS4-HMAC-SHA256 (AWS docs를 참조하십시오).