Scenario is simple. Your application has three modules and each module needs to be accessible to users with different priviledges:

1. ‘default’ module – accessible to all users and guests
2. ‘member’ module – accessible only to registered users
3. ‘admin’ module – accessible only to registered users with administrator priviledges

I will go step by step and explain all parts in depth:

• database table and model
• registration form
• registration controller action
• login form
• login controller action
• logout controller action
• authentication controller plugin
• recommended reading

Database table and model

Let’s create a database table that will store all users:

CREATE TABLE users (
id INT NOT NULL AUTO_INCREMENT,
first_name VARCHAR(255) NOT NULL,
last_name VARCHAR(255) NOT NULL,
email VARCHAR(255) NOT NULL,
username VARCHAR(255) NOT NULL,
password_hash VARCHAR(255) NOT NULL,
role VARCHAR(255) NOT NULL,
status VARCHAR(255) NOT NULL,
INDEX (first_name),
INDEX (last_name),
INDEX (username),
INDEX (email),
PRIMARY KEY (id)
) ENGINE = INNODB;

The ‘role’ column will hold a user access level, for example: ‘user’, ‘administrator’ etc. The ‘status’ column could have ‘pending’ and ‘approved’ possible values which would allow administrators to approve freshly registered users before they could access private parts of the website.

I put INDEX on ‘first_name’, ‘last_name’, ‘username’ and ‘email’ fields because are often be used instead of the ‘id’ to fetch a single user.

You will also need a model representing the table. Here is a very simple model, in a real-life application you will certainly need more methods (for editing and removing users etc):

Notice this line in the add() method:

What it does is it first prepends the salt to the plain text password and then create an sha1 hash which can be safely stored in the database.

Registration form

Unless you want to create user accounts manually you should allow guests to register. The registration form:

The form is straightforward – a single form element per table column (except ‘id’, ‘role’ and ‘status’). I always use my custom decorators which produce the markup I want.

Registration controller action

First of all, in order to eliminate duplicate rows in the database we check for users with the same username or email before continuing. We also make sure a user correctly filled in both email input fields and both password input fields.

Afterwards, an email with a verification string (which happens to be an sha1 hash of the user email) is sent to the user and a new account is created. I use a handy action helper to generate a random string (in this case used as a salt):

By clicking on the link the user is taken to the email verification page:

Login form

The login form is quite simple. It contains just two input fields (for username and password) and a “Remember me?” checkbox:

Login controller action

Notice this line:

The argument of the setCredentialTreatment() method is probably confusing, it’s a little more complex SQL expression. What it does is it compares the entered password with the password_hash from the database (substitute the entered password for the question mark). CONCAT() is a MySQL function for concating strings (in PHP it’s done with the concatenation operator – ‘.’), SUBSTRING() is very similar to the PHP’s substr() (the only difference is the first character has index 1 in MySQL and 0 in PHP), SHA1() is the same as sha1() in PHP.

Logout controller action

Authentication controller plugin

I always use a controller plugin for authentication. You could possibly do it in controllers (let’s say in the init() method) but I find the controller plugin to be an ideal for this purpose:

As you can see, there are different access rules for each module. It’s not terribly difficult to create more comples access rules. The one thing you must understand is that (quoted from the Zend Framework documentation):

In general, Zend_Acl obeys a given rule if and only if a more specific rule does not apply.

For instance, let’s say you want to disallow logged in users from accessing the login form:

You can also specify actions in the access rules:

One more thing, you need to register the plugin so it works. I usually do it in the bootstrap file:

You need to add the ‘My_’ namespace to the application config file, too:

autoloaderNamespaces[] = "My_"

Recommended reading

• My favorite Zend_Form decorators configuration
• Extending Zend_Form
• Password hashes and salts

What is a hash? A hash is the result of a one-way mathematical process which creates a unique string. The string is next to impossible to decode in order to recover the original text. This makes it an ideal way of storing sensible data in databases – especially passwords.

There are many hashing algorithms, most widely used are MD5 (128-bit) and sha1 (160-bit). Researchers found out that MD5 and also SHA1 are less secure than previously thought so if security is your top priority, you should look for some more advanced algorithms (256-bit or 512-bit). But for usual applications SHA1 is still very secure.

Example: Simple user authorization using sha1 hash

Let’s create a simple table for users:

CREATE TABLE users (
id INT NOT NULL AUTO_INCREMENT,
username VARCHAR(255) NOT NULL,
password_hash VARCHAR(255) NOT NULL,
PRIMARY KEY (id)
) ENGINE = INNODB;

When user registers, you ought to save only a hash of the password in the database:

When a user attempts to log in, you just need to compare a hash of the user entered password to the hash stored in the database:

Salt improvement

Even though storing only hashed passwords in the database is already very safe, there is a weakness which can be exploited. If an attacker gains access to the database, he will be able to say that users with the same password hash must also have the same password. This information would be still useless but the attacker can use the ‘ brute forcing’ (generate numerous potential password hashes – either randomly generated or from a dictionary – and compare them with hashes in the database) to decode user passwords.

Strong passwords (containing letters, numbers and other symbols) are secure even against the ‘brute forcing’ attacks but users often like short passwords containing only letters or only letters and numbers. This weakness can be overcome by using a ‘salt’. Salt is a randomly generated string which is prepended to a plain text password before using a hasing algorithm. You need a function for creating a random string:

User registration will now look a little differently:

And when a user attempts to log in: