NIST 800-44 Version 2 Guidelines on Securing Public Web Servers

More documents

Recommendations

Info

GUIDELINES ON SECURING PUBLIC WEB SERVERS 7.3 Basic Authentication The basic authentication technology uses the Web server content’s directory structure. Typically, all files in the same directory are configured with the same access privileges. A requesting user provides a recognized user identification and password for access to files in a given directory. More restrictive access control can be enforced at the level of a single file within a directory if the Web server software provides this capability. Each vendor’s Web server software has its own method and syntax for defining and using this basic authentication mechanism. From a security perspective, the main drawback of this technology is that all password information is transferred in an encoded, rather than an encrypted, form. Anyone who knows the standardized encoding scheme can decode the password after capturing it with a network sniffer. Furthermore, any Web content is transmitted as unencrypted plaintext, so this content also can be captured, violating confidentiality. These limitations can be overcome using basic authentication in conjunction with SSL/TLS (see Section 7.5). Basic authentication is supported by standard-compliant Web browsers [Koss00]. Basic authentication is useful for protecting information from malicious bots (see Section 5.2.4) because the bots should not have the necessary credentials to access the protected directories. However, this mechanism should not be considered secure against more determined and sophisticated attackers. 7.4 Digest Authentication Because of the drawbacks with basic authentication, an improved technique known as digest authentication was introduced in version 1.1 of the HTTP protocol. 47 Digest authentication uses a challenge-response mechanism for user authentication. Under this approach, a nonce or arbitrary value is sent to the user, who is prompted for an ID and password, as with basic authentication. However, in this case, the information entered by the user is concatenated and a cryptographic hash of the result is formed. This hash is concatenated with the nonce and a hash of the requested method and URL, and the result is then rehashed as a response value that is sent to the server. Because the user’s password is not sent in the clear, it cannot be directly sniffed from the network. The user’s password is not needed by the server to authenticate the user—only the hashed value of the user ID and password. Because the nonce can serve as an indicator of timeliness (e.g., it can be composed of date and time information), replay attacks are also thwarted. Unfortunately, all other information is sent in the clear and is vulnerable to interception and alteration. Digest authentication is also susceptible to offline dictionary attacks (see Section 7.6) where the attacker tries various passwords in an attempt to recreate the captured digest value. These limitations can be overcome using digest authentication in conjunction with SSL/TLS (see Section 7.5). 48 Like basic authentication, digest authentication is useful for protecting information from malicious bots (see Section 5.2.4). 47 48 More information on basic and digest authentication is available from IETF RFC 2617, HTTP Authentication: Basic and Digest Access Authentication (http://www.ietf.org/rfc/rfc2617.txt). For example, offline dictionary attacks can be performed against intercepted digest authentication passwords to identify the cleartext passwords. Intercepted digest authentication passwords that are sent over SSL-protected connections are not susceptible to offline dictionary attacks. 7-2
GUIDELINES ON SECURING PUBLIC WEB SERVERS 7.5 SSL/TLS The SSL and TLS protocols provide server and client authentication and encryption of communications. 49 SSL was first introduced by Netscape Communications in 1994 and was revised twice (SSL version 3 is the current version). 50 In 1996, the Internet Engineering Task Force (IETF) established the TLS working group to formalize and advance the SSL protocol to the level of Internet standard. The TLS protocol version 1.0 is formally specified in IETF Request for Comments (RFC) 2246, 51 which was published in 1999 and is based in large part on SSL version 3. SSL version 3 and TLS version 1 are essentially identical and are discussed together in this document. Most major Internet components, such as Web browsers, support the use of both SSL 3 and TLS 1.0. TLS 1.1, specified in RFC <strong>44</strong>36, was released in April 2006, and future versions of Web browsers will likely support it. TCP/IP governs the transport and routing of data over the Internet. Other protocols, such as HTTP, LDAP, and Internet Message Access Protocol (IMAP), run “on top of” TCP/IP in that they all use TCP/IP to support typical application tasks, such as displaying Web pages or delivering e-mail messages. Thus, SSL/TLS can support more than just secure Web communications. Figure 7-1 shows how SSL/TLS fits between the application and network/transport layers of the Internet protocol suite. 7.5.1 SSL/TLS Capabilities Figure 7-1. SSL/TLS Location within the Internet Protocol Stack SSL/TLS provides the following capabilities to HTTP and other application layer protocols [SSL98]: Server Authentication—SSL/TLS allows a Web client (user) to confirm a Web server’s identity. SSL/TLS-enabled Web clients (browsers) can employ standard techniques of public key cryptography to check that a server’s name and public key are contained in a valid certificate issued by a CA listed in the client’s list of trusted CAs. This confirmation might be important if the user, for example, is sending a credit card number over the network and wants to confirm the receiving server’s identity. Client Authentication—SSL/TLS allows a Web server to confirm a user’s identity using the same techniques as those used for server authentication by reversing the roles. SSL/TLS-enabled Web 49 50 51 Proper understanding of SSL and the information presented in this section requires at least a basic understanding of cryptographic algorithms, message digest functions, digital signatures, symmetric encryption algorithms, and asymmetric encryption algorithms. For an introduction to cryptography, see <strong>NIST</strong> SP <strong>800</strong>-32, Introduction to Public Key Technology and the Federal PKI Infrastructure. For more information on transport layer security, see <strong>NIST</strong> SP <strong>800</strong>-52, <strong>Guidelines</strong> for the Selection and Use of Transport Layer Security (TLS) Implementations. Both of these documents can be found at http://csrc.nist.gov/publications/nistpubs/. SSL versions before 3.0 are insecure and should not be used. http://www.ietf.org/rfc/rfc2246.txt 7-3
Page 1 and 2:
Special Publication 800</st
Page 3 and 4:
GUIDELINES ON SECURING PUBLIC WEB S
Page 5 and 6:
Page 7 and 8:
Page 9 and 10:
Page 11 and 12:
Page 13 and 14:
Page 15 and 16:
Page 17 and 18:
Page 19 and 20:
Page 21 and 22:
Page 23 and 24: GUIDELINES ON SECURING PUBLIC WEB S
Page 73: GUIDELINES ON SECURING PUBLIC WEB S
Page 125 and 126:
Page 127 and 128:
Page 129 and 130:
Page 131 and 132:
Page 133 and 134:
Page 135 and 136:
Page 137 and 138:
Page 139 and 140:
Page 141 and 142:
show all

NIST 800-44 Version 2 Guidelines on Securing Public Web Servers

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?