title: HTTP The Definitive Guide - 12. Basic Authentication
date: 2022-12-05
tags:
- Network
- HTTP
Introduction
GDSC에서 해당 서적을 통해 HTTP를 공부하는 스터디에 참가하고 있다.
HTTP 이전의 내용은 개인적으로 공부하며 채울 예정이다.
이번 Chapter는 12장 Basic Authentication
이다.
Purpose
Network에서의 인증 및 Basic Authentication에 대해 알아본다.
Authentication
인증은 간단히 말하자면 Server에게 자신이 어떤 유저인지 식별하는 것이다.
오프라인에서는 주민등록증, 운전면허증, 여권 등을 이용하여 자신이 누구인지 식별할 수 있다.
하지만 도난의 위험이 있기에 이러한 것들이 언제나 자신이 누구인지 식별해주지 않는다.
Network에서의 인증 또한 충분한 정보를 제공해야 자신이 어떤 유저인지 식별할 수 있다.
HTTP's Challenge/Response Authentication Framework
HTTP는 Challenge/Response Framework를 제공한다. 위 그림은 간단한 Challenge/Response Authentication이다.
Server는 Request에 알맞은 작업을 수행할 수도 있으며, 인증이 필요할 경우 필요한 정보를 요구하기도 한다.
Client에서 제공한 정보가 올바르지 않을 경우 인증에 실패하여 요청한 Request를 처리하지 않고 Error가 발생한다.
Authentication Protocol and Header
HTTP를 이용할 때 Customized Control Header를 이용하여 다른 Authentication Protocol을 위한 Framework를 제공한다.
위 표는 4개의 Phase로 구분된 Authentication이며, 이는 Protocol에 따라 다를 수 있다.
- Request Phase - Server에 Request하는 것으로, 이때는 Authentication이 존재하지 않는다.
- Challenge Phase - Request를 처리하기 위해 유저를 식별해야 할 경우, Status Code 401 Unauthorized와 함께 인증에 필요한 정보를 요청한다.
- Authorization Phase - Client는 인증에 필요한 정보를 포함하여 다시 Request한다.
- Success Phase - 인증에 성공할 경우, Server는 Request를 올바르게 처리한다.
4개의 Phase를 보다 직관적으로 이해하기 위한 그림이다.
위 그림에서는 Status 401이 Authorization Required로 적혀있으나, 실제로는 Unauthorized를 더 많이 이용하는 것으로 보인다.
HTTP에서 공식적으로 지원하는 두 가지의 Protocol은 Basic Authentication과 Digest Authentication이다.
본 Chapter에서 Basic Authentication에 대해 자세히 다루며, Digest Authentication은 Chapter 13에서 자세히 다룬다.
Security Realm
Server에는 다양한 Resource가 존재하며, 각각 다른 유저에게 허용될 수 있다.
이러한 것들을 관리하기 위해 권한에 따라 Resource를 묶어 Security Realm으로 구성된다.
이전 Phase에서 jeff.png를 이용할 때 Realm Directive는 family로 명시되었다.
위 사진과 같이 family Realm에 해당하는 유저 정보가 제공되어야 해당 Realm의 Resource를 이용할 수 있다.
sales-forecast.xls를 이용할 경우, Basic realm="Corporate Financials"와 같이 나열된다.
Basic Authentication
Basic Authentication은 가장 일반적인 HTTP Authentication Protocol이다.
HTTP 1.0에서 정의되었으나 RFC 2617에서 더욱 상세한 내용과 함께 재정의되었다.
지금까지 예시로 살펴보았던 Authentication 모두 Basic Authentication이다.
Base64 Encoding
Basic Authentication에서 Username와 Password를 이용할 경우, 두 항목을 :
으로 구분하여 나열한 후 Base64 Encoding이 이루어진다.
Base64 Encoding은 Binary로 표현된 데이터를 문자열 방식으로 전달할 수 있다.
ASCII에서는 사용할 수 없는 문자들이 있는 반면, Base64는 6Bits를 이용하여 큰 문제 없이 Encoding할 수 있다.
8Bits로 표현하던 것을 6Bits로 표현하기에 약 33%의 길이가 증가하는 문제가 존재한다.
다만 Base64로 Encoding된 문자열의 경우, 원본 데이터가 무엇인지 식별하기 어렵기에 어떠한 유형의 데이터인지 명시하여 이용하는 편이다.
Proxy Authentication
지금까지는 Server에서 진행하는 Authentication에 대해 다루었으나, Proxy에서도 Authentication이 가능하다.
이 경우 Proxy에서 Authentication을 담당하기에 조직의 각 서비스에서 Authentication을 다루는 것보다 편하게 처리할 수 있다.
인증 절차는 Server와 동일하나, Authentication에 이용되는 Header는 조금 다르다.
The Security Flaw of Basic Authentication
Basic Authentication은 간단하고 편하지만 안전하지 않다.
악의적인 접근을 막거나 SSL과 같은 보안 기술을 이용할 경우에만 Basic Authentication을 이용해야 한다.
- Client에서 Server로 인증에 필요한 정보를 보낼 때, 누구나 해당 정보를 조회할 수 있다. 개인 정보 탈취의 위험이 있기에 SSL과 같은 기술을 이용하거나 Digest Authentication과 같이 훨씬 안전한 Authentication Protocol을 이용해야 한다.
- 인증에 필요한 정보가 암호화되더라도 이를 이용할 수 있다. 정확한 정보를 알 수 없더라도 이를 그대로 이용하면 인증에 성공할 것이다.
- Intranet이나 개인화된 Content와 같이 중요하지 않은 곳에서 이용하더라도 문제가 발생할 수 있다. 유저들은 일반적으로 같은 Username과 Password를 여러 Site에서 이용한다. 이를 탈취한다면 다른 Site에서 악의적으로 이용될 수도 있다.
- Proxy와 같이 무언가가 중개할 때, 인증 정보를 그대로 이용하되 다른 Resource를 요청하는 악의적인 행동이 가능하다.
- Spoofing에 취약하다. 유저는 올바른 Site를 이용하고 있다고 생각하더라도, 실제로는 악의적인 Site를 이용할 수도 있다. 이를 알아채지 못한다면 중요한 정보를 그대로 넘겨주게 될 수도 있다.
문제들을 종합한다면, Basic Authentication은 중요한 정보를 인증에 이용하지 않는 곳에서는 유용하게 이용할 수 있다.
SSL과 같은 보안 기술을 통해 Basic Authentication을 안전하게 이용할 수 있다. 일반적으로 사용하는 기법이다.
Conclusion
Network에서의 인증과 Basic Authentication에 대해 알아보았다.
현업에서는 Basic Authentication에 SSL을 섞는 것으로는 충분하지 않을 것이다.
인증에 대해서는 더 많은 학습이 필요하다.
'Network' 카테고리의 다른 글
HTTP The Definitive Guide - 13. Digest Authentication (0) | 2022.12.12 |
---|---|
HTTP The Definitive Guide - 11. Client Identification and Cookie (0) | 2022.12.04 |
HTTP The Definitive Guide - 10. HTTP-NG (0) | 2022.12.01 |
HTTP The Definitive Guide - 09. Web Robots (0) | 2022.11.30 |
HTTP The Definitive Guide - 08. Integration Points: Gateways, Tunnels, and Relays (0) | 2022.11.23 |