기본 인증, 인코딩 : 기본 인증 보안 고려사항

- 기본 인증(Basic Authentication)의 보안적 한계

- HTTPS가 왜 필수인지, 암호화되지 않은 통신의 위험

- 자격 증명(username:password) 노출 위험성

- 현대 웹 애플리케이션에서 왜 Basic Auth가 거의 쓰이지 않는가

- 대안적 인증 방식(JWT, OAuth 등)

---

HTTP의 필요성

1. HTTP와 HTTPS의 차이

구분	HTTP	HTTPS
전송방식	평문(암호화가 없음)	TLS/SSL로 암호화
보안수준	낮음(도청, 변조가능)	높음(도청, 위변조 방지)
포트	80	443

 

* HTTP로 Basic Auth를 사용하면 Authorization 헤더가 그대로 노출됨

* HTTPS는 전송 구간을 암호화하여 중간에서 패킷을 보더라도 내용을 알 수 없음

 

 

2. HTTPS 내부 동작

• 클라이언트 Hello : 브라우저가 서버에 "HTTPS로 통신하겠다"고 신호를 보냄 
• 서버 Hello + 인증서 : 서버는 사용할 암호화 방식을 고르고, 자신이 신뢰할 수 있는 서버임을 증명하는 디지털 인증서를 보냄(공개키 포함)
• 키 교환 : 브라우저는 서버의 공개키로 임시 대칭키(세션 키)를 암호화해서 전달한다
• 세션 키 확립 : 서버는 개인키로 이를 복호화하여 같은 대칭키를 얻음
• 대칭키 암호화 통신 시작 : 이후 모든 HTTP 요청/응답은 이 대칭키로 암호화되어 전송됨

 

다이어그램

 

HTTPS 인증 다이어그램

 

 

3. 실생활에서

HTTP : 우편엽서에 주소와 내용, 비밀번호까지 다 써서 보내는 것

HTTPS : 봉투에 넣어서 봉인 후 보내는 것. 중간에 보더라도 내용은 알 수 없음

HTTP와 HTTPS의 차이

---

자격 증명 노출 위험성

2번째 고려사항, 자격 증명 노출 위험성

1. Base64는 암호화가 아니다

Base64는 단순한 인코딩일 뿐, 누구나 쉽게 디코딩 할 수 있음

따라서 Authorization 헤더를 훔치면, 즉시 username:password 를 알 수 있음

 

 

2. 공격 시나리오

• 사용자가 HTTP로 로그인 요청을 보냄
• 네트워크상에서 패킷이 그대로 노출됨
• 공격자가 패킷을 캡처해서 Authorization 헤더를 획득함
• Base64 디코딩 -> 즉시 평문 ID/PW 획득

---

현대 웹 애플리케이션에서의 활용 여부

1. 왜 Base64가 잘 안쓰이나?

- 매 요청마다 ID/PW 전체를 보내는 구조라서 매우 위험함

- 세션/토큰 기반 인증이 더욱 안전하고 효율적

- 브라우저 기본 다이얼로그를 쓰는 UX 또한 좋지 않다

 

 

2. 그럼 어디서 쓰임?

- 내부 시스템, 테스트용 API, 간단한 인증에만 제한적으로 사용된다

- 운영 서비스에서는 권장되지 않음

 

 

3. 대안들

방식	특징
세션 기반 인증	서버가 세션 ID를 관리함, 쿠키 기반 인증
토큰 기반 인증(JWT)	클라이언트가 토큰을 보관함
OAuth2.0	제3자 서비스 인증(구글, 네이버 로그인 등)

 

 

팁

* Basic Auth를 꼭 써야 한다면, 반드시 HTTPS 위에서만 사용함

* 운영 서비스에서는 가능하다면 세션/토큰 기반 인증으로 설계하기

* API 보안에는 API key + HTTPS, 혹은 Bearer Token을 권장한다

---

정리

항목	설명
Basic Auth의 한계	ID/PW를 매 요청마다 평문으로 전송함
HTTPS의 필요성	전송 구간 암호화, 도청/위변조 방지
노출 위험성	패킷 캡처 -> Base64 디코딩으로 즉시 탈취
활용 여부	운영 서비스에는 권장되지 않음 내부용/테스트용으로 제한함
대안	세션, JWT, OAuth 등 현대적 방식이 있음