Username Password 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 pro
Trang 1their 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
14
F IGURE 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
Trang 2F IGURE 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
F IGURE 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
L ISTING 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.
Trang 3<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
14
L ISTING 14.1 Continued
Trang 4Storing 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>
Trang 5</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 {
14
L ISTING 14.2 Continued
Trang 6// 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
L ISTING 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
Trang 7The 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 $nameand 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 0or 1
14
Trang 8Protecting 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_fileand 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
Trang 9browser 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
14
Trang 10Using 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
L ISTING 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.”;
}
?>