|
| ||
|
| Forward to CGI Scripts |
Individual documents or whole directories are protected in such a way that only browsers connecting from certain IP (Internet) addresses, IP subnets, or domains can access them.
Documents or directories are protected so that the remote user has to provide a name and password in order to get access.
Both the request for the document and the document itself are encrypted in such a way that the text cannot be read by anyone but the intended recipient. Public key cryptography can also be used for reliable user verification. See below.
IP address restriction can be made much safer by running your server behind a firewall machine that is capable of detecting and rejecting attempts at spoofing IP addresses. Such detection works best for intercepting packets from the outside world that claim to be from trusted machines on your internal network.
One thing to be aware of is that if a browser is set to use a proxy server to fetch documents, then your server will only know about the IP address of the proxy, not the real user's. This means that if the proxy is in a trusted domain, anyone can use that proxy to access your site. Unless you know that you can trust a particular proxy to do its own restriction, don't add the IP address of a proxy (or a domain containing a proxy server) to the list of authorized addresses.
Restriction by host or domain name has the same risks as restriction by IP address, but also suffers from the risk of "DNS spoofing", an attack in which your server is temporarily fooled into thinking that a trusted host name belongs to an alien IP address. To lessen that risk, some servers can be configured to do an extra DNS lookup for each client. After translating the IP address of the incoming request to a host name, the server uses the DNS to translate from the host name back to the IP address. If the two addresses don't match, the access is forbidden. See below for instructions on enabling this feature in NCSA's httpd
Another problem is that the password is vulnerable to interception as it is transmitted from browser to server. It is not encrypted in any meaningful way, so a hacker with the right hardware and software can pull it off the Internet as it passes through. Furthermore, unlike a login session, in which the password is passed over the Internet just once, a browser sends the password each and every time it fetches a protected document. This makes it easier for a hacker to intercept the transmitted data as it flows across the Internet. To avoid this, you have to encrypt the data. See below.
If you need to protect documents against _local_ users on the server's host system, you'll need to run the server as something other than "nobody" and to set the permissions of both the restricted documents and server scripts so that they're not world readable. See Q9.
<Directory /full/path/to/directory>
<Limit GET POST> order mutual-failure deny from all allow from 192.198.2 .zoo.org allow from 18.157.0.5 stoat.outback.au </Limit> </Directory>
This will deny access to everybody but the indicated hosts (18.157.0.5 and stoat.outback.au), subnets (182.198.2) and domains (.zoo.org). Although you can use either numeric IP addresses or host names, it's safer to use the numeric form because this form of identification is less easily subverted (Q18).
One way to increase the security of restriction by domain name is to
make sure that your server double-checks the results of its DNS
lookups. You can enable this feature in
NCSA's httpd (and the related Apache server) by making sure that the
-DMAXIMUM_DNS flag is set in the Makefile.
For the CERN server, you'll need to declare a protection scheme with the Protection directive, and associate it with a local URL using the Protect directive. An entry in httpd.conf that limits access to certain domains might look like this:
Protection LOCAL-USERS {
GetMask @(*.capricorn.com, *.zoo.org, 18.157.0.5)
}
Protect /relative/path/to/directory/* LOCAL-USERS
Check your server documentation for the precise details of how to add new users. For NCSA httpd, you can add a new user to the password file using the htpasswd program that comes with the server software:
htpasswd /path/to/password/file usernamehtpasswd will then prompt you for the password to use. The first time you invoke htpasswd you must provide a -c flag to create the password file from scratch.
The CERN server comes with a slightly different program called htadm:
htadm -adduser /path/to/password/file usernamehtadm will then prompt you for the new password.
After you add all the authorized users, you can attach password protection to the directories of your choice. In NCSA httpd and its derivatives, add something like this to access.conf:
<Directory /full/path/to/protected/directory>
AuthName name.of.your.server
AuthType Basic
AuthUserFile /usr/local/etc/httpd/conf/passwd
<Limit GET POST>
require valid-user
</Limit>
</Directory>
You'll need to replace AuthUserFile with the full path to the password
file. This type of protection can be combined with IP address
restriction as described in the previous section. See NCSA's online
documentation (http://hoohoo.ncsa.uiuc.edu/) or the author's book (How to Set Up and Maintain a
Web Site) for more details.
For the CERN server, the corresponding entry in httpd.conf looks like this:
Protection AUTHORIZED-USERS {
AuthType Basic
ServerID name.of.your.server
PasswordFile /usr/local/etc/httpd/conf/passwd
GetMask All
}
Protect /relative/path/to/directory/* AUTHORIZED-USERS
Again, see the documentation or the author's book for details.
http://www.genome.wi.mit.edu/~lstein/user_manage/
Bill Jones has written a multi-purpose script called WebPass. In addition to allowing users to change their Web passwords, they can also change their POP, log-in and news passwords, if they have them. It uses a combination of Perl and Expect to do its magic. You can find it at:
http://webmaster.fccj.cc.fl.us/Webmaster/WebPass.htmlSeveral vendors of commercial Web servers also offer remote user administration scripts. See your server documentation for details.
http://your.site.com/protected/directory/.htaccessThis is clearly an undesirable feature since it gives out important information about your system, including the location of the server password file.
Another problem with the the per-directory access files is that if you ever need to change the server software, it's a lot easier to update a single central access control file than to search and fix a hundred small files.
Most practical implementations of secure Internet encryption actually combine the traditional symmetric and the new asymmetric schemes. Public key encryption is used to negotiate a secret symmetric key that is then used to encrypt the actual data.
Since commercial ventures have a critical need for secure transmission on the Web, there is very active interest in developing schemes for encrypting the data that passes between browser and server.
More information on public key cryptography can be found in the book "Applied Cryptography", by Bruce Schneier.
SSL (Secure Socket Layer) is the scheme proposed by Netscape Communications Corporation. It is a low level encryption scheme used to encrypt transactions in higher-level protocols such as HTTP, NNTP and FTP. The SSL protocol includes provisions for server authentication (verifying the server's identity to the client), encryption of data in transit, and optional client authentication (verifying the client's identity to the server). SSL is currently implemented commercially on several different browsers, including Netscape Navigator, Secure Mosaic, and Microsoft Internet Explorer, and many different servers, including ones from Netscape, Microsoft, IBM, Quarterdeck, OpenMarket and O'Reilly and Associates. Details on SSL can be found at:
http://home.netscape.com/products/security/ssl/index.html
SHTTP (Secure HTTP) is the scheme proposed by CommerceNet, a coalition of businesses interested in developing the Internet for commercial uses. It is a higher level protocol that only works with the HTTP protocol, but is potentially more extensible than SSL. Currently SHTTP is implemented for the Open Marketplace Server marketed by Open Market, Inc on the server side, and Secure HTTP Mosaic by Enterprise Integration Technologies on the client side. See here for details:
http://www.eit.com/creations/s-http/
Shen is scheme proposed by Phillip Hallam-Baker of CERN. Like SHTTP it is a high level replacement for the existing HTTP protocol. Although it has existed as a proposal for nearly two years, no browser or server vendor has implemented it. Further, the URL that described it is no longer available, so for all intents and purposes it can be considered moribund.
There are several components to this software. You will need to obtain and install them all in order to have a working SSL-based Web server:
After installing an SSL-enabled server you will need to obtain a server certificate from a certifying authority. Server certificates are avalable from a number of different companies, each with a slightly different application procedure and fee schedule. In the United States, the VeriSign Corporation was the first and still most widely used certifying authority. Because of a recent fee increase ($495 for a commercial server certificate), however, VeriSign is currently one of the more expensive agencies. A good alternative to VeriSign is Thawte Consulting; its fees are significantly lower and its application procedure for non-American organization is far less of a hassle. Other certifying authorities include:
The process of obtaining a server certificate is slightly different from CA to CA, but follows the same basic outline. After choosing a certifying authority, connect to its Web site and find the server certificate application section. From here locate the appropriate application form for your server software, and fill it out. You'll be asked to provide your Web site's domain name, company name, and contact information. You'll also be asked to provide documentation, such as a Dun and Bradstreet number, articles of incorporation, or a notarized letter from the bursar of your college to prove the identity of your organization. You'll also be asked to provide payment information, such as a credit card number.
The application form is only half of the process. You'll also need to generate an electronic certificate request. After submitting the application form to the CA, you'll use a program provided with your server software to generate a public/private key pair. In the Apache-SSL distributions, the program is calledgenkey.
After generating the key pair, the key generation software will create a file containing the key request. In some cases it will automatically mail the file to the CA. In other cases, it will ask you to manually mail the file to the CA. In either case there will now be a wait of days to weeks while the CA confirms the validity of your request. Eventually you will receive a signed certificate by return e-mail. You then complete the process by installing the signed certificate on your server. The details again vary from server to server. For Apache-SSL you'll use a program called getca.
At this point users will be able to retrieve documents from your server and to submit forms without fear of interception. Your server's certificate provides remote users with proof of your server's identity.
Users can obtain inexpensive personal certificates from VeriSign. VeriSign offers two classes of certificate. Class 1 certificates cost a mere $9.95 yearly, but provide no assurance that the user is who he or she claims to be because VeriSign performs no validation of the information submitted by the user on the application form. At most, class 1 certificates certify that the user can receive e-mail at the address provided in the application. Class 2 certificates, available for $19.95 yearly, provide a greater level of assurance. In order to obtain such a certificate, the user must provide personal identifying information that is validated by a credit bureau.
If you are running an intranet, you may wish to issue personal certificates yourself, in order to provide fine-grained access control to employees of your organization. To do this, you will need to obtain and install a certificate server. Such systems are available from Microsoft, Netscape, XCert, Entrust and GTE.
To use personal certificates for access control, your server will need to be specially configured. The mechanics of setting this up are beyond the scope of this document, but detailed directions can be found in the author's book, Web Security: A Step-by-Step Reference Guide.
Even with an encrypting server, you should be careful about what happens to the credit card number after it's received by the server. For example, if the number is received by a server script, make sure not to write it out to a world-readable log file or send it via e-mail to a remote site.
Before making purchases with the First Virtual system, the consumer first signs up for a First Virtual account by filling out an on-line application form at First Virtual's site (see below). The consumer then completes the process by telephone. During the sign up procedure he provides his credit card number and contact information, and receives a First Virtual personal identification number (PIN) in return. Thereafter, to make purchases at participating online vendors, the user provides his First Virtual PIN in lieue of his credit card information. First Virtual will later contact him by e-mail, giving him the chance to approve or disapprove the purchase before his credit card is billed. The consumer pays a one-time charge of $2.00 to open a First Virtual account. There are no additional charges, and no special software is required on the user's side of the connection.
Merchants wishing to accept First Virtual payments must open up an account with First Virtual for a one-time processing fee of $10.00. First Virtual will provide the merchant with simple software for validating users' PIN numbers and notifying First Virtual when a purchase has been made. It's straightforward to integrate this software into a "shopping cart" style CGI script. In addition to the one-time fee, First Virtual charges the merchant a transaction fee of $0.29 per transaction, plus 3% of the transaction price.
More information on First Virtual can be obtained at:
The software that supports DigiCash prevents the CyberBucks from being forged or spent more than once. Like true cash, DigiCash can be spent anonymously. You do not have to authenticate yourself in order to spend or receive DigiCash, and its use leaves no audit trail. This is in contrast to credit-card based systems like CyberCash and SET in which every transaction leaves a paper trail that can be used to gather information about the consumer's spending habits. In addition, DigiCash can be used to transmit money safely between peers, allowing ordinarily people to sell merchandise and services across the Internet without involving the banking system.
DigiCash requires special software to be installed on both the consumer's and merchant's computers. It is currently available for Windows NT, Windows 95, and some Unix systems. Since the system has only recently come out of its pilot phase it is not yet widely adopted, but this situation is expected to change. For more information, including a listing of DigiCash-accepting banks, see:
When a user goes to purchase an item from a CyberCash-accepting merchant, the wallet software pops up and requests the user to select the payment system. He may choose to charge the purchase against a credit card, in which case the charge will appear on his next credit card statment, or against his bank account, in which case the sum will be debited immediately. Software installed on the merchant's side of the connection validates and records the transaction by connecting to a server maintained by CyberCash, a process that takes 10-15 seconds. The Wallet maintains a record of each transaction, allowing the user to rapidly review his purchases and check taem against his credit card and/or bank statement. It is available for many platforms, including Macintosh, Windows 95 and Windows NT.
The system uses strong cryptography to prevent transaction information from being intercepted by unauthorized third parties. Further, because actual credit card account numbers are never recorded on the merchant's server, there is no chance that credit card numbers can be stolen by individuals who have broken into the merchant's computer system.
For a merchant to accept CyberCash payments he must open an account with a bank that supports the system. A CyberCash account is similar to the checking account that is set up for mail order houses that accept conventional credit card orders and has similar fees: a one-time fee of approximately $100 to create the account, a monthly fee of approximately $15 to keep the account open, and a transaction fee of 2-3% of the purchase price of each transaction. The exact fees are set by the regional banks themselves, so the numbers will vary somewhat. There are currently several hundred banks that support CyberCash accounts, and the number is growing steadily.
After setting up a CyberCash account, the merchant must install software called the "Electronic Cash Register" on his Web server. This software is launched when the user presses the "pay" button in a shopping cart script (or equivalent), and takes over the transaction, creating an entry in a transaction log that the merchant can feed into his order entry and shipping systems. The Cash Register is downloadable free of charge and available for many platforms, including Windows NT and Unix.
The main advantage of CyberCash over DigiCash is that it provides the customer with the same degree of consumer protection that credit cards provide. If a merchant fails to deliver a product or delivers unsatisfactory merchandise, the customer can appeal to the credit card company. Disadvantages include the loss of anonymity that accompanies any credit or debit card transaction, and the inability of CyberCash to handle peer to peer payments. In addition, the fees charged to merchants for processing credit card transactions make CyberCash impractical for small purchases, such as "play per pay" on-line video games. This last problem, however, has been addressed by CyberCash's recently-introduced "CyberCoin" system, which allows the customer to pay a lump sum to CyberCash in advance and then make small purchases against this sum.
More information on CyberCash is available at: http://www.cybercash.com
To address the high potential for fraud on the Internet, the SET standard uses a complex system of certifying authorities to vouch for the identify of every party in the transaction: customer, merchant, card-issuer and merchant's bank are all identified by signed, unforgeable certificates. To address privacy concerns, the transaction is separated in such a way that the merchant has access to information about what is being purchased, how much it costs, and whether the payment is approved, but no information on what payment method the customer is using. Similarly, the card-issuer has access to the purchase price, but no information on the type of merchandise involved. Despite these precautions, however, SET does not provide the complete anonymity that the DigiCash system has.
SET requires specialized software on both the customer's and merchant's side of the connection. On the customer's side, at least, the software can be delivered transparently in the form of Java Applets and/or ActiveX controls. Two SET-compliant products are currently in the offing. Microsoft Merchant is an Internet commerce system offered by the Microsoft Corporation. Based around Microsoft's Internet Information Server, Microsoft Merchant offers online credit card validation services using the Verifone service. In addition, Microsoft Merchant provides such frills as catalog management, shopping cart scripts, and sales tax calculations. Microsoft Merchant was in beta test in November 1996, but should be available by the time you read this.
For its part, the Netscape Corporation, in collaboration with its strategic partner First Data, offers LivePayment. This is an optional module for the Netscape Secure Commerce Server which provides secure credit card submission, validation and processing. You can add other modules to provide automatic catalog and inventory management, shopping carts, and corporate database interfaces. In its current incarnation, LivePayment uses a precursor to SET that is similar, but not identical, to the standard. A fully SET-compliant version of LivePayment is expected shortly.
|
| ||
|
| Forward to CGI Scripts |
Lincoln D. Stein ([email protected])
Last modified: Sun Dec 20 15:09:13 MET 1998