Protecting Member Areas with Cookies

Some methods of protecting member areas with cookies have better security than other ways. Some member areas need a high level of security. Other's don't.

First, let me mention that storing passwords in cookies is flagrantly insecure. More so now than in the past, with active cookie sniffing connections expected at any public WiFi connection.

One thing that needs to be considered is the type of member data being stored on the server. If credit card information or other highly sensitive data, then do whatever is necessary for the best security that can be coded.

Similarly, if the member area itself contains highly sensitive data.

Without sensitive data in member records or available in member areas, security is less critical.

It is the less critical member areas that this article addresses. Security for highly sensitive data, like banking for example, require the services of an experienced professional online security expert.

Protecting Entire Directories

All files in an entire directory can be protected with a cookie. The cookie can have any value. So long as the cookie exists in the browser, the browser can access files within the directory.

Each directory to be protected has something like this in its .htaccess file:

RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_COOKIE} !COOKIENAME= [NC]
RewriteRule .* http://example.com/login.php [L]

Replace COOKIENAME with the required cookie name. And replace the login page URL with the correct one.

Cookie Value Keyed To Member Record

For cookie protection at the page level, both the cookie name and the cookie value are validated. For better protection, the cookie value contains a key to the member's data record and also info from the record itself, perhaps the member's email address.

Individual web pages are protected by validating the cookie value. If the data record exists and the data matches, the page load is allowed.

This works for PHP web pages located anywhere in the domain's document directory.

Files containing page elements that need to be protected (videos, spreadsheets) can be put into a cookie protected directory as described in the above "Protecting Entire Directories" section.

It is possible to spoof this cookie. To do the spoof, however, the member data record key and the specific data from the member record need to be known or guessed.

Better Security with Temporary Cookie Values

With this method, the cookie value is still keyed to the member record. The better security comes from the temporary nature of the cookie value.

The cookie value changes every time a member page is loaded into the browser. This makes cookie spoofing hard to do, well nigh impossible for all but the thoroughly skilled.

If a page load presents a cookie with the correct value, two things happen as the browser loads the page:

1. A cookie with a new value is sent to the browser.

2. The new cookie value is recorded in the member record.

On the other hand, if a page load is attempted with a cookie value different than expected, these two things happen:

1. The expected cookie value in the member record is removed (to prevent repeated guessing attempts).

2. The browser is redirected to the log-in form.

Additional Considerations

Password encryption.

For better security, passwords should be encrypted in the database.

It can be argued that encrypted passwords would prevent password recovery. Yes, that is correct. No unencrypted version of the password should be available anywhere on the server.

Instead of password recovery, let the member specify a new password.

Secure login.

For a short article about login security, see the Login Security article.

Will Bontrager