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.
Section 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 Section 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. Section 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. Section 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.
