their customers’ details when they make their first order. This means that a customer is not required to type her details every time. Having asked for and received information from your visitor, you need a way to associate the information with the same user the next time she visits. If you are willing to make the assump- tion that only one person visits your site from a particular account on a particular machine and that each visitor only uses one machine, you could store a cookie on the user’s machine to identify the user. This is certainly not true for all users—frequently, many people share a com- puter, and many people use more than one computer. At least some of the time, you will need to ask a visitor who she is again. In addition to asking who a user is, you will also need to ask a user to provide some level of proof that she is who she claims to be. As discussed in Chapter 13, “E-commerce Security Issues,” asking a user to prove her identity is called authentication. The usual method of authentication used on Web sites is asking visi- tors to provide a unique login name and a password. Authentication is usually used to allow or disallow access to particular pages or resources, but can be optional, or used for other purposes such as personalization. Implementing Access Control Simple access control is not difficult to implement. The code shown in Listing 14.1 delivers one of three possible outputs. If the file is loaded without parameters, it will display an HTML form requesting a username and password. This type of form is shown in Figure 14.1. Implementing Authentication with PHP and MySQL C HAPTER 14 14 IMPLEMENTING AUTHENTICATION 305 FIGURE 14.1 Our HTML form requests that visitors enter a username and password for access. If the parameters are present but not correct, it will display an error message. Our error mes- sage is shown in Figure 14.2. 18 7842 CH14 3/6/01 3:35 PM Page 305 FIGURE 14.2 When users enter incorrect details, we need to give them an error message. On a real site, you might want to give a somewhat friendlier message. If these parameters are present and correct, it will display the secret content. Our test content is shown in Figure 14.3. E-commerce and Security P ART III 306 FIGURE 14.3 When provided with correct details, our script will display content. The code to create the functionality shown in Figures 14.1, 14.2, and 14.3 is shown in Listing 14.1. LISTING 14.1 secret.php—PHP and HTML to Provide a Simple Authentication Mechanism <? if(!isset($name)&&!isset($password)) { //Visitor needs to enter a name and password ?> <h1>Please Log In</h1> This page is secret. 18 7842 CH14 3/6/01 3:35 PM Page 306 <form method = post action = “secret.php”> <table border = 1> <tr> <th> Username </th> <td> <input type = text name = name> </td> </tr> <tr> <th> Password </th> <td> <input type = password name = password> </td> </tr> <tr> <td colspan =2 align = center> <input type = submit value = “Log In”> </td> </tr> </table> </form> <? } else if($name==”user”&&$password==”pass”) { // visitor’s name and password combination are correct echo “<h1>Here it is!</h1>”; echo “I bet you are glad you can see this secret page.”; } else { // visitor’s name and password combination are not correct echo “<h1>Go Away!</h1>”; echo “You are not authorized to view this resource.”; } ?> The code from Listing 14.1 will give you a simple authentication mechanism to allow autho- rized users to see a page, but it has some significant problems. This script • Has one username and password hard-coded into the script • Stores the password as plain text • Only protects one page • Transmits the password as plain text These issues can all be addressed with varying degrees of effort and success. Implementing Authentication with PHP and MySQL C HAPTER 14 14 IMPLEMENTING AUTHENTICATION 307 LISTING 14.1 Continued 18 7842 CH14 3/6/01 3:35 PM Page 307 Storing Passwords There are many better places to store usernames and passwords than inside the script. Inside the script, it is difficult to modify the data. It is possible, but a bad idea to write a script to modify itself. It would mean having a script on your server, which gets executed on your server, but is writable or modifiable by others. Storing the data in another file on the server will let you more easily write a program to add and remove users and to alter passwords. Inside a script or another data file, there is a limit to the number of users you can have without seriously affecting the speed of the script. If you are considering storing and searching through a large number of items in a file, you should consider using a database instead, as previously discussed. As a rule of thumb, if you want to store and search through a list of more than 100 items, they should be in a database rather than a flat file. Using a database to store usernames and passwords would not make the script much more complex, but would allow you to authenticate many different users quickly. It would also allow you to easily write a script to add new users, delete users, and allow users to change their pass- words. A script to authenticate visitors to a page against a database is given in Listing 14.2. L ISTING 14.2 secretdb.php—We Have Used MySQL to Improve Our Simple Authentication Mechanism <? if(!isset($name)&&!isset($password)) { //Visitor needs to enter a name and password ?> <h1>Please Log In</h1> This page is secret. <form method = post action = “secretdb.php”> <table border = 1> <tr> <th> Username </th> <td> <input type = text name = name> </td> </tr> <tr> <th> Password </th> <td> <input type = password name = password> </td> </tr> <tr> <td colspan =2 align = center> <input type = submit value = “Log In”> </td> E-commerce and Security P ART III 308 18 7842 CH14 3/6/01 3:35 PM Page 308 </tr> </table> </form> <? } else { // connect to mysql $mysql = mysql_connect( ‘localhost’, ‘webauth’, ‘webauth’ ); if(!$mysql) { echo ‘Cannot connect to database.’; exit; } // select the appropriate database $mysql = mysql_select_db( ‘auth’ ); if(!$mysql) { echo ‘Cannot select database.’; exit; } // query the database to see if there is a record which matches $query = “select count(*) from auth where name = ‘$name’ and pass = ‘$password’”; $result = mysql_query( $query ); if(!$result) { echo ‘Cannot run query.’; exit; } $count = mysql_result( $result, 0, 0 ); if ( $count > 0 ) { // visitor’s name and password combination are correct echo “<h1>Here it is!</h1>”; echo “I bet you are glad you can see this secret page.”; } else { Implementing Authentication with PHP and MySQL C HAPTER 14 14 IMPLEMENTING AUTHENTICATION 309 LISTING 14.2 Continued 18 7842 CH14 3/6/01 3:35 PM Page 309 // visitor’s name and password combination are not correct echo “<h1>Go Away!</h1>”; echo “You are not authorized to view this resource.”; } } ?> The database we are using can be created by connecting to MySQL as the MySQL root user and running the contents of Listing 14.3. LISTING 14.3 createauthdb.sql—These MySQL Queries Create the auth Database, the auth Table, and Two Sample Users create database auth; use auth; create table auth ( name varchar(10) not null, pass varchar(30) not null, primary key (name) ); insert into auth values (‘user’, ‘pass’); insert into auth values ( ‘testuser’, password(‘test123’) ); grant select, insert, update, delete on auth.* to webauth@localhost identified by ‘webauth’; Encrypting Passwords Regardless of whether we store our data in a database or a file, it is an unnecessary risk to store the passwords as plain text. A one-way hashing algorithm can provide a little more secu- rity with very little extra effort. E-commerce and Security P ART III 310 LISTING 14.2 Continued 18 7842 CH14 3/6/01 3:35 PM Page 310 The PHP function crypt() provides a one-way cryptographic hash function. The prototype for this function is string crypt (string str [, string salt]) Given the string str, the function will return a pseudo-random string. For example, given the string “pass” and the salt “xx”, crypt() returns “xxkT1mYjlikoII”. This string cannot be decrypted and turned back into “pass” even by its creator, so it might not seem very useful at first glance. The property that makes crypt() useful is that the output is deterministic. Given the same string and salt, crypt() will return the same result every time it is run. Rather than having PHP code like if( $username == “user” && $password == “pass” ) { //OK passwords match } we can have code like if( $username == ‘user’ && crypt($password,’xx’) == ‘xxkT1mYjlikoII’ ) { //OK passwords match } We do not need to know what ‘xxkT1mYjlikoII’ looked like before we used crypt() on it. We only need to know if the password typed in is the same as the one that was originally run through crypt(). As already mentioned, hard-coding our acceptable usernames and passwords into a script is a bad idea. We should use a separate file or a database to store them. If we are using a MySQL database to store our authentication data, we could either use the PHP function crypt() or the MySQL function PASSWORD(). These functions do not produce the same output, but are intended to serve the same purpose. Both crypt() and PASSWORD() take a string and apply a non-reversible hashing algorithm. To use PASSWORD(), we could rewrite the SQL query in Listing 14.2 as select count(*) from auth where name = ‘$name’ and pass = password(‘$password’) This query will count the number of rows in the table auth that have a name value equal to the contents of $name and a pass value equal to the output given by PASSWORD() applied to the con- tents of $password. Assuming that we force people to have unique usernames, the result of this query will be either 0 or 1. Implementing Authentication with PHP and MySQL C HAPTER 14 14 IMPLEMENTING AUTHENTICATION 311 18 7842 CH14 3/6/01 3:35 PM Page 311 Protecting Multiple Pages Making a script like this protect more than one page is a little harder. Because HTTP is state- less, there is no automatic link or association between subsequent requests from the same per- son. This makes it harder to have data, such as authentication information that a user has entered, carry across from page to page. The easiest way to protect multiple pages is to use the access control mechanisms provided by your Web server. We will look at these shortly. To create this functionality ourselves, we could include parts of the script shown in Listing 14.1 in every page that we want to protect. Using auto_prepend_file and auto_append_file, we can automatically prepend and append the code required to every file in particular directo- ries. The use of these directives was discussed in Chapter 5, “Reusing Code and Writing Functions.” If we use this approach, what happens when our visitors go to multiple pages within our site? It would not be acceptable to require them to re-enter their names and passwords for every page they want to view. We could append the details they entered to every hyperlink on the page. As users might have spaces, or other characters that are not allowed in URLs, we should use the function urlencode() to safely encode these characters. There would still be a few problems with this approach though. Because the data would be included in Web pages sent to the user, and the URLs they visit, the protected pages they visit will be visible to anybody who uses the same computer and steps back through cached pages or looks at the browser’s history list. Because we are sending the password back and forth to the browser with every page requested or delivered, this sensitive information is being trans- mitted more often than necessary. There are two good ways to tackle these problems: HTTP basic authentication and sessions. Basic authentication overcomes the caching problem, but the browser still sends the password to the browser with every request. Session control overcomes both of these problems. We will look at HTTP basic authentication now, and examine session control in Chapter 20, “Using Session Control in PHP,” and in more detail in Chapter 24, “Building User Authentication and Personalization.” Basic Authentication Fortunately, authenticating users is a common task, so there are authentication facilities built in to HTTP. Scripts or Web servers can request authentication from a Web browser. The Web E-commerce and Security P ART III 312 18 7842 CH14 3/6/01 3:35 PM Page 312 browser is then responsible for displaying a dialog box or similar device to get required infor- mation from the user. Although the Web server requests new authentication details for every user request, the Web browser does not need to request the user’s details for every page. The browser generally stores these details for as long as the user has a browser window open and automatically resends them to the Web server as required without user interaction. This feature of HTTP is called basic authentication. You can trigger basic authentication using PHP, or using mechanisms built in to your Web server. We will look at the PHP method, the Apache method, and the IIS method. Basic authentication transmits a user’s name and password in plain text, so it is not very secure. HTTP 1.1 contains a somewhat more secure method known as digest authentication, which uses a hashing algorithm (usually MD5) to disguise the details of the transaction. Digest authentication is supported by many Web servers, but is not supported by a significant number of Web browsers. Digest authentication has been supported by Microsoft Internet Explorer from version 5.0. At the time of writing, it is not supported by any version of Netscape Navigator, but might be included in version 6.0. In addition to being poorly supported by installed Web browsers, digest authentication is still not very secure. Both basic and digest authentication provide a low level of security. Neither gives the user any assurance that she is dealing with the machine she intended to access. Both might permit a cracker to replay the same request to the server. Because basic authentication transmits the user’s password as plain text, it allows any cracker capable of capturing packets to impersonate the user for making any request. Basic authentication provides a (low) level of security similar to that commonly used to con- nect to machines via Telnet or FTP, transmitting passwords in plaintext. Digest authentication is a little more secure, encrypting passwords before transmitting them. Using SSL and digital certificates, all parts of a Web transaction can be protected by strong security. If you want strong security, you should read the next chapter, Chapter 15, “Implementing Secure Transactions with PHP and MySQL.” However, for many situations, a fast, but rela- tively insecure, method such as basic authentication is appropriate. Basic authentication protects a named realm and requires users to provide a valid username and password. Realms are named so that more than one realm can be on the same server. Different files or directories on the same server can be part of different realms, each protected by a different set of names and passwords. Named realms also let you group multiple directo- ries on the one host or virtual host as a realm and protect them all with one password. Implementing Authentication with PHP and MySQL C HAPTER 14 14 IMPLEMENTING AUTHENTICATION 313 18 7842 CH14 3/6/01 3:35 PM Page 313 Using Basic Authentication in PHP PHP scripts are generally cross-platform, but using basic authentication relies on environment variables set by the server. In order for an HTTP authentication script to run on Apache using PHP as an Apache Module or on IIS using PHP as an ISAPI module, it needs to detect the server type and behave slightly different. The script in Listing 14.4 will run on both servers. LISTING 14.4 http.php—PHP Can Trigger HTTP Basic Authentication <? // if we are using IIS, we need to set $PHP_AUTH_USER and $PHP_AUTH_PW if (substr($SERVER_SOFTWARE, 0, 9) == “Microsoft” && !isset($PHP_AUTH_USER) && !isset($PHP_AUTH_PW) && substr($HTTP_AUTHORIZATION, 0, 6) == “Basic “ ) { list($PHP_AUTH_USER, $PHP_AUTH_PW) = explode(“:”, base64_decode(substr($HTTP_AUTHORIZATION, 6))); } // Replace this if statement with a database query or similar if ($PHP_AUTH_USER != “user” || $PHP_AUTH_PW != “pass”) { // visitor has not yet given details, or their // name and password combination are not correct header(‘WWW-Authenticate: Basic realm=”Realm-Name”’); if (substr($SERVER_SOFTWARE, 0, 9) == “Microsoft”) header(“Status: 401 Unauthorized”); else header(“HTTP/1.0 401 Unauthorized”); echo “<h1>Go Away!</h1>”; echo “You are not authorized to view this resource.”; } else { // visitor has provided correct details echo “<h1>Here it is!</h1>”; echo “<p>I bet you are glad you can see this secret page.”; } ?> E-commerce and Security P ART III 314 18 7842 CH14 3/6/01 3:35 PM Page 314 . need to set $PHP_ AUTH_USER and $PHP_ AUTH_PW if (substr($SERVER_SOFTWARE, 0, 9) == “Microsoft” && !isset( $PHP_ AUTH_USER) && !isset( $PHP_ AUTH_PW) && substr($HTTP_AUTHORIZATION,. one password. Implementing Authentication with PHP and MySQL C HAPTER 14 14 IMPLEMENTING AUTHENTICATION 313 18 7842 CH14 3/6/01 3:35 PM Page 313 Using Basic Authentication in PHP PHP scripts. “ ) { list( $PHP_ AUTH_USER, $PHP_ AUTH_PW) = explode(“:”, base64_decode(substr($HTTP_AUTHORIZATION, 6))); } // Replace this if statement with a database query or similar if ( $PHP_ AUTH_USER != “user” || $PHP_ AUTH_PW