Fallback으로 Basic Auth가 선택되면 – 보안은 안전할까?

로그에서 확인된 fallback으로 해당 문제점에 대해 알아봅시다.

들어가며

사실 처음에는 별다른 생각이 없었습니다. 단순히 로그에 기록된 디버그 메시지 하나쯤으로 여겼습니다. 로그에는 Challenge for Negotiate authentication scheme not available라는 메시지가 남아 있었습니다. Challenge라는 용어 자체는 알고 있었지만, 실제 인증 흐름 속에서 마주친 것은 이번이 처음이었습니다.

이 로그가 출력된 맥락은 이 글의 초점과 직접 관련이 없어 생략합니다.

[클라이언트] ── 요청 ──────────────▶ [서버]
[클라이언트] ◀─ 401 Unauthorized, WWW-Authenticate: Negotiate ─ [서버] (Challenge)
[클라이언트] ── Authorization: (인증정보) ───▶ [서버]
[클라이언트] ◀─ 200 OK ────────────── [서버] (인증 성공)

이것이 바로 인증 과정에서 말하는 Challenge입니다. 이번 이슈는 서버가 보낸 Challenge를 클라이언트가 정상적으로 처리하지 못해서 발생한 것이었습니다.

인증 흐름 분석

• 서버는 SPNEGO 기반의 Negotiate 인증을 요구합니다.
• 클라이언트는 Kerberos와 NTLM 인증 등의 인증방법을 순차적으로 시도합니다.
• 클라이언트가 이 인증 방식들을 모두 처리할 수 없거나 인증이 실패하면, 최종적으로는 Basic Auth 방식으로 fallback되어 인증을 다시 시도합니다.

🔓인증 정보 전송 구조와 보안 리스크

클라이언트에서 사용하는 username/password는
프로퍼티 파일 내에서 암호화 라이브러리를 사용해 암호화된 형태로 저장되고 있었습니다.
저장 시점에서는 평문 노출 없이 안전하게 관리되고 있었던 셈입니다.

다만 애플리케이션 실행 시 이 값은 복호화되어 사용되고,
Basic Auth 방식으로 요청을 보낼 때는
base64로 인코딩된 형태로 Authorization 헤더에 포함되어 전송됩니다.

이러한 동작은 단순한 구현 관행이 아닌, HTTP Basic Authentication 공식 명세 (RFC 7617) 에 명시된 동작입니다. 따라서 대부분의 언어나 HTTP 라이브러리가 기본적으로 이 방식으로 동작합니다.

문제는 TLS가 적용되지 않은 상태라면 이 값은 네트워크 상에서 평문처럼 노출될 수 있는 구조이고,
특히 같은 네트워크에 위치한 공격자(중간자)가 Promiscuous 모드로 패킷을 감청하고 있다면, 자신을 목적지로 하지 않는 패킷도 수신할 수 있기 때문에 인증 정보가 그대로 노출될 수 있습니다.

이 fallback이 단순한 예외 처리가 아니라, 실제 보안 리스크로 이어질 수 있는 가능성을 내포하고 있는 셈입니다.

HTTP Basic Auth 인증정보는 네트워크에서 어떻게 보일까?

앞서 언급했던 인증 방식이 실패했을 때 fallback되어 Basic 인증으로 전환되면 어떤 보안적 위험이 발생할 수 있을까요?

이번 실험은 Negotiate 인증(Challenge) 자체의 세부 동작보다는, 최종적으로 Basic Auth로 fallback되었을 때 인증 정보가 얼마나 쉽게 노출될 수 있는지를 직접 확인하기 위해 진행하였습니다.

---

🔧 실험 구성

• FastAPI로 구성한 테스트 서버 (Gunicorn, HTTP로 동작, 포트 8000)
• 로컬 PC에서 인증 헤더를 포함한 요청 전송
• Wireshark를 통해 요청 패킷을 실시간 캡처 및 분석
• curl 명령어를 이용하여 Authorization 헤더를 명시적으로 추가해 요청 전송

요청 명령어:

curl -H "Authorization: Basic dGVzdHVzZXI6dGVzdHBhc3M=" http://SERVER_PUBLIC_IP:8000

---

🔎 Wireshark 캡처 결과

Wireshark로 실험 패킷을 분석한 결과, 요청에 포함된 Authorization: Basic ... 헤더가 자동 디코딩되어 Credentials: testuser:testpass 형태의 평문 인증 정보로 표시되는 것을 확인할 수 있었습니다.

즉, TLS가 적용되지 않은 HTTP 환경에서는 네트워크를 통해 오가는 패킷만 감청할 수 있다면, 인증 정보가 손쉽게 노출될 수 있습니다.

실험 결과 요약

• Basic 인증 헤더는 단지 Base64로 인코딩될 뿐, 암호화되지 않습니다.
• 내부망/공용망 관계없이 HTTP는 인증 정보 탈취 위험이 존재합니다.

✅ 이번 실험을 통해, fallback으로 인해 Basic 인증이 선택될 수 있다는 점과
그런 상황에서 TLS 적용이 얼마나 중요한지를 실감할 수 있었습니다.
특히 TLS 인증서가 만료되거나 적용되지 않은 상태에서는
인증 정보가 쉽게 노출될 수 있다는 점에서,
Basic Auth는 반드시 HTTPS 환경에서만 사용되어야 한다는 원칙을 다시 확인하게 되었습니다.

마무리하며

처음에는 간단한 로그 메시지 하나에서 시작된 일이었습니다. 하지만 직접 패킷을 추적하고 인증 흐름을 분석해가며, 인증 구조와 그 이면에 있는 보안 리스크를 명확하게 이해할 수 있었습니다.

사실 그동안 책이나 문서로만 접했던 인증의 Challenge라는 개념도 이번 경험을 통해 실제 인증 과정과 명확히 연결할 수 있었습니다.

개발자로서 보안이라는 분야를 공부하면서 “어디까지 알아야 하는 걸까?” 하는 고민이 있었던 것도 사실입니다. 하지만 애초에 제가 보안 공부를 시작한 이유는 IT 전반에 대해 더 깊고 폭넓게 이해하고 싶었기 때문입니다.

직접 로그를 분석하고 네트워크 패킷을 살펴보면서,

“TLS가 왜 필수인지”
“fallback이라는 간단한 동작이 어떻게 실제 보안 위협으로 연결되는지”

실제 사례를 통해 생생하게 깨닫는 순간, 그동안의 공부가 헛되지 않았음을 느꼈습니다.

꼭 보안 전문가가 되지 않더라도, 이렇게 실무 경험을 글로 기록하고 정리하는 과정 자체가 개발자로서 성장하는 제 자신에게 매우 의미 있는 한 걸음이라 생각합니다.

---

이 글은 제가 실제 경험한 내용을 바탕으로 작성했습니다. 혹시 다른 시각이나 보완할 점이 있다면 언제든 편하게 알려주시기 바랍니다.