ch30.htm

来自「Maximum Security (First Edition) 网络安全 英文」· HTM 代码 · 共 1,283 行 · 第 1/5 页

</BLOCKQUOTE>

<P>This is different from the MD5 implementation. As reported by the same document:

<DL>
	<DD>In MD5 Message Digest Authentication, the password is not passed over the network
	at all. Instead, a series of numbers is generated based on the password and other
	information about the request, and these numbers are then hashed using MD5. The resulting
	&quot;digest&quot; is then sent over the network, and it is com-bined with other
	items on the server to test against the saved digest on the server.
</DL>

<P>It is my opinion that in intranets or other networked environments where you can
be sure of what browser is being used, you should implement the MD5 authentication
scheme.</P>
<P><B>Who Can Use </B><FONT SIZE="4"><TT><B>htpasswd</B></TT></FONT><B>?</B> Anyone
can use <TT>htpasswd</TT> to password protect any directory within his or her directory
tree. That is, a system administrator can protect an entire Web site, or a user can
selectively password protect directories within his or her <TT>/~user</TT> hierarchy.
However, there are some practical obstacles. First, the program must be available
for you to use. That means the following:

<UL>
	<LI>The machine on which the site resides must be a UNIX box.<BR>
	<BR>
	
	<LI>The administrator there must have gotten <TT>htpasswd</TT> with the distribution
	of his or her Web-server kit (NCSA; Apache also supports this utility).<BR>
	<BR>
	
	<LI>The administrator must have compiled the source to a binary or otherwise obtained
	a binary. You may go to the directory and find that only the source is available
	and the permissions are set to <TT>root</TT> as well.
</UL>

<P>Check whether all these conditions are met. You can generally find the location
of <TT>htpasswd</TT> (without bothering your sysad) by issuing the <TT>whereis</TT>
command at a shell prompt. However, <TT>htpasswd</TT> is usually located in the <TT>/usr/local/etc/httpd/support</TT>
directory.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>TIP:</B></FONT><B> </B>Your <TT>PATH</TT> environment variable
	is probably not set to reflect that directory, and I would not bother to change it.
	You will only be using the program once or twice unless you are engaged in system
	administration. 
<HR>


</BLOCKQUOTE>

<P><B>What if My Sysad Doesn't Have </B><FONT SIZE="4"><TT><B>htpasswd</B></TT></FONT><B>
and Won't Get It?</B> Some system administrators can be difficult to get hold of,
or may simply ignore user requests for the <TT>htpasswd</TT> utility. If you encounter
this situation, there is an alternative: <TT>htpasswd.pl</TT>. <TT>htpasswd.pl</TT>
is a Perl script designed to replace the current implementation of <TT>htpasswd</TT>.
It was written by Ryun Whitfield Schlecht (also known as Nem), a 22-year-old Computer
Science major at North Dakota State University.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>You can find Nem at <A
	HREF="http://abattoir.cc.ndsu.nodak.edu/~nem/">http://abattoir.cc.ndsu.nodak.edu/~nem/</A>.
	The code for htpasswd.pl is located at <A HREF="http://abattoir.cc.ndsu.nodak.edu/~nem/perl/htpass.html">http://abattoir.cc.ndsu.nodak.edu/~nem/perl/htpass.html</A>.
	
<HR>


</BLOCKQUOTE>

<P><B>Using </B><FONT SIZE="4"><TT><B>htpasswd</B></TT></FONT> Implementing <TT>htpasswd</TT>
takes only a few seconds. The first step is to create a file named <TT>.htaccess</TT>
in the target directory. This is a plain-text dot file that can be edited with any
editor on the UNIX platform (I prefer vi). The contents of the file will appear as
follows:</P>
<PRE><FONT COLOR="#0066FF">AuthUserFile /directory_containing_.htpasswd/.htpasswd
AuthGroupFile /directory_containing_a_group_file
AuthName ByPassword
AuthType Basic

&lt;Limit GET&gt;
require user _some_username_here
&lt;/Limit&gt;
</FONT></PRE>
<P>Let's go through each line:

<UL>
	<LI>The first line specifies the <TT>AuthUserFile</TT>. This is where the actual
	passwords are stored, in a file named <TT>.htpasswd</TT> (I will address the construct
	of that file momentarily).<BR>
	<BR>
	
	<LI>The second line specifies the location of the group file (called <TT>.htgroup</TT>).
	This is where usernames can be categorized into groups. In this example, we will
	not use a group file because we do not have many groups.<BR>
	<BR>
	
	<LI>The third and fourth lines express the way in which the password will be authenticated.
	(The technique being used is basic HTTP authentication because not all browsers support
	MD5).<BR>
	<BR>
	
	<LI>The fifth, sixth, and seventh lines express which users are allowed to perform
	a <TT>GET</TT> operation on the directory (that is, which users are allowed to access
	that directory). This is where you put the username.
</UL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>TIP:</B></FONT><B> </B>All paths should be expressed in
	their absolute form. That is, the <I>entire</I> path should be expressed. If you
	fail to do so, the authentication routine will fail. 
<HR>


</BLOCKQUOTE>

<P>Next, you will create the .<TT>htpasswd</TT> file. This file is a special file;
it can be created with a regular editor, but I would advise against it. Instead,
use your version of <TT>htpasswd</TT> like so:</P>
<PRE><FONT COLOR="#0066FF">htpasswd -c /directory_containing_htpasswd/.htpasswd username
</FONT></PRE>
<P>This will create the file and prompt you for a password for the username. You
will have to type this password twice: once to set it and once to confirm it.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>CAUTION:</B></FONT><B> </B>Make certain you have created
	the <TT>.htpasswd</TT> file in the same directory as you indicated in the <TT>.htaccess</TT>
	file. Otherwise, the system will be unable to find the <TT>.htpasswd</TT> file and,
	no matter what password is entered, users from outside will meet with a failed authorization.
	
<HR>


</BLOCKQUOTE>

<P>If you examine the <TT>.htpasswd</TT> file after you finish, you will see that
it contains the username and an encrypted string, which is the password in encrypted
form. It will look something like this:</P>
<PRE><FONT COLOR="#0066FF">username: o3ds2xcqWzLP7
</FONT></PRE>
<P>At this point, the directory is password protected. Anyone landing on that page
will be confronted with a password dialog box.</P>
<P>If you do not have Telnet access, you really cannot perform the preceding operation.
If your provider has denied Telnet access, explain the situation; perhaps it can
offer you Telnet on a limited basis so you can set the <TT>htpasswd</TT>. I would
not use a provider that did not offer Telnet access, but there are many out there.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>CAUTION:</B></FONT><B> </B>In the past, I have seen users
	attempt to set up these files--without Telnet--using FTP clients. Do NOT try this,
	or you will be unable to access your page later. After these files exist in your
	directory, the dialog box will appear every time. You would then have to return to
	FTP and delete the files. However, depending on how the permissions were set, you
	might be unable to do so. If you do not have access to Telnet and know very little
	about UNIX, do NOT attempt to establish such files on your server's drive. 
<HR>


</BLOCKQUOTE>

<H4><FONT COLOR="#000077"><B>HTML Security Extensions</B></FONT></H4>
<P>I mentioned several security extensions to HTML earlier in this book. Now it's
time to get a bit more specific, examining each in turn.</P>
<P>Because the Web has now become a popular medium for commerce, there is an enormous
push for security in HTML. Because the majority of garden-variety HTML traffic is
in clear text, the development of cryptographic and other data-hiding techniques
has become a big business. Thus, most of the proposals are proprietary. I will address
two: the Secure Sockets Layer (SSL) and S-HTTP.</P>
<P><B>Secure Sockets Layer (Netscape)</B> <I>Secure Sockets Layer</I> (SSL) is a
system designed and proposed by Netscape Communications Corporation. The SSL protocol
supports a wide range of authentication schemes. These can be implemented using various
cryptographic algorithms, including the now-popular DES. As reported by Netscape,
in its specification of SSL:

<DL>
	<DD>The primary goal of the SSL Protocol is to provide privacy and reliability between
	two communicating applications. The protocol is composed of two layers. At the lowest
	level, layered on top of some reliable transport protocol (e.g., TCP[TCP]), is the
	SSL Record Protocol. The SSL Record Protocol is used for encapsulation of various
	higher level protocols. One such encapsulated protocol, the SSL Handshake Protocol,
	allows the server and client to authenticate each other and to negotiate an encryption
	algorithm and cryptographic keys before the application protocol transmits or receives
	its first byte of data.
</DL>

<P>SSL has been characterized as extremely secure, primarily because the connection
security also incorporates the use of MD5. The protocol therefore provides connection
integrity as well as authentication. The design of SSL has been deemed sufficiently
secure that very powerful software firms have incorporated the technology into their
products. One such product is Microsoft's Internet Information Server.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>Microsoft's early implementation
	of SSL required that you obtain a certificate from a third party, in this case VeriSign.
	This certificate verified your identity, a contingency that not everyone is happy
	about. 
<HR>


</BLOCKQUOTE>

<P>SSL was unveiled to the world and largely accepted by security circles, primarily
because the system combined some of the most powerful encryption techniques currently
available. But the bright future of SSL soon met with dark and stormy skies. The
implementation initially introduced by Netscape Communications Corporation simply
wasn't strong enough. On September 19, 1995, news that SSL had been cracked was plastered
across the national headlines. As John Markoff noted in his article &quot;Security
Flaw Is Discovered In Software Used In Shopping,&quot; which appeared in <I>The New
York Times </I>on September 19, 1995:

<DL>
	<DD>A serious security flaw has been discovered in Netscape, the most popular software
	used for computer transactions over the Internet's World Wide Web, threatening to
	cast a chill over the emerging market for electronic commerce...The flaw, which could
	enable a knowledgeable criminal to use a computer to break Netscape's security coding
	system in less than a minute, means that no one using the software can be certain
	of protecting credit card information, bank account numbers or other types of information
	that Netscape is supposed to keep private during online transactions.
</DL>

<P>Several students (including Ian Goldberg and David Wagner) found that within minutes,
they could discover the key used in the encryption process. This (for a time, at
least) rendered SSL utterly useless for serious security.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>C source code has been
	posted to the Internet that you can use to attack the early, flawed implementations
	of SSL. You can get that source at <A HREF="http://hplyot.obspm.fr:80/~dl/netscapesec/unssl.c"><TT>http://hplyot.obspm.fr:80/~dl/netscapesec/unssl.c</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>The flaw is best expressed by the Netscape advisory (&quot;Potential Vulnerability
in Netscape Products&quot;) issued shortly after the story broke: