Download
1 / 30
370 likes | 691 Views
Digest Authentication. Herng-Yow Chen. Outline. Theory and practice of digest authentication. The improvement of Digest Authentication. Problem of Basic Authentication. Basic authentication is convenient and flexible but completely insecure.
E N D
Digest Authentication Herng-Yow Chen
Outline Theory and practice of digest authentication. The improvement of Digest Authentication
Problem of Basic Authentication Basic authentication is convenient and flexible but completely insecure. Usernames and passwords are sent in a clear way (using a base-64 encoding, which can be decoded easily). Base-64 encoding protects against unintentional accidental viewing but offers no confidentiality protection against malicious parties. The only way to use basic authentication securely is to use it conjunction with SSL (talk later).
Introduction Digest authentication was developed as a compatible, more secure alternative to basic authentication. Even though digest authentication is not yet in wide use, the concepts still are important for anyone implementing secure transaction.
The improvements of Digest Authentication Digest authentication is an alternate HTTP authentication protocol that tries to fix the most serious flaws of basic authentication. Never send secret passwords across the network in the clear Prevent unscrupulous individuals from capturing and replaying handshakes Optionally can guard against tampering with message content Guards against several other common forms of attacks.
The improvements of Digest Authentication Cont. Digest authentication is not the most secure protocol possible. Many needs for secure HTTP transaction cannot be met by digest authentication. For those needs, Transport Layer Security (TLS) and Secure HTTP (HTTPS) are more appropriate protocols. 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.
The improvements of Digest Authentication Cont. To date, digest authentication has not been 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.
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 is a correct match for the password.
Using Digests to Keep Passwords Secret Cont. 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. However, there are techniques, such as dictionary attacks, where passwords are tried first. These cryptanalysis techniques can dramatically ease the process of cracking passwords.
Using Digests for password-obscured authentication Please give me the internal sales forecast. Internet (a)Request client server You requested a secret financial document.Please tell me your username and password digests. Internet (b)Challenge client server Ask user for username and password digest(“0w!”)=A3F5 Please give me the internal sales forecast. My username is “bri” My digested password is “A3F5” Internet (c)Authorization server client digest(“0w!”)=A3F5 ˇ This is a match! OK.The digest you sent me matches the digest of my internal password, so here is the document. Internet (d)Success client server
One-Way Digests A digest is a “condensation of a body of information.” * Merriam-Webster dictionary, 1998. Digests act as one-way functions, typically converting an infinite number of possible input value into a finite range of condensations. In theory, it is possible to have two distinct inputs map to the same digest, called a “collision.” In practice, the number of potential outputs is so large that the chance of a collision in real life is vanishingly small and, for the purpose of password matching, unimportant.
Message Digest #5 (MD5) One popular digest function, MD5, converts any arbitrary sequence of bytes, of any length, into a 128-bit digest. 128 bits = 2 128, or about 1,000,000,000,000,000,000,000,000,000,000,000,000,000 = 10 39 possible distinct condensations.
MD5 Cont. 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 will have an awfully hard time figuring out which of the effectively infinite number of input values generated it.
MD5 Cont. The 128 bits of MD5 output often are written as 32 hexadecimal characters, each character representing 4 bits. Digest functions sometimes are called cryptographic checksums, one-way hash functions, or fingerprint functions.
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. Unfortunately, obscured password alone do not save us 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.
Using Nonces to Prevent Replays Cont. 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. Mixing the nonce in with the password causes the digest to change each time the nonce change. This prevent replay attacks.
Using Nonces to Prevent Replays Cont. 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.
The Digest Authentication Handshake Client www.ncnu.edu.tw (1)Server generates nonce WWW-Authenticate (challenge) (2)Server sends realm, nonce, algorithms (3)Choose algorithm from set [generate response digest] [generate client-nonce] Authorization (response) (4)Client sends response digest [send algorithm] [send client-nonce] (5)Server verifies digest [generate rspauth digest] [generate next nonce] Authentication-Info (info) (7)Client verifies rspauth digest (6)Server sends next nonce [send client rspauth digest]
Basic versus digest authentication syntax • Basic authentication (a)Query GET /cgi-bin/checkout?cart=17854 HTTP/1.1 client server (b)Challenge client HTTP/1.1 401 Unauthorized WWW-Authenticate: Basic realm=“Shopping Cart” server Shopping Cart Username: Password: (c)Response GET /cgi-bin/checkout?cart=17854 HTTP/1.1 Authorization: Basic YnJpYW4tdG90dHk6T3ch server client (d)Success HTTP/1.1 200 OK … client server
Reference http://www.ietf.org/rfc/rfc2617.txt RFC 2617,”HTTP Authentication: Basic and Digest Access Authentication”
