[TIL] HTTP : The Definitive Guide "p286 ~ p288"

시윤·2025년 3월 24일

TIL http

[TIL] Two Pages Per Day

목록 보기

117/146

Chapter 13. Digest Authentication

(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)

✏️ 원문 번역

Preface

Basic authentication is convenient and flexible but completely insecure. Usernames and passwords are sent in the clear, and there is no attempt to protect messages from tampering. The only way to use basic authentication securely is to use it in conjunction with SSL.

Basic Authentication은 편리하고 유연하지만 안전하지 않습니다.
username과 password가 변조로부터 보호되지 않은 메시지로 투명하게 전송됩니다.
Basic Authentication을 안전하게 사용하기 위한 유일한 방법은 SSL과 결합하는 것입니다.

Digest authentication was developed as a compatible, more secure alternative to basic authentication. We devote this chapter to the theory and practice of digest authentication. Even though digest authentication is not yet in wide use, the concepts still are important for anyone implementing secure transactions.

Digest Authentication은 Basic Authentication과 호환되고 비교적 안전한 대안으로 고안되었습니다.
이번 챕터에서는 Digest Authentication의 이론과 실전 활용 방안에 대해 논하고자 합니다.
Digest Authentication은 아직 널리 사용되고 있지 않지만 안전한 트랜잭션을 구현하는 사람들에게 있어 여전히 중요한 개념을 담고 있습니다.

The Improvements of Digest Authentication

Digest authentication is an alternate HTTP authentication protocol that tries to fix the most serious flaws of basic authentication. In particular, digest authentication:

• Never sends secret passwords across the network in the clear

• Prevents unscrupulous individuals from capturing and replaying authentication handshakes

• Optionally can guard against tampering with message contents

• Guards against several other common forms of attacks

Digest Authentication은 Basic Authentication의 심각한 결함들을 보완하기 위해 등장한 HTTP 인증 프로토콜입니다.
Digest Authentication은 다음과 같은 특징을 가집니다.
- 비밀번호를 절대 네트워크상에 투명하게 전송하지 않습니다.
- 공격자가 Authentication Handshake를 캡처하거나 리플레이하는 것을 방지합니다.
- 선택적으로 메시지 콘텐츠가 변조되는 것을 막습니다.
- 그 밖의 일반적인 공격으로부터 보호합니다.

Digest authentication is not the most secure protocol possible.† Many needs for secure HTTP transactions cannot be met by digest authentication. For those needs, Transport Layer Security (TLS) and Secure HTTP (HTTPS) are more appropriate protocols.

Digest Authentication이 가장 안전한 프로토콜인 것은 아닙니다.
Digest Authentication이 HTTP 보안 트랜잭션에 대한 다양한 요구를 전부 충족할 수는 없습니다.
필요에 따라 Transport Layer Security(TLS)와 Secure HTTP(HTTPS)와 같은 적절한 프로토콜을 사용해야 합니다.

However, digest authentication is significantly stronger than basic authentication, which it was designed to replace. Digest authentication also is stronger than many popular schemes proposed for other Internet services, such as CRAM-MD5, which has been proposed for use with LDAP, POP, and IMAP.

그러나 Digest Authentication은 Basic Authentication을 대체하기 위해 고안되었다는 점에서 비교적 강력합니다.
심지어는 LDAP, POP, IMAP와 함께 사용하기 위해 고안된 CRAM-MD5와 같은 다른 인터넷 서비스에 대한 여러 인기 있는 기법들보다도 강력합니다.

To date, digest authentication has not been widely deployed. However, because of the security risks inherent to basic authentication, the HTTP architects counsel in RFC 2617 that “any service in present use that uses Basic should be switched to Digest as soon as practical.” It is not yet clear how successful this standard will become.

아직까지 Digest Authentication은 널리 구현되지 않았습니다.
하지만 Basic Authentication의 선천적인 보안 결함으로 인해 HTTP 설계자들은 RFC 2617에서 "Basic을 사용하는 현행 서비스는 빠른 시일 내로 Digest 방식으로 변환해야 함"을 권고하고 있습니다.
물론 얼마나 성공적인 표준이 될지는 아직 알 수 없습니다.

Using Digests to Keep Passwords Secret

The motto of digest authentication is “never send the password across the network.” Instead of sending the password, the client sends a “fingerprint” or “digest” of the password, which is an irreversible scrambling of the password. The client and the server both know the secret password, so the server can verify that the digest provided a correct match for the password. Given only the digest, a bad guy has no easy way to find what password it came from, other than going through every password in the universe, trying each one!

Digest Authentication의 모토는 "비밀번호를 네트워크를 통해 절대 전송하지 말자"입니다.
클라이언트는 비밀번호를 전송하는 대신 비밀번호에 대한 "fingerprint"나 "digest"를 전송합니다.
digest는 비밀번호를 비가역적으로 뒤섞은 형태입니다.
클라이언트와 서버는 모두 비밀번호를 알고 있으므로 비밀번호에 관한 digest가 일치하는지 검증할 수 있습니다.
digest가 주어진다면 공격자는 이 세상의 모든 비밀번호를 하나씩 시도해보지 않고서야 어떤 비밀번호가 들어오고 있는지 쉽게 유추할 수 없습니다.

Let’s see how this works (this is a simplified version):

이제 Digest Authentication이 어떻게 동작하는지 간단히 살펴봅시다.

• In Figure 13-1a, the client requests a protected document.

Figure 13-1a에서 클라이언트가 보호된 문서를 요청합니다.

• In Figure 13-1b, the server refuses to serve the document until the client authenticates its identity by proving it knows the password. The server issues a challenge to the client, asking for the username and a digested form of the password.

Figure 13-1b에서 서버는 클라이언트가 비밀번호를 알고 있다는 사실을 인증하기 전까지 문서를 제공하지 않습니다.
서버는 클라이언트에게 Challenge를 발행하여 username과 digested 양식의 password를 요구합니다.

• In Figure 13-1c, the client proves that it knows the password by passing along the digest of the password. The server knows the passwords for all the users, so it can verify that the user knows the password by comparing the client-supplied digest with the server’s own internally computed digest. Another party would not easily be able to make up the right digest if it didn’t know the password.

Figure 13-1c에서 클라이언트는 password의 digest를 전달함으로써 비밀번호를 알고 있다는 사실을 증명합니다.
서버는 모든 사용자에 대한 비밀번호를 알고 있습니다.
클라이언트로부터 전달받은 digest를 서버가 내부적으로 연산한 digest 값과 비교하여 사용자가 비밀번호를 알고 있는지 확인할 수 있습니다.
제삼자는 password가 무엇인지 알지 못하는 한 올바른 digest를 쉽게 만들어낼 수 없습니다.

• In Figure 13-1d, the server compares the client-provided digest with the server’s internally computed digest. If they match, it shows that the client knows the password (or made a really lucky guess!). The digest function can be set to generate so many digits that lucky guesses effectively are impossible. When the server verifies the match, the document is served to the client—all without ever sending the password over the network.