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

시윤·2025년 3월 25일

TIL http

[TIL] Two Pages Per Day

목록 보기

118/146

Chapter 13. Digest Authentication

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

✏️ 원문 번역

One-Way Digests

A digest is a “condensation of a body of information.” Digests act as one-way functions, typically converting an infinite number of possible input values into a finite range of condensations. One popular digest function, MD5, converts any arbitrary sequence of bytes, of any length, into a 128-bit digest.

digest는 본문의 정보를 압축하여 표현한 형태입니다.
보통 입력 값으로 들어올 수 있는 모든 숫자를 유한한 범위로 압축하기 위한 단방향 함수를 나타냅니다.
가장 널리 사용되는 digest 함수는 MD5입니다.
MD5는 임의의 길이를 가진 바이트 시퀀스를 128비트의 digest로 변환합니다.

128 bits = 2^128, or about 1,000,000,000,000,000,000,000,000,000,000,000,000,000 possible distinct condensations.

128비트는 2의 128제곱을 의미합니다.
즉 1,000,000,000,000,000,000,000,000,000,000,000,000,000개의 달하는 이형이 존재할 수 있습니다.

What is important about these digests is that if you don’t know the secret password, you’ll have an awfully hard time guessing the correct digest to send to the server. And likewise, if you have the digest, you’ll have an awfully hard time figuring out which of the effectively infinite number of input values generated it.

digest에서 중요한 것은 비밀번호를 정확히 알지 못하면 서버에 전송할 올바른 digest를 추측하기가 매우 어렵다는 점입니다.
마찬가지로 digest가 있더라도 무한한 입력값 중에서 어떤 값이 digest를 생성했는지 알아내기가 매우 어렵습니다.

The 128 bits of MD5 output often are written as 32 hexadecimal characters, each character representing 4 bits. Table 13-1 shows a few examples of MD5 digests of sample inputs. Notice how MD5 takes arbitrary inputs and yields a fixed-length digest output.

일반적으로 MD5의 128비트 출력값은 32개의 16진수 문자로 표현됩니다. 16진수에서 각각의 문자는 4비트를 나타냅니다.
Table 13-1은 예제 입력에 관한 MD5 digest 결과를 나타냅니다.
MD5가 임의의 입력을 고정 길이의 digest 출력을 생성하는 방법에 주목해봅시다.

Digest functions sometimes are called cryptographic checksums, one-way hash functions, or fingerprint functions.

Digest 함수는 Cryptographic Checksum(암호화 체크섬), 단방향 해시함수, 핑거프린트 함수라고도 합니다.

Using Nonces to Prevent Replays

One-way digests save us from having to send passwords in the clear. We can just send a digest of the password instead, and rest assured that no malicious party can easily decode the original password from the digest.

단방향 digest는 비밀번호를 투명하게 정보하는 것을 방지합니다.
대신 비밀번호의 digest만을 전송하며, 악의적인 제삼자가 digest로부터 쉽게 원본 비밀번호를 디코딩하지 못할 것이라고 안심할 수 있습니다.

Unfortunately, obscured passwords alone do not save us from danger, because a bad guy can capture the digest and replay it over and over again to the server, even though the bad guy doesn’t know the password. The digest is just as good as the password.

하지만 비밀번호를 숨기는 것만으로는 모든 위험으로부터 안전할 수 없습니다.
공격자가 비밀번호를 알지 못하더라도 digest를 캡처하여 서버에 지속적인 리플레이 공격을 수행할 수 있기 때문입니다.
digest도 비밀번호만큼 중요합니다.

To prevent such replay attacks, the server can pass along to the client a special token called a nonce, which changes frequently (perhaps every millisecond, or for every authentication). The client appends this nonce token to the password before computing the digest.

리플레이 공격을 방지하기 위해 서버는 클라이언트에게 특별한 토큰인 nonce를 전송할 수 있습니다.
nonce는 빠른 주기로(밀리초, 혹은 인증이 수행될 때마다) 변화합니다.
클라이언트는 비밀번호에 nonce 토큰을 추가한 후 digest를 연산합니다.

Mixing the nonce in with the password causes the digest to change each time the nonce changes. This prevents replay attacks, because the recorded password digest is valid only for a particular nonce value, and without the secret password, the attacker cannot compute the correct digest.

비밀번호와 nonce를 결합한다는 것은 nonce가 변화할 때마다 digest 값도 함께 변화한다는 것을 의미합니다.
저장된 비밀번호 digest가 특정한 nonce 값에 대해서만 유효하기 때문에 리플레이 공격을 방지할 수 있습니다.
공격자는 비밀번호 없이 올바른 digest를 연산할 수 없게 됩니다.

Digest authentication requires the use of nonces, because a trivial replay weakness would make un-nonced digest authentication effectively as weak as basic authentication. Nonces are passed from server to client in the WWW-Authenticate challenge.

사소한 리플레이 취약점이 nonce를 사용하지 않는 Digest Authentication을 Basic Authentication만큼이나 취약하게 만들 수 있습니다.
그러므로 Digest Authentication에서는 nonce를 사용해야 합니다.
nonce는 WWW-Authenticate Challenge를 통해 서버에서 클라이언트로 전달됩니다.

The Digest Authentication Handshake

The HTTP digest authentication protocol is an enhanced version of authentication that uses headers similar to those used in basic authentication. Some new options are added to the traditional headers, and one new optional header, Authorization-Info, is added.

HTTP Digest Authentication 프로토콜은 Basic Authentication에서 사용되는 헤더와 유사한 헤더를 사용하는 개선된 버전의 인증 방식입니다.
기존의 헤더에 몇 가지 선택사항이 추가되었으며 선택적인 헤더로 Authorization-Info가 새롭게 추가되었습니다.

The simplified three-phase handshake of digest authentication is depicted in Figure 13-2.

Digest Authentication의 3단계에 거친 Handshake 과정을 Figure 13-2에서 간단히 설명하고 있습니다.

Here’s what’s happening in Figure 13-2:

Figure 13-2의 동작 과정을 함께 살펴봅시다.

• In Step 1, the server computes a nonce value. In Step 2, the server sends the nonce to the client in a WWW-Authenticate challenge message, along with a list of algorithms that the server supports.

Step 1에서 서버는 nonce 값을 계산합니다.
Step 2에서 서버가 클라이언트에게 nonce를 전송합니다. nonce는 Challenge 메시지의 WWW-Authenticate 헤더에 포함되어 서버가 지원하는 알고리즘 목록과 함께 전송됩니다.

• In Step 3, the client selects an algorithm and computes the digest of the secret password and the other data. In Step 4, it sends the digest back to the server in an Authorization message. If the client wants to authenticate the server, it can send a client nonce.

Step 3에서 클라이언트는 특정 알고리즘을 선택하여 비밀번호와 기타 데이터에 관한 Digest를 연산합니다.
그리고 Step 4에서 Authorization 메시지를 통해 서버에게 digest를 전송합니다.
클라이언트가 서버의 인증을 요구하는 경우 클라이언트 또한 nonce를 전송할 수 있습니다.

• In Step 5, the server receives the digest, chosen algorithm, and supporting data and computes the same digest that the client did. The server then compares the locally generated digest with the network-transmitted digest and validates that they match. If the client symmetrically challenged the server with a client nonce, a client digest is created. Additionally, the next nonce can be precomputed and handed to the client in advance, so the client can preemptively issue the right digest the next time.

Step 5에서 서버는 digest, 선택된 알고리즘, 추가적인 데이터(ex. 해시 계산에 함께 사용되는 값) 등을 받습니다.
그리고 클라이언트가 수행한 것과 동일한 digest를 연산합니다.
서버는 로컬에서 생성한 digest와 네트워크를 통해 전달받은 digest를 비교한 후 서로 일치하는지 확인합니다.
만약 클라이언트가 nonce를 가지고 서버에게 대칭으로 Challenge를 요청했다면 client digest가 형성됩니다.
더불어 다음 nonce를 미리 연산한 후 클라이언트에 전달함으로써 해당 클라이언트가 다음 번에 올바른 digest를 선제적으로 발행할 수 있게 합니다.

Many of these pieces of information are optional and have defaults. To clarify things, Figure 13-3 compares the messages sent for basic authentication (Figure 13-3a–d) with a simple example of digest authentication (Figure 13-3e–h).

위의 정보 중 일부는 선택적이며 일부는 기본값일 수 있습니다.
Figure 13-3은 Basic Authentication을 통해 전송되는 메시지(Figure 13-3a-d)와 Digest Authentication(Figure 13-3e-h)의 예시를 비교하여 명확하게 설명합니니다.

Now let’s look a bit more closely at the internal workings of digest authentication.

이제 Digest Authentication의 내부 동작에 대해 조금 더 자세히 알아봅시다.

✏️ 요약

One-way Digests

: 단방향 함수를 통해 데이터를 유한한 범위로 압축한 형태

MD5 : 임의의 길이를 가진 바이트 시퀀스를 128비트의 값으로 변환하는 단방향 해시함수
단방향 함수의 특성상 원본 입력값을 알아내기 어려움
Digest 생성에 사용되는 함수를 Cryptographic Checksum, 단방향 해시함수, 핑거프린트 함수라고도 함

Nonces

: 리플레이 공격을 방지하기 위해 digest를 생성하기 전 비밀번호에 추가하는 특수 토큰

nonce가 변화할 때마다 digest 값도 함께 변화
서버는 로컬에서 생성한 digest와 네트워크를 통해 전달받은 digest를 비교한 후 서로 일치하는지 확인
- WWW-Authenticate : 서버가 생성한 nonce를 클라이언트에 전달
- cnonce(client nonce) : 클라이언트와 서버간 안전한 통신을 위해 사용하는 값(재전송이 발생하면 동일한 cnonce 값이 전송 -> 재전송 식별 가능)
- Authorization-Info : 다음 nonce를 미리 전달 -> 클라이언트가 우선적으로 올바른 digest를 생성할 수 있도록 도움

✏️ 감상

그저께 nonce를 찾아봤었다

https://velog.io/@dvlp-sy/TIL-HTTP-The-Definitive-Guide-p283-p284#replay

며칠 전 TIL을 작성하면서 리플레이 공격에 관한 대응 방안을 찾아보면서 nonce에 대해 간단히 정리한 내용이 있다. 여기서 설명하는 nonce는 비밀번호에 결합되는 nonce가 아니라 클라이언트에서 전송하는 cnonce에 해당한다. nonce 값의 중복 여부 확인을 통해 리플레이 여부를 확인하는 것이다. 하지만 digest를 생성하기 전 비밀번호에 덧붙이는 문자열도 nonce라고 한다는 것은 오늘 글을 읽으면서 처음 알게 되었다..! 아무래도 nonce보다는 salt라는 이름으로 더 익숙했던 탓이다.

nonce와 salt는 뭐가 다를까

Stack Overflow에 비슷한 의문을 가진 사람이 있어 답변을 긁어왔다.

대충 해석을 해보자면 salt는 평문이 동일한 출력값으로 해싱되지 않도록 원본 데이터에 덧붙이는 값이다. 레인보우 테이블을 통해 원본 비밀번호를 유추할 수 없도록 방지하기 위해 사용한다. nonce는 리플레이 공격을 방지하기 위해 일정 기간이나 세션 내에서 고유한 값을 표현하기 위해 사용되는 데이터다.

음 사실 읽어도 뭐가 다른 건지 잘 모르겠다. 그냥 의도의 차이인가...?

digest를 생성하는 데 사용되는 nonce는 위에서 설명한 nonce로써의 의미도 가지고 있고, salt로써의 의미도 가지고 있는 것으로 보인다. nonce를 사용하지 않는 Digest Authentication은 리플레이 공격에도 취약하지만, 같은 비밀번호가 항상 같은 digest로 해싱되므로 어느 정도 원본 값을 유추할 수 있다는 것도 문제다. 거기다 Hash Collision을 활용하면 원본 값을 같은 digest로 해싱되는 다른 값으로 대치할 수 있어 보안상 위험할 수 있다. 요즘에는 컴퓨터 성능이 좋아서,, 단방향 해시를 써도 간파당하는 세상이다.

하 보안공부 열심히 해야겠다 😝