PHP CookBook

14.1 Introduction

In a perfect world, encryption wouldn't be necessary. Nosy people would keep their eyes on their own data, and a credit card number floating around the Internet would attract no special attention. In so many ways, however, our world isn't perfect, so we need encryption.

Encryption scrambles data. Some data scrambling can't be unscrambled without unreasonable amounts of processing. This is called one-way encryption . Other encryption methods work in two directions: data is encrypted; then it's decrypted.

PHP supplies tools to encrypt and secure your data. Some tools, such as the crypt( ) and md5( ) functions, are part of PHP's base set of functions, and some are extensions that need to be explicitly included when PHP is compiled (e.g., mcrypt, mhash, and cURL).

The crypt( ) function does one-way DES encryption using the first eight characters of plaintext to calculate the ciphertext. You pass it the plaintext to encrypt (and a salt, which strengthens the encryption), and it returns the encrypted ciphertext. PHP generates a random salt if you don't supply one:

print crypt('shrimp','34');
34b/4qaoXmcoY

If the constant CRYPT_MD5 is set to 1, crypt( ) can do MD5 encryption. To tell PHP to use MD5 encryption, start the salt with $1$:

print crypt('shrimp','$1$seasalt!');
$1$seasalt!$C8bRD475BC3T4EvjjmR9I.

Recipe 14.5 discusses crypt( ). It is most widely used for encrypting passwords.

mcrypt is a more full-featured encryption library that offers different algorithms and encryption modes. Because it supports different kinds of encryption, mcrypt is especially helpful when you need to exchange encrypted data with other systems or with programs not written in PHP. mcrypt is discussed in detail in Recipe 14.8.

PHP gives you the tools to protect your data with robust encryption, but encryption is just part of the large and often complex security picture. Your encrypted data can be unlocked with a key, so protecting that key is very important. If your encryption keys are accessible to unauthorized users (because they're stored in a file accessible via your web server or because they're stored in a file accessible by other users in a shared hosting environment, for example), your data is at risk, no matter how airtight your chosen encryption algorithm is.

You need to determine how secure you want your data to be. Encrypting it is more secure but more complex. Simpler encoding hides your data from elementary prying eyes but offers less security. No encryption or security is absolute. Picking an appropriate security method means finding a place on the spectrum between convenience and protection. The more convenient (or computationally inexpensive) types of security generally provide less protection. Sometimes your goal isn't to protect data from prying eyes but to avoid the appearance of impropriety. Seeing a plaintext field in a form (or URL) named "Password" could be more disturbing to your users than the same data wrapped in Base64 encoding. Recipe 14.3 shows how to obscure data with Base64.

Sensitive data needs to be protected not just on the server but also when it's traveling on the network between your server and your users. Data sent over regular HTTP is visible to anybody with access to the network at any point between your server and a user. Recipe 14.11 discusses how to layer HTTP over SSL to prevent network snoopers from peeping at data as it passes by.

There are plenty of nontechnical prerequisites to tight security. Assigning passwords that are a random jumble of letters, numbers, and punctuation does no good if those passwords are so hard to remember that users write them on sticky notes attached to their monitors. As we have already said, security is not an absolute, but a tradeoff between convenience and protection. As you use the recipes in this chapter to protect your data, decide what is an acceptable risk for your data versus the corresponding appropriate level of inconvenience that security introduces.^[1]

^[1] Practical Unix and Internet Security, by Simson Garfinkel and Gene Spafford (O'Reilly) offers some helpful and (not surprisingly) practical advice on how to think about the balancing act of risk management.