웹사이트에 있는 모든 정보나 업무가 공용은 아니기 때문에 허가된 사람만이 데이터에 접근하고 업무를 처리할 수 있어야 한다. 그러기 위해서는 서버가 사용자가 누구인지 식별할 수 있어야 한다. 인증은 누구인지 증명하는 작업이다. 보통 사용자는 이름과 비밀번호를 입력해서 인증한다.
#1. 인증
인증은 사용자가 누구인지 증명하는 것이다.
웹 애플리케이션이 HTTP 요청 메시지를 받으면 서버는 요청을 처리하는 대신에 비밀번호 같이 개인 정보를 요구하는 '인증 요구'로 응답할 수 있다. 사용자가 다시 요청을 보낼 때 인증정보를 첨부해야 요청이 문제없이 처리가 된다.
인증 프로토콜과 헤더
| 단계 | 헤더 | 설명 | 메서드/상태 |
| 요청 | 첫 요청은 인증 정보 없음 | GET | |
| 인증요구 | WWW-Authenticate | 서버는 사용자에게 인증 요구 | 401 Unauthorized |
| 인증 | Authorization | 클라이언트 재요청(인증) | GET |
| 성공 | Authentication-Info | 인증확인, 문서와 함꼐 응답 | 200 OK |
- 사용자가 서버에 요청을 보냄.
- 서버는 사용자에게 인증을 요구 (401 Unauthorized 응답과 함께 WWW-Authenticate 헤더를 통해 인증방법 설명)
- 클라이언트는 인코딩 된 비밀번호와 인증 파라미터들을 Authorization 헤더에 담아 재요청을 한다.
- 서버는 인증이 완료되면 상태 코드 (200 OK)를 반환하며 추가적인 인증 알고리즘을 Authentication-Info 헤더에 기술
보안 영역
웹 서버는 기밀문서를 보안 영역(realm) 그룹으로 나눈다. 보안 영역은 저마다 다른 사용자 권한을 요구한다.
#2. 기본 인증
기본 인증은 가장 잘 알려진 HTTP 인증 규약이다. 거의 모든 주요 클라이언트와 서버에 기본 인증이 구현되어 있다.
기본 인증에서 웹 서버는 클라이언트의 요청을 거부하고 유효한 사용자 이름과 비밀번호를 요구할 수 있다. 서버는 200 대신 401 상태 코드와 함께 클라이언트가 접근하려고 했던 보안 영역을 WWW-Authenticate에 기술해서 응답하여 인증 요구를 시작한다.
| 인증요구/응답 | 헤더 문법 |
| 인증요구 (서버에서 클라이언트로) | WWW-Authenticate: Basic realm=따음표로 감싼 문서집합 |
| 응답 (클라이언트에서 서버로) | Authorization: Basic base-64로 인코딩한 이름과 비밀번호 |
base-64 인코딩은 바이너리, 텍스트 국제 문자 데이터 문자열을 받아서 전송할 수 있게 그 문자열을 전송 가능한 문자인 알파벳으로 변환한다. 전송 중에 원본 문자열이 변질될 걱정 없이 원격에서 디코딩할 수 있다.
base-64 인코딩은 국제 문자나 HTTP 헤더에서 사용할 수 없는 문자(큰 따옴표, 콜론, 캐리지 리턴)를 포함한 사용자 이름이나 비밀번호를 보내야 할 때 유용할 수 있다.
#3. 기본 인증의 보안 결함
기본 인증은 단순하고 편리하지만 안심할 수는 없다. 기본 인증은 악의적이지 않은 누군가가 의도치 않게 리소스에 접근하는 것을 막는 데 사용하거나 SSL 같은 암호기술과 혼용한다.
- 기본 인증은 사용자 이름과 비밀번호를 쉽게 디코딩할 수있는 형식으로 네트워크에 전송한다.
- 재전송 공격을 예방하기 위한 처리가 이루어지지 않는다.
- 수많은 사람들이 같은 비밀번호를 사용한다. 악의적인 사람은 이러한 점을 이용해 중요한 사이트에 접근 시도한다.
- 트랜잭션의 본래 의도를 바꿔버리는 프락시나 중개자가 개입할 경우 기본 인증은 정상적인 동작을 보장 안 한다.
- 기본 인증은 가짜 서버의 위장에 취약하다.
#4. 다이제스트 인증
기본 인증은 편리하고 유연하지만 안전하지 않을 수 있다. 사용자 이름과 비밀번호를 평문으로 보내고 메시지를 위조하지 못하게 보호하려는 어떠한 시도도 하지 않는다. 기본 보안을 안전하게 이용하는 유일한 방법은 SSL과 결합해서 사용하는 것이다.
다이제스트 인증은 기본 인증과 호환되는 안전한 대체재로 개발되었지만 널리 쓰이지는 않는다. 다이제스트 인증이 가능한 가장 안전한 프로토콜은 아니다. 안전한 트랜잭션을 위한 많은 요구사항을 만족하지 못한다. 그러한 요구사항들에는 전송 계층 보안 (TLS)과 보안 HTTP (HTTPS)가 더 적합한 프로토콜이다.
다이제스트 인증의 개선점
- 비밀번호를 절대로 네트워크를 통해 평문으로 전송하지 않는다.
- 인증 체결을 가로채서 재현하려는 악의적인 사람들을 차단한다.
- 구현하기에 따라서 메시지 내용 위조를 막는 것도 가능하다.
- 그 외 몇몇 잘 알려진 형태의 공격을 막는다.
비밀번호를 안전하게 지키기 위해 요약 사용
다이제스트 인증은 절대로 비밀번호를 네트워크를 통해 보내지 않는다. 비밀번호를 보내는 대신 클라이언트는 비밀번호를 비가역적으로 뒤섞은 지문 혹은 요약(digest)을 보낸다.
단방향 요약
요약은 단방향 함수로 동작하고 일반적으로 입력 가능한 무한 가지의 모든 입력값들을 유한한 범위의 압축으로 변환한다. 비밀번호를 그대로 전송해야 할 문제로부터 해방시켜 준다.
재전송 방지를 위한 난스(nonce) 사용
악의적인 사람들은 비밀번호를 모른다 해도 요약을 가로채서 서버로 몇 번이고 재전송할 수 있다. 이러한 재전송 공격을 방지하기 위해 서버는 클라이언트에게 '난스'라고 하는 특별하고 자주 바뀌는 증표를 건네준다.
다이제스트 인증 핸스셰이크
다이제스트 인증 프로토콜은 기본 인증의 기존 헤더에 몇몇 새 옵션이 추가되었다. 선택적인 헤더인 Authorization-Info가 새로 추가되었다.
- 서버는 난스 값을 계산
- 서버는 난스를 WWW-Authenticate (인증요구) 메시지에 담아 클라이언트에게 전송
- 클라이언트는 알고리즘을 선택, 비밀번호와 그 외 데이터에 대한 요약을 계산
- 클라이언트는 Authorization(응답) 메시지에 요약을 담아 서버에게 전송
- 서버는 요약을 검증, rspauth 요약을 생성, 다음번 난스를 생성
- 서버가 다음번 난스를 보냄, 클라이언트 rspauth 요약을 보냄 (Authentication-Info 정보)
- 클라이언트가 rspauth 요약을 검증
#5. 보호 수준 향상
| 단계 | 기본인증 | 다이제스트 인증 |
| 인증요구 |
WWW-Authenticate: Basic realm="<영영 값>" |
WWW-Authenticate: Digest realm="<영역 값>" nonce="<난스 값>" |
| 응답 |
Authorization: Basic <base64 (user:pass)> |
Authorization: Digest username="<사용자 이름>" realm="<영역 값>" nonce="<난스 값>" uri=<요청 uri> |
| 정보 | 없음 |
Authentication-Info : nextnonce="<난스 값>" |
참고 자료
- HTTP완벽가이드 , 인사이트
'HTTP' 카테고리의 다른 글
| [HTTP] 엔터티와 인코딩 (0) | 2020.05.05 |
|---|---|
| [HTTP] 보안 HTTPS (0) | 2020.05.05 |
| [HTTP] 클라이언트 식별과 쿠키(Cookie) (0) | 2020.05.04 |
| [HTTP] HTTP/2.0 (0) | 2020.05.04 |
| [HTTP] 배포 시스템 : FrontPage와 WebDAV (0) | 2020.05.04 |
