So I was handed an ancient project which was up to me to fix / improve. About a week later I am about done but there is 1 thing I left...Login security. As it is now, it's just md5(password) that's saved in the database. Better then nothing, but far from good enough. My plan was to have a constant pepper in the class which handles the logins, then do something like crypt(pepper . $password) to store it, since that should generate a random salt and is slower then sha1 / md5 / etc. I feel this should be save enough, do any of you have any ideas on how to improve it (without non-standard extensions)?

There's lots of comments so far and a lot of them are following along the same lines - use a better method of encryption, something like crypt with Blowfish or something similar as well as some hashing (like HMAC).

Public/private key based encryption is very popular because of the strength it sets in encryption, specially above 1024 bits. Now there are external library to encrypt data using RSA encryption like RSA in phpclasses.org - the fun is we were also using this library in one of our ZF based project. But last week I've found that there is a hidden gem in the Library/Zend/Crypt folder (Zend_Crypt_Rsa) which can do the same thing using openssl library.

He couldn't find much in the way of documentation for the component, so he wrote up how to use it in three easy steps:

• Create your RSA public/private key using ssh-keygen
• Encrypt data using your public key
• Decrypt the cipher

The Zend_Crypt_Rsa makes it simple to encrypt/decrypt the data, just taking in a passphrase, a path to the RSA key file and the message contents.

As earlier I'd encountered Zends wonderful Zend_Filter class, I decided to go with it and use the Zend_Filter_Encrypt and Zend_Filter_Decrypt to accomplish the work. The Zend_Filter component provides a set of common useful data filters, among which are the encryption filters. Although my project was not developed in Zend, I could easily integrate the required classes in the code. Note that Zend has a great upload library, Zend_File_Transfer, that lets you easily manage file uploading and also encryption, but as I already had the upload code tested, I decided to just add the encryption part.

He includes the step-by-step process to get everything you need and which files you'll need to have included from the framework to make things work. He includes code for both encrypting and decrypting the file information as well as hints on selecting an algorithm and a random initialization vector. You can download the complete source if you want to jump right in.

There have been a couple of approaches I've been considering [to replace sessions being stored in the database], one of which is simply storing all the information in a browser cookie. First I want to make clear I don't necessarily condone this. The reason I'm writing this post, is because I'm hoping for some more community feedback. Is this a really bad idea? I would love to know.

He includes some code to make it happen - a class that uses the hash_hmac function and a SHA1 encryption type (along with a salt) to convert the information into a string that can be (relatively) safely stored in a cookie. Be sure to read the comments for more opinions on the method.

One crucial part of PHP development practice is always keeping in mind that security is not something you can simply buy off the shelf at your local convenient store. Ensuring the security of your web applications is a process, which over time, needs to be constantly evaluated, monitored, and hardened.

He shows a few methods you can use to secure things - generating random values, making random passwords to give to your users, creating salted passwords, obfuscation and an overview of cryptography in PHP. Complete source code is included.

Think about what we might need a class like this for? We want to encrypt important data with a password for security reasons. We also want, as already mentioned, to be able to decrypt that data when necessary. Why should you use symmetric algorithms? It's easy; when you're offering a password sent via email or something like that, you need the password to be sent in plaintext. The hash algorithms are not reversible. Once you have hashed a string you can't decipher the original text from the hash.

He lays out his basic class with three methods - the constructor that sets up the key and algorithm and the encrypt and decrypt functions. These use to mcrypt functions to handle the heavy lifting.

While GnuPG works very well as a standalone tool, it also plays very well with PHP. This integration is possible due to PHP's ext/gnupg extension, which provides a flexible and powerful API to access GnuPG functions for encryption, decryption, message signing and verification, and key maintenance. And your mission (should you choose to accept it) will be to accompany me over the next few pages, while I give you a crash course in this API, showing you how easy it is to integrate these functions into your next PHP application.

The tutorial walks you through some of the basic concepts behind the "lock and key" GnuPG implements and how to get the extension installed so you can follow along. His examples range from a basic encryption of a string out to a full encrypt/decrypt example, how to sign information with a key and even a method for sending an encrypted message.

Every good programmer knows, that passwords should never be stored in clear text. Instead a one way hash (or digest) should be used. This way user passwords are not at risk in case of an intrusion.

He points out the multiple ways that PHP offers for both simple hashing (like md5 or sha1) and the true encryption types (like ssha, apr1 and crypt). He shows how they work in the DokuWiki application via a call to auth_cryptPassword to make it and db_get_hash/auth_verifyPassword to check against it.

Needed a mechanism to be able to pass chunks of data securely from PHP to Java [...] One solution might be something "from scratch" involving mcrypt or PHP libraries like Crypt_RSA. [...] Another approach is GnuPG, either via the command line as discussed in this tutorial or via the GnuPG extension from PECL.

Option 3 is using OpenSSL and PHP's openssl_seal() function. SSL is normally used for encrypting networked communication between peers but that's not all it can do. [...] What's more - and perhaps the biggest win - it also allows us to re-use existing SSL certificates.

He uses the openssl_seal functionality on top of the EVP encrypted envelope on the certificate to handle the encrypt/decrypt of the data. Both the PHP code and Java code (and execution example) are included in the post.

To start, I will focus on the paragraph above. What I get out of that is that if only your source was closed and hidden from prying eyes, it would not have bugs in it. Which is, of course, total nonsense. Code has bugs because it's open and they feel safer? There are two kinds of bugs: application bugs (which is the code I would write) and system bugs (in this case, bugs that that appear from PHP itself). I'm sorry, but there is nothing I can do if there is a bug in PHP that causes my application to crash except to point this bug out to the people who have the ability to fix it.

He goes on to talk more about how protection like this (the article talks about using the IonCube Encoder) will not stop someone if they're really determine to get at the code underneath the encryption. His only suggestion is to make an application good enough that people wouldn't want to try to steal it as much and would rather pay for their version.

Encode your stuff if you want, but be aware that the minute you choose to do that you are telling your customers "I don't trust you" and I have a hard time understanding a business model that assumes people are going to want to steal the stuff you sell.