Chapter 13. Digest Authentication
(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)
✏️ 원문 번역
Security Considerations
RFC 2617 does an admirable job of summarizing some of the security risks inherent in HTTP authentication schemes. This section describes some of these risks.
-
RFC 2617은 HTTP 인증 기법에 내재한 보안 위협을 훌륭하게 요약하고 있습니다.
-
이번 섹션에서는 몇 가지 위협에 대해 설명합니다.
Header Tampering
To provide a foolproof system against header tampering, you need either end-to-end encryption or a digital signature of the headers—preferably a combination of both! Digest authentication is focused on providing a tamper-proof authentication scheme, but it does not necessarily extend that protection to the data. The only headers that have some level of protection are WWW-Authenticate and Authorization.
-
헤더 변조에 대응하기 위한 완벽한 시스템을 제공하려면 헤더에 대한 end-to-end 암호화나 전자서명이 필요합니다.
-
혹은 두 기법을 함께 사용하여도 좋습니다.
-
Digest Authentication은 변조 방지 인증 기법을 제공하는 데 중점을 두고 있지만 반드시 데이터까지 보호 범위를 확장해야 하는 것은 아닙니다.
-
어느 정도 보호 기능이 탑재되어 있는 유일한 헤더는 WWW-Authenticate와 Authorization 헤더입니다.
Replay Attacks
A replay attack, in the current context, is when someone uses a set of snooped authentication credentials from a given transaction for another transaction. While this problem is an issue with GET requests, it is vital that a foolproof method for avoiding replay attacks be available for POST and PUT requests. The ability to successfully replay previously used credentials while transporting form data could cause security nightmares.
-
현재 맥락에서 리플레이 공격이란 주어진 트랜잭션에서 감청한 인증 정보를 다른 트랜잭션에 사용하는 것을 의미합니다.
-
이 문제는 GET 요청에서 발생하지만, POST와 PUT 요청에서 리플레이 공격을 피하기 위한 완벽한 방법을 사용할 수 있어야 합니다.
-
폼 데이터를 전송하는 동안 이전에 사용된 인증 정보를 성공적으로 리플레이 할 수 있다면 보안상의 문제가 발생할 수 있습니다.
Thus, in order for a server to accept “replayed” credentials, the nonce values must be repeated. One of the ways to mitigate this problem is to have the server generate a nonce containing a digest of the client’s IP address, a time-stamp, the resource ETag, and a private server key (as recommended earlier). In such a scenario, the combination of an IP address and a short timeout value may provide a huge hurdle for the attacker.
-
서버가 같은 nonce 값을 반복하는 경우 "리플레이 된" 자격 증명을 승인할 수 있습니다.
-
이 문제를 완화하기 위한 한 가지 방법으로 서버가 클라이언트의 IP 주소, 타임스탬프, 리소스 ETag, 서버의 비밀키에 관한 digest를 포함하여 nonce를 생성하는 것이 있습니다.
-
IP 주소와 짧은 타임아웃 값의 조합은 공격의 난이도를 상당히 높입니다.
However, this solution has a major drawback. As we discussed earlier, using the client’s IP address in creating a nonce breaks transmission through proxy farms, in which requests from a single user may go through different proxies. Also, IP spoofing is not too difficult.
-
하지만 해당 솔루션에는 주요한 결함이 있습니다.
-
앞서 이야기했던 것처럼 클라이언트의 IP 주소를 사용하여 nonce를 생성하는 것은 단일 사용자의 요청이 다른 프록시를 통과하는 프록시 팜 전달 과정에서 유효성을 잃을 수 있습니다.
-
또한 IP 스푸핑은 그다지 어렵지 않습니다.
One way to completely avoid replay attacks is to use a unique nonce value for every transaction. In this implementation, for each transaction, the server issues a unique nonce along with a timeout value. The issued nonce value is valid only for the given transaction, and only for the duration of the timeout value. This accounting may increase the load on servers; however, the increase should be miniscule.
-
리플레이 공격을 완전히 회피하기 위해서는 트랜잭션별로 고유한 nonce 값을 사용해야 합니다.
-
서버는 트랜잭션마다 타임아웃 값과 함께 고유한 nonce 값을 발행합니다.
-
발행된 nonce는 주어진 트랜잭션과 타임아웃 기간 내에서만 유효합니다.
-
서버의 부하가 증가할 수 있지만 그 양은 미미할 것입니다.
Multiple Authentication Mechanisms
When a server supports multiple authentication schemes (such as basic and digest), it usually provides the choice in WWW-Authenticate headers. Because the client is not required to opt for the strongest authentication mechanism, the strength of the resulting authentication is only as good as that of the weakest of the authentication schemes.
-
서버가 다중 인증 기법(Basic과 Digest를 동시에 사용하는 등)을 지원하는 경우 WWW-Authenticate 헤더를 통해 선택의 기회를 제공합니다.
-
클라이언트가 가장 강력한 인증 매커니즘을 선택할 의무는 없으므로 결과 인증의 강도는 가장 약한 인증 기법의 강도를 따릅니다.
The obvious ways to avoid this problem is to have the clients always choose the strongest authentication scheme available. If this is not practical (as most of us do use commercially available clients), the only other option is to use a proxy server to retain only the strongest authentication scheme. However, such an approach is feasible only in a domain in which all of the clients are known to be able to support the chosen authentication scheme—e.g., a corporate network.
-
이 문제를 회피하기 위한 분명한 방법은 클라이언트가 반드시 가능한 인증 기법 중 가장 강력한 기법을 선택하도록 하는 것입니다.
-
상황이 여의치않은 경우 유일하게 사용할 수 있다는 다른 옵션은 가장 강력한 인증 기법만을 유지하는 프록시 서버를 사용하는 것입니다.
-
하지만 이러한 접근 방식은 모든 클라이언트가 주어진 인증 기법을 지원하는 것으로 알려진 도메인(ex. 기업 네트워크)에 한해서만 적용 가능하다는 문제가 있습니다.
Dictionary Attacks
Dictionary attacks are typical password-guessing attacks. A malicious user can eavesdrop on a transaction and use a standard password-guessing program against nonce/response pairs. If the users are using relatively simple passwords and the servers are using simplistic nonces, it is quite possible to find a match. If there is no password aging policy, given enough time and the one-time cost of cracking the passwords, it is easy to collect enough passwords to do some real damage.
-
Dictionary 공격은 대표적인 패스워드 유추 공격입니다.
-
악의적인 사용자가 트랜잭션을 감청한 후 nonce/response 쌍에 대해 패스워드 유추 프로그램을 동작시킬 수 있습니다.
-
사용자가 비교적 단순한 패스워드를, 서버가 단순한 nonce를 사용하고 있다면 비밀번호를 찾는 것이 가능할 수 있습니다.
-
패스워드 Aging 정책이 없는 경우 충분한 시간과 비밀번호를 해독하기 위한 일회성 비용이 주어지면 피해를 입힐 수 있을 만큼 많은 양의 비밀번호를 수집할 수 있습니다.
There really is no good way to solve this problem, other than using relatively complex passwords that are hard to crack and a good password aging policy.
-
더 심각한 것은 이 문제를 해결하기 위한 마땅한 방안이 존재하지 않는다는 점입니다.
-
해독되지 않을 정도로 복잡한 패스워드를 사용하는 것과 적절한 패스워드 Aging 정책을 사용하는 것만이 유일한 대책입니다.
Hostile Proxies and Man-in-the-Middle Attacks
Much Internet traffic today goes through a proxy at one point or another. With the advent of redirection techniques and intercepting proxies, a user may not even realize that his request is going through a proxy. If one of those proxies is hostile or compromised, it could leave the client vulnerable to a man-in-the-middle attack.
-
오늘날 많은 인터넷 트래픽이 특정 시점에서 프록시를 거칩니다.
-
리디렉션 기술과 중간 프록시의 등장으로 인해 사용자는 요청이 프록시를 통과하는지 체감할 수 없게 되었습니다.
-
프록시 중 하나가 적대적이거나 손상된 경우 클라이언트는 중간자 공격에 취약해질 수 있습니다.
Such an attack could be in the form of eavesdropping, or altering available authentication schemes by removing all of the offered choices and replacing them with the weakest authentication scheme (such as basic authentication).
- 이러한 종류의 공격은 Eavesdropping(감청) 혹은 제공받은 선택지를 제거하고 사용할 수 있는 인증 기법을 가장 약한 것(ex. Basic Authentication)으로 바꿔치기함으로써 이루어질 수 있습니다.
One of the ways to compromise a trusted proxy is though its extension interfaces. Proxies sometimes provide sophisticated programming interfaces, and with such proxies it may be feasible to write an extension (i.e., plug-in) to intercept and modify the traffic. However, the data-center security and security offered by proxies themselves make the possibility of man-in-the-middle attacks via rogue plug-ins quite remote.
-
신뢰할 수 있는 프록시를 손상시키는 방법 중 하나는 확장 인터페이스를 이용하는 것입니다.
-
프록시는 종종 정교한 프로그래밍 인터페이스를 제공하여 가로챈 트래픽을 수정할 수 있는 익스텐션을 제공하기도 합니다.
-
그러나 데이터 센터 보안과 프록시가 자체적으로 제공하는 보안으로 인해 악성 플러그인을 통해 중간자 공격이 발생할 가능성은 희박합니다.
There is no good way to fix this problem. Possible solutions include clients providing visual cues regarding the authentication strength, configuring clients to always use the strongest possible authentication, etc., but even when using the strongest possible authentication scheme, clients still are vulnerable to eavesdropping. The only foolproof way to guard against these attacks is by using SSL.
-
문제를 해결할 수 있는 마땅한 방법이 존재하지 않습니다.
-
가능한 방법은 인증 강도에 관한 시각적인 단서를 제공하고 가장 강력한 인증 방식을 사용하도록 강제하는 것뿐입니다.
-
하지만 가장 강력한 인증 기법을 사용하더라도 클라이언트는 여전히 Eavesdropping 공격에 취약합니다.
-
이러한 종류의 공격에 대응하는 완벽한 방법은 SSL을 사용하는 것뿐입니다.
Chosen Plaintext Attacks
Clients using digest authentication use a nonce supplied by the server to generate the response. However, if there is a compromised or malicious proxy in the middle intercepting the traffic (or a malicious origin server), it can easily supply a nonce for response computation by the client. Using the known key for computing the response may make the cryptanalysis of the response easier. This is called a chosen plaintext attack. There are a few variants of chosen plaintext attacks:
-
Digest Authentication을 사용하는 클라이언트는 서버가 제공한 nonce를 사용하여 응답을 생성합니다.
-
하지만 손상되거나 악의적인 중간 프록시가 트래픽을 가로챈다면 클라이언트의 응답 연산에 사용되는 nonce를 쉽게 제공할 수 있습니다.
-
알려진 키를 사용하여 응답을 계산하는 경우 응답 암호 분석이 더욱 간단해질 수 있습니다.
-
이러한 공격을 "Chosen Plaintext Attack"이라고 합니다.
-
Chosen Plaintext Attack에는 몇 가지 변형이 존재합니다.
Precomputed dictionary attacks
This is a combination of a dictionary attack and a chosen plaintext attack. First, the attacking server generates a set of responses, using a predetermined nonce and common password variations, and creates a dictionary. Once a sizeable dictionary is available, the attacking server/proxy can complete the interdiction of the traffic and start sending predetermined nonces to the clients. When it gets a response from a client, the attacker searches the generated dictionary for matches. If a there is a match, the attacker has the password for that particular user.
Precomputed Dictionary Attacks
-
Dictionary Attack과 Chosen Plaintext Attack을 결합한 형태입니다.
-
먼저 공격 서버가 사전에 생성한 nonce와 다양한 패스워드를 사용하여 응답 집합을 생성한 후 Dictionary를 만듭니다.
-
활용 가능한 거대한 Dictionary를 구축하고 나면 공격 서버 및 프록시는 트래픽 차단을 완료하고 사전에 생성한 nonce를 클라이언트에게 전송할 수 있습니다.
-
서버가 클라이언트로부터 응답을 받으면 공격자는 일치하는 항목을 발견하기 위해 Dictionary를 탐색합니다.
-
일치 항목이 발생하는 경우 공격자는 특정 사용자의 패스워드를 얻습니다.
Batched brute-force attacks
The difference in a batched brute-force attack is in the computation of the password. Instead of trying to match a precomputed digest, a set of machines goes to work on enumerating all of the possible passwords for a given space. As the machines get faster, the brute-force attack becomes more and more viable.
Batched Brute-force Attacks
-
일괄적인 무차별 대입 공격의 차이점은 패스워드 연산에 있습니다.
-
사전에 연산된 digest가 일치하는지 확인하는 대신 여러 대의 기계로 주어진 공간에 대해 모든 가능한 패스워드를 열거하기 시작합니다.
-
기계가 빠르면 빠를수록 무차별 대입 공격은 점점 더 성공 가능성이 높아집니다.
In general, the threat posed by these attacks is easily countered. One way to prevent them is to configure clients to use the optional cnonce directive, so that the response is generated at the client’s discretion, not using the nonce supplied by the server (which could be compromised by the attacker). This, combined with policies enforcing reasonably strong passwords and a good password aging mechanism, can mitigate the threat of chosen plaintext attacks completely.
-
이러한 공격으로 발생하는 위협은 일반적으로 쉽게 차단할 수 있습니다.
-
클라이언트가 선택적인 cnonce 지시어를 사용하도록 구성하는 것도 한 가지 방법입니다.
-
서버에서 제공한 nonce를 그대로 사용하지 않고 클라이언트의 재량에 따라 응답이 생성되도록 하는 것입니다(서버는 공격자에 의해 손상될 수 있습니다).
-
강력한 패스워드를 강제하는 정책과 잘 설계된 패스워드 Aging 매커니즘을 결합하여 Chosen Plaintext Attack으로 인한 위협을 완벽히 제거할 수 있습니다.
Storing Passwords
The digest authentication mechanism compares the user response to what is stored internally by the server—usually, usernames and H(A1) tuples, where H(A1) is derived from the digest of username, realm, and password.
-
Digest Authentication 매커니즘은 사용자 응답과 서버 내부에 저장된 값을 비교합니다.
-
일반적으로 서버 내부의 값은 username과 H(A1) 튜플을 나타냅니다.
-
H(A1)은 username, realm, password의 digest로부터 파생된 값입니다.
Unlike with a traditional password file on a Unix box, if a digest authentication password file is compromised, all of the documents in the realm immediately are available to the attacker; there is no need for a decrypting step.
-
유닉스 계열의 전통적인 패스워드 파일과 달리 Digest Authentication의 패스워드 파일에 손상이 발생하면 공격자가 영역 내의 모든 문서를 즉시 사용할 수 있습니다.
-
복호화 과정은 전혀 필요하지 않습니다.
Some of the ways to mitigate this problem are to:
• Protect the password file as though it contained clear-text passwords.
• Make sure the realm name is unique among all the realms, so that if a password file is compromised, the damage is localized to a particular realm. A fully qualified realm name with host and domain included should satisfy this requirement.
- 이 문제를 완화하기 위한 몇 가지 방법이 존재합니다.
- 비밀번호 파일을 일반 텍스트 비밀번호가 포함된 것처럼 보호합니다.
- 패스워드 파일이 손상되더라도 특정 영역에만 손해가 국한되도록 고유한 영역 이름을 지정합니다. 호스트와 도메인이 포함된 정규화된 영역의 이름은 이러한 조건을 충족해야 합니다.
While digest authentication provides a much more robust and secure solution than basic authentication, it still does not provide any protection for security of the content—a truly secure transaction is feasible only through SSL, which we describe in the next chapter.
-
Digest Authentication은 Basic Authentication에 비해 더 강력한 보안 솔루션을 제공합니다.
-
하지만 Digest Authentication도 콘텐츠에 대해서는 어떠한 보호 조치도 제공하고 있지 않습니다.
-
완벽한 보안 트랜잭션은 다음 챕터에서 다룰 SSL을 통해서만 이루어질 수 있습니다.
✏️ 요약
Security Considerations
[1] Header Tampering
- Problem : 헤더 변조 (Digest Authentication은 데이터까지 보호 범위를 확장하지 않음 -> 보호되는 헤더는
WWW-Authenticate,Authorization뿐) - Solution : end-to-end 암호화 및 전자서명 사용
[2] Replay Attacks
- Problem : 감청한 인증 정보를 다른 트랜잭션에 사용
- Solution : 트랜잭션마다 고유한 nonce 사용
[3] Multiple Authentication Mechanisms
- Problem : 서버가 여러 인증 방식을 제공하는 경우 가장 약한 인증 기법에 보안 수준이 의존하게 됨
- Solution : 클라이언트가 가장 강력한 인증 기법을 선택하게 함, 가장 강력한 인증 기법만을 유지하는 프록시 사용
[4] Dictionary Attacks
- Problem : 트랜잭션을 감청하여 획득한 nonce/response 쌍을 통해 패스워드를 유추할 수 있음 (특히 nonce나 패스워드가 단순한 경우)
- Solution : 패스워드 Aging 정책 강화, 복잡한 패스워드 사용 (완벽한 대책 존재 X)
[5] Man-in-the-Middle Attacks
- Problem : 프록시를 손상시켜 감청하거나 요구하는 인증 기법을 가장 약한 것으로 바꿔치기 할 수 있음
- Solution : 클라이언트가 가장 강력한 인증 기법을 선택하게 함, SSL 사용
[6] Chosen Plaintext Attacks
- Problem : 중간 프록시가 클라이언트에게 nonce를 제공하고 이를 바탕으로 응답을 유도하여 암호를 쉽게 분석함
- Precomputed Dictionary Attacks : 공격 서버가 생성한 nonce와 다양한 패스워드를 결합하여 Dictionary를 생성하고, 클라이언트의 응답에서 일치 항목이 발생하는 경우 패스워드를 획득하는 방식
- Batched Brute-force Attacks : 여러 기기를 활용하여 모든 가능한 패스워드에 대해 확인하는 방식
- Solution : 클라이언트의 재량에 따라 cnonce를 사용하여 응답을 생성하게 함
[7] Storing Passwords
- Problem : 비밀번호 파일이 손상되는 경우 영역 내의 모든 문서에 접근할 수 있음
- Solution : 비밀번호 파일 보호, 고유한 영역 이름 지정, SSL 사용
✏️ 감상
Chapter 13 完
Digest Authentication에 관한 내용을 담은 Chapter 13이 마무리되었습니다. Digest Authentication은 Basic Authentication과 달리 nonce를 통해 비밀번호를 불투명하게 전송해서 보안을 강화하는 기술이라는 점에서 의의가 있는 기법이었습니다. 패스워드에 덧붙여서 salt의 역할을 하는 nonce와 리플레이 공격을 방지하기 위한 cnonce 등... 과거 네트워크 보안을 연구하던 사람들의 고뇌를 고스란히 느낄 수 있는 챕터였던 것 같습니다.
Digest Authentication이 예전에 비해 개선된 인증 과정을 제공한다는 점은 분명하지만, 오늘날에는 공격 방식도 그만큼 개선되었다는 것이 문제겠지요..?! 오늘 다룬 내용처럼 Digest Authentication을 사용하더라도 Dictionary Attack이나 MITM 앞에서는 효과를 잃어버릴 수밖에 없습니다. 읽으면 읽을수록 통신 과정에서의 보안은 역시 SSL을 따라잡을 만한 것이 없다는 생각이 듭니다. 교수님께서도 오늘날 네트워크에서 HTTPS를 안 쓸 이유가 없다며 도대체 왜 아직도 HTTP를 고수하는 서버가 있는지 모르겠다고 말씀하셔서...ㅋㅋㅋㅋㅋㅋ SSL 라이팅 제대로 당한 덕분에 설레는 마음으로 다음 챕터를 펼칠 수 있게 되었습니다 😌 다음 챕터가 바로 Secure HTTP라구용
아참 그저께 포스팅은 생일이어서 쉬었습니다 희희.. 어차피 아무도 안 읽지만 저 혼자 찔려서 적어봤어요
