Chapter 13. Digest Authentication
(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)
✏️ 원문 번역
Digest Authentication Session
The client response to a WWW-Authenticate challenge for a protection space starts an authentication session with that protection space (the realm combined with the canonical root of the server being accessed defines a “protection space”).
-
보호 공간에 대한 WWW-Authenticate Challenge에 대한 클라이언트의 응답은 해당 보호 공간과의 인증 세션을 작동시킵니다.
-
접근중인 서버의 root와 결합된 영역이 "보호 공간"을 정의합니다.
The authentication session lasts until the client receives another WWW-Authenticate challenge from any server in the protection space. A client should remember the username, password, nonce, nonce count, and opaque values associated with an authentication session to use to construct the Authorization header in future requests within that protection space.
-
인증 세션은 클라이언트가 보호 공간의 모든 서버로부터 또다른 WWW-Authenticate Challenge를 요구받을 때까지 유지됩니다.
-
클라이언트는 username, password, nonce, nonce count, 불투명 값 등 인증 세션과 연관된 정보를 유지하고 있어야 합니다.
-
보안 공간에 대한 추후 요청에 대비하여 Authorization 헤더를 구축하기 위함입니다.
When the nonce expires, the server can choose to accept the old Authorization header information, even though the nonce value included may not be fresh. Alternatively, the server may return a 401 response with a new nonce value, causing the client to retry the request; by specifying “stale=true” with this response, the server tells the client to retry with the new nonce without prompting for a new username and password.
-
nonce가 만료되면 서버는 nonce 값이 최신이 아닐지라도 과거의 Authorization 헤더 정보를 승인할지 말지 선택할 수 있습니다.
-
다른 방법으로 서버는 새로운 nonce 값을 담은 401 응답을 반환할 수도 있습니다.
-
이 응답은 클라이언트가 요청을 재전송하도록 요구합니다.
-
서버는 응답상에 "stale=true"를 명시함으로써 클라이언트에게 username과 password를 새로 입력받을 필요없이 새로운 nonce를 사용하여 요청을 재전송할 수 있게 합니다.
Preemptive Authorization
In normal authentication, each request requires a request/challenge cycle before the transaction can be completed. This is depicted in Figure 13-4a.
-
일반적인 인증 과정에서 각각의 요청은 request/challenge 사이클을 수행하여 트랜잭션을 완료해야 합니다.
-
Figure 13-4a에서 해당 내용을 확인할 수 있습니다.
This request/challenge cycle can be eliminated if the client knows in advance what the next nonce will be, so it can generate the correct Authorization header before the server asks for it. If the client can compute the Authorization header before it is requested, the client can preemptively issue the Authorization header to the server, without first going through a request/challenge. The performance impact is depicted in Figure 13-4b.
-
만약 클라이언트가 다음 nonce의 값을 미리 알 수 있다면 서버가 요청하기 전에 미리 올바른 Authorization 헤더를 생성할 수 있으므로 request/challenge 사이클을 제거할 수 있습니다.
-
요청이 오기 전에 Authorization 헤더를 미리 연산할 수 있는 클라이언트는 request/challenge를 거치지 않고 서버에 대한 Authorization 헤더를 선제적으로 발행할 수 있습니다.
-
성능상의 영향은 Figure 13-4b에서 확인할 수 있습니다.
Preemptive authorization is trivial (and common) for basic authentication. Browsers commonly maintain client-side databases of usernames and passwords. Once a user authenticates with a site, the browser commonly sends the correct Authorization header for subsequent requests to that URL (see Chapter 12).
-
선제적인 인증 방식은 Basic Authentication에서 일반적으로 적용됩니다.
-
브라우저는 일반적으로 클라이언트측에 username 및 password 데이터베이스를 유지하고 있습니다.
-
사용자가 사이트에 인증하면 브라우저가 특정 URL에 대한 요청에 적절한 Authorization 헤더를 삽입하여 전송합니다.
Preemptive authorization is a bit more complicated for digest authentication, because of the nonce technology intended to foil replay attacks. Because the server generates arbitrary nonces, there isn’t always a way for the client to determine what Authorization header to send until it receives a challenge.
-
Digest Authentication에서는 선제적인 인증이 조금 더 복잡할 수 있습니다.
-
리플레이 공격을 차단하기 위한 nonce 기술이 추가되었기 때문입니다.
-
서버가 임의의 nonce를 생성하기 때문에 Challenge를 받기 전까지 클라이언트가 어떤 Authorization을 전송할지 결정할 수 있는 방법이 항상 있지 않습니다.
Digest authentication offers a few means for preemptive authorization while retaining many of the safety features. Here are three potential ways a client can obtain the correct nonce without waiting for a new WWW-Authenticate challenge:
• Server pre-sends the next nonce in the Authentication-Info success header.
• Server allows the same nonce to be reused for a small window of time.
• Both the client and server use a synchronized, predictable nonce-generation algorithm.
-
Digest Authentication은 보안 특성을 그대로 유지하면서 선제적인 인증 방식을 구현하기 위한 몇 가지 수단을 추가로 제공합니다.
-
클라이언트가 새로운 WWW-Authenticate Challenge를 기다리지 않고 적절한 nonce를 포함하기 위한 세 가지 대책이 있습니다.
- 서버가 Authentication-Info 헤더에 다음 nonce를 미리 전송하는 방안
- 서버가 짧은 시간 내에 동일한 nonce를 재사용할 수 있도록 허용하는 방안
- 클라이언트와 서버가 동기화되어 예측 가능한 nonce 생성 알고리즘을 사용하는 방안
Next Nonce Pregeneration
The next nonce value can be provided in advance to the client by the Authentication-Info success header. This header is sent along with the 200 OK response from a previous successful authentication.
Authentication-Info: nextnonce="<nonce-value>"
-
Authentication-Info 성공 헤더를 사용하면 클라이언트에게 다음 Nonce 값을 전달할 수 있습니다.
-
이 헤더는 이전의 성공적인 인증을 나타내는 200 OK 응답과 함께 전송됩니다.
Given the next nonce, the client can preemptively issue an Authorization header.
- 다음 Nonce가 주어지면 클라이언트는 선제적으로 Authorization 헤더를 발행할 수 있습니다.
While this preemptive authorization avoids a request/challenge cycle (speeding up the transaction), it also effectively nullifies the ability to pipeline multiple requests to the same server, because the next nonce value must be received before the next request can be issued. Because pipelining is expected to be a fundamental technology for latency avoidance, the performance penalty may be large.
-
선제적인 인증 방식은 request/challenge 사이클을 회피할 수 있지만, 동일한 서버에 대한 다중 요청을 파이프라이닝하는 기술을 무효화합니다.
-
다음 요청이 발행되기 전에 다음 nonce 값을 전달받아야 하기 때문입니다.
-
파이프라이닝은 지연을 회피하기 위한 기본적인 기술이기 때문에 성능적인 문제가 발생할 수 있습니다.
Limited Nonce Reuse
Instead of pregenerating a sequence of nonces, another approach is to allow limited reuse of nonces. For example, a server may allow a nonce to be reused 5 times, or for 10 seconds.
-
nonce 시퀀스를 미리 생성하는 대신 nonce의 제한된 재사용을 허용하는 방법도 있습니다.
-
예를 들어 서버는 nonce를 5번 재사용하거나 10초 동안 재사용하는 것을 허용할 수 있습니다.
In this case, the client can freely issue requests with the Authorization header, and it can pipeline them, because the nonce is known in advance. When the nonce finally expires, the server is expected to send the client a 401 Unauthorized challenge, with the WWW-Authenticate: stale=true directive set:
WWW-Authenticate: Digest realm="<realm-value>" nonce="<nonce-value>" stale=true
-
이러한 경우 클라이언트가 nonce를 미리 알고 있기 때문에 Authorization 헤더를 포함하여 자유롭게 파이프라이닝된 요청을 발행할 수 있습니다.
-
nonce가 최종적으로 만료되면 서버는 WWW-Authenticate: stale=true 지시어 집합과 함께 클라이언트에게 401 Unauthorized Challenge를 요구할 것입니다.
Reusing nonces does reduce security, because it makes it easier for an attacker to succeed at replay attacks. Because the lifetime of nonce reuse is controllable, from strictly no reuse to potentially long reuse, trade-offs can be made between windows of vulnerability and performance.
-
nonce를 재사용하면 공격자가 리플레이 공격에 성공할 확률이 높아지므로 보안이 약화되는 것은 분명합니다.
-
하지만 엄격하게 재사용을 금하는 것부터 오랜 시간 재사용을 허용하는 것까지 nonce의 재사용 주기를 적당히 조절할 수 있기 때문에 취약점과 성능 사이에서 절충안을 찾을 수 있습니다.
Additionally, other features can be employed to make replay attacks more difficult, including incrementing counters and IP address tests. However, while making attacks more inconvenient, these techniques do not eliminate the vulnerability.
-
카운터를 증가시키거나 IP 주소를 확인하는 등 다른 특성을 적용함으로써 리플레이 공격을 더 어렵게 만들 수는 있습니다.
-
공격자가 공격하기 조금 까다로워질 뿐 취약점을 완전히 제거하는 것은 아닙니다.
Synchronized Nonce Generation
It is possible to employ time-synchronized nonce-generation algorithms, where both the client and the server can generate a sequence of identical nonces, based on a shared secret key, that a third party cannot easily predict (such as secure ID cards).
-
클라이언트와 서버가 공유된 비밀 키를 사용하여 동일한 nonce 시퀀스를 생성할 수 있도록 동기화된 nonce 생성 알고리즘을 적용하는 것도 가능합니다.
-
비밀 키는 제삼자가 쉽게 예측할 수 없는 것이어야 합니다(보안 ID와 같이).
These algorithms are beyond the scope of the digest authentication specification.
- 이러한 알고리즘은 Digest Authentication 명세에서 다루고 있는는 범위에서 벗어납니다.
✏️ 요약
Preemptive Authentication
: 클라이언트가 request/challenge를 거치지 않고 Authentication 헤더를 선제적으로 발행하는 인증 방식
- 성능 최적화 : 각각의 요청이 request/challenge를 거치지 않으므로 서버와 주고받는 요청 응답의 횟수가 감소함
- Basic Authentication에서 일반적으로 적용
- Digest Authentication에서는 nonce로 인해 적용 어려움 -> 추가적인 수단 제공
[1] Next Nonce Pregeneration
: 서버가 다음 nonce를 미리 생성한 후 Authentication-Info에 담아 전송하는 것
- 단점 : 동일 서버에 대한 다중 요청 파이프라이닝 무효화
- 파이프라이닝 : 이전 요청에 대한 응답을 받지 않고 바로 다음 요청 전송
- Authentication-Info 헤더가 담긴 응답을 받아야 다음 요청이 전송 가능하므로 파이프라이닝 불가능
[2] Limited Nonce Reuse
: nonce의 제한된 재사용을 허용하여 클라이언트가 동일한 nonce를 Authorization 헤더에 담아 전송할 수 있게 하는 것 (nonce가 만료되면 WWW-Authenticate: stale=true를 포함하여 401 Unauthorized Challenge 요청)
- 횟수 제한 : 동일한 nonce를 n번 사용할 수 있게 한다
- 시간 제한 : 동일한 nonce를 n초 동안 사용할 수 있게 한다
- 단점 : 리플레이 공격을 완전히 차단할 수 없음
- nonce 재사용 주기를 적절히 조절해야 함 (성능 <-> 보안)
- 카운터나 IP 주소 확인 등 다른 기법과 함께 사용하는 것이 좋음
[3] Synchronized Nonce Generation
: 클라이언트와 서버가 동기화된 nonce 생성 알고리즘을 사용하는 것
- 클라이언트와 서버간 Shared Secret Key 공유
- Digest Authentication 명세에서는 다루지 않음
✏️ 감상
보안은 항상 성능 문제가 뒤따른다
확실히 보안은 무겁다..! 공격을 방지하기 위해 뭔가를 자꾸 확인하고 교차 검증하다 보니 성능이 떨어지는 것은 당연한 일이다. 성능을 반토막내지 않으면서 보안을 강화할 수 있는 방법이 있으면 좋을 텐데 ㅎㅁㅎ 성능 저하를 감수하더라도 보안은 중요하니까 안 할 수도 없고 이걸...
보안 분야가 끊임없이 연구되는 것도, 보안 관련 문제가 계속해서 발생하고 있지만 적절한 조치를 취하기가 어려워서일 것이다. 파면 팔수록 정말 고민이 많아지는 분야다. 구멍난 독에 물은 계속 들어오고 그걸 막으려고 모든 수단과 방법을 고민하는 느낌 ㅋㅋㅋㅋㅋㅋㅋㅋ..
근데 그게 꽤 재미있다는 거 아십니까
