※ HTTP Digest 와 SSL을 함께 사용하여, 보안 기능을 더 업데이트 한다면, 최소한, 스니핑에 의한 피해를 최소화할 수 있지 않을까?
※ 실제로, 재직 중인 회사에서 좀 오래전에 모든 로그인/회원가입 Form에 SSL 보안서버를 탑재하면서, 유효성 검증을 위해서, WireShark Tool을 이용하여, 패킷을 분석했던 경우가 있었다. 당연히 SSL 보안서버가 적용되지 않은 로그인/회원가입 폼에서는 전송되는 패킷을 확인해본 결과 여실히 Data 들이 있었고, 암호화가 안되어 있으니, 복호화 따윈 할 필요도 없이, 도용을 할 가능성이 공존하고 있었다. 물론, SSL 보안서버 탑재 후에는 그런 부분의 우려가 많이 줄었다고 생각한다.
이러한 부분에서, HTTP Digest와 같은 Handshake mechanisim을 Password 등 민감한 개인정보를 송수신 하는 모듈에 적용하는 방안은, 보안기능성 향상에 큰 도움을 줄 수 있을 것이다.
Digest access authentication was originally specified by RFC
2069 (An Extension to HTTP: Digest Access Authentication). RFC
2069 specifies roughly a traditional digest authentication scheme with
security maintained by a server-generated nonce value. The authentication response is
formed as follows (where HA1, HA2, A1, A2 are names of string variables):
RFC 2069 was later replaced by RFC
2617 (HTTP Authentication: Basic and Digest Access Authentication).
RFC 2617 introduced a number of
optional security enhancements to digest authentication; "quality of protection"
(qop), nonce counter incremented by client, and a client-generated random nonce.
These enhancements are designed to protect against, for example, chosen-plaintext attackcryptanalysis.
If the qop directive's value is "auth" or is unspecified, then HA2 is
If the qop directive's value is "auth-int" , then HA2 is
If the qop directive's value is "auth" or "auth-int" , then compute the
response as follows:
If the qop directive is unspecified, then compute the response as
follows:
The above shows that when qop is not specified, the simpler RFC
2069 standard is followed.
Impact of MD5 security on digest authentication
The MD5 calculations used in HTTP digest authentication is intended to be "one way", meaning
that it should be difficult to determine the original input when only the output
is known. If the password itself is too simple, however, then it may be possible
to test all possible inputs and find a matching output (a brute-force attack) – perhaps aided by a
dictionary or suitable look-up list.
The HTTP scheme was designed at CERN in 1993 and
does not incorporate subsequent improvements in authentication systems, such as
the development of keyed-hash message authentication code (HMAC). Although the cryptographic construction that is used is based
on the MD5 hash function, collision attacks were in 2004 generally
believed to not affect applications where the plaintext (i.e. password) is not
known.[1][citation needed] However,
claims in 2006 (Kim, Biryukov2, Preneel, Hong, "On the Security of HMAC
and NMAC Based on HAVAL MD4 MD5 SHA-0 and SHA-1") cause some doubt over
other MD5 applications as well. So far, however, MD5 collision attacks have not
been shown to pose a threat to digest authentication, and the RFC
2617 allows servers to implement mechanisms to detect some collision and
replay attacks.
HTTP digest
authentication considerations
Advantages
HTTP digest authentication is designed to be more secure than traditional
digest authentication schemes; e.g., "significantly stronger than (e.g.) CRAM-MD5 ..." (RFC2617).
Some of the security strengths of HTTP digest authentication are:
The password is not used directly in the digest, but rather HA1 =
MD5(username:realm:password). This allows some implementations (e.g. JBossDIGESTAuth) to store HA1 rather than the cleartext password.
Client nonce was introduced in RFC2617, which
allows the client to prevent chosen plaintext attacks (which otherwise
makes e.g. rainbow
tables a threat to digest authentication schemes).
Server nonce is allowed to contain timestamps. Therefore the server may
inspect nonce attributes submitted by clients, to prevent replay attacks.
Server is also allowed to maintain a list of recently issued or used server
nonce values to prevent reuse.
Disadvantages
Digest access authentication is intended as a security trade-off. It is
intended to replace unencrypted HTTP basic access authentication. It is
not, however, intended to replace strong authentication protocols, such as public-key or Kerberos
authentication.
In terms of security, there are several drawbacks with digest access
authentication:
Many of the security options in RFC 2617 are optional. If
quality-of-protection (qop) is not specified by the server, the client will
operate in a security-reduced legacy RFC 2069 mode.
Digest access authentication is vulnerable to a man-in-the-middle (MitM) attack. For
example, a MitM attacker could tell clients to use basic access authentication
or legacy RFC2069 digest access authentication mode. To extend this further,
digest access authentication provides no mechanism for clients to verify the
server's identity.
Some servers require passwords to be stored using reversible encryption.
However, it is possible to instead store the digested value of the username,
realm, and password.[2]
Alternative
authentication protocols
Some strong authentication protocols for web-based applications include:
Public
key authentication (usually implemented with HTTPS / SSL client
certificates).
These weak cleartext protocols used together with HTTPS network encryption
resolve many of the threats that digest access authentication is designed to
prevent.
Example with
explanation
The following example was originally given in RFC
2617 and is expanded here to show the full text expected for each request
and response. Note that only the "auth" (authentication) quality of protection
code is covered – at the time of writing, only the Opera and Konquerorweb browsers are known to support "auth-int"
(authentication with integrity protection). Although the specification mentions
HTTP version 1.1, the scheme can be successfully added to a version 1.0 server,
as shown here.
This typical transaction consists of the following steps.
The client asks for a page that requires authentication but does not provide
a username and
password. Typically this is because the user simply entered the address or
followed a link to the page.
The server responds with the 401 "client-error" response code,
providing the authentication realm and a randomly-generated, single-use value
called a nonce.
At this point, the client will present the authentication realm (typically a
description of the computer or system being accessed) to the user and prompt for
a username and password. The user may decide to cancel at this point.
Once a username and password have been supplied, the client re-sends the
same request but adds an authentication header that includes the response
code.
In this example, the server accepts the authentication and the page is
returned. If the username is invalid and/or the password is incorrect, the
server might return the "401" response code and the client would prompt the user
again.
Note: A client may already have the required username and password without
needing to prompt the user, e.g. if they have previously been stored by a web
browser.
(followed by a blank line and HTML text of the restricted page).
The "response" value is calculated in three steps, as follows. Where values
are combined, they are delimited
by colon
symbols.
The MD5 hash of the combined username, authentication realm and password is
calculated. The result is referred to as HA1.
The MD5 hash of the combined method and digest URI is calculated, e.g. of
"GET" and "/dir/index.html". The result is referred to
as HA2.
The MD5 hash of the combined HA1 result, server nonce (nonce), request
counter (nc), client nonce (cnonce), quality of protection code (qop) and HA2
result is calculated. The result is the "response" value provided by the
client.
Since the server has the same information as the client, the response can be
checked by performing the same calculation. In the example given above the
result is formed as follows, where MD5() represents a function used
to calculate an MD5 hash, backslashes represent a continuation and the quotes
shown are not used in the calculation.
Completing the example given in RFC 2617 gives the following
results for each step.
At this point the client may make another request, reusing the server nonce
value (the server only issues a new nonce for each "401" response) but providing
a new client nonce (cnonce). For subsequent requests, the hexadecimal request
counter (nc) must be greater than the last value it used – otherwise an attacker
could simply "replay" an
old request with the same credentials. It is up to the server to ensure that the
counter increases for each of the nonce values that it has issued, rejecting any
bad requests appropriately. Obviously changing the method, URI and/or counter
value will result in a different response value.
The server should remember nonce values that it has recently generated. It
may also remember when each nonce value was issued, expiring them after a
certain amount of time. If an expired value is used, the server should respond
with the "401" status code and add stale=TRUE to the authentication
header, indicating that the client should re-send with the new nonce provided,
without prompting the user for another username and password.
The server does not need to keep any expired nonce values – it can simply
assume that any unrecognised values have expired. It is also possible for the
server to only allow each nonce value to be returned once, although this forces
the client to repeat every request. Note that expiring a server nonce
immediately will not work, as the client would never get a chance to use it.
SIP digest
authentication
SIP uses basically the same digest
authentication algorithm. It is specified by RFC
3261.