The other day I announced the release of my new password hashing library, PasswordLib. As I've come to expect, Reddit was full of interesting commentary on the topic. Some was good, some was bad and some surprised me. What surprised me was the insistence on a global salt (otherwise known as a "pepper"). So, I started thinking about it some more, and I figured I'd write a post on why I don't use peppers in my hashing algorithms (and why you may want to rethink it too).

He starts with an explanation of what a salt is (and isn't) to lead naturally into the idea of a "pepper", a single unique value that's used across an entire site/application for password encryption. He covers four flaws inherent with this method:

• There's no proof that using them increases your security.
• There are no publicly vetted hashing algorithms that accept a pepper as an argument.
• Using a block cipher instead of a pepper provides a stronger level of encryption and protection.
• The entire concept of a pepper is based around a flawed premise. [...] The flaw in that premise is that it's often not just your database that's leaked.

If you check out the master branch, you can use the new Encrypt strategy to encrypt your session data automatically. This means that you can read and write session data in cleartext and they will be encrypted on the fly before getting stored (in a cookie, for example).

You'll need the mcrypt extension installed for it to work correctly, but it makes storing the encrypted version of your data more or less automatic. Just set up your Session configuration to use it as a strategy and any time you call a "read" or "write" the hard work is handled for you. For those more interests in what's "under the hood" he goes on to talk about how the strategy works, what cipher it uses by default, how to change it and the default string to use in hashing.

Recently, an attacker hacked into my database and stole all the passwords and usernames stored there. Needless to say, I had to change everything and it cost me time and money. What made the crime easy for the attacker is that I never encrypted any of the passwords in the database. I've learned my lesson and now I'm passing along that wisdom with this article about encryption in PHP. Using some of the encryption techniques that PHP offers, you can safeguard your information in various ways.

He lays the foundation for the series by talking about three different kinds of encryption that can help you protect your data - one-way encryption, symmetric (using a key) and asymmetric (shared key locking).

In my situation, PayPal is only used to pay for orders - cart and order setup is done in our shop, so I do not want to have additional problems with users changing orders numbers, amount to be paid, etc. [...] Only PayPal knows how to decrypt it, because it uses public key encryption technology (you need to upload your certificate in PayPal account).

Some sample usage code is included as is a link to the class itself. His example takes a payment transaction including the item name, amount and currency type and sends it off to the PayPal servers in a connection protected by certificates.

It's been a while since I did some active ZF/PEAR component development. It's been one of those 6 month periods where time to commit was a rarity for a few reasons. So now that I'm back on the road, where to?

He sets his sights on the Zend_Crypt component and details some of the encryption methods it contains - HMAC, the Diffie-Hellman Key Agreement Protocol, a hashing wrapper and proposed support for a RSA public key cryptography. He mentions that a lot of this support is already in a beta package for PEAR.

What if you're using MD5 in your web application and want to switch over to another encryption method. It's actually not that hard and I plan to cover them in this multi-part tutorial (I know I planned on writing this months ago, but it's better late then never). In this first part I plan on going over updating the database structure and a 'pseudo-code' of what will need to be done.

As mentioned, he gives the outline (pseudo-code) of how the process will work - basically, creating an SHA1 hash of the MD5 and the username in a "newpassword" column added to your database.

In this increasingly virtual online world, you have to be careful to protect your data. Learn the basics of encoding and encrypting important bits of information, such as passwords, credit card numbers, and even entire messages. Get an overview of what it means to encrypt and decrypt information, as well as some practical examples involving passwords and other data, using PHP's built-in functionality.

They start off where any good encryption article should - with a primer in cyrptography. You can't understand the advanced without a good grasp on the basic. Using this knowledge, they start to work up their form, a simple username and password validation system.

They provide all of the code you'll need to build the form, and even intorduce you to the crypt() function. A bad use of this functionality is also illustrated. Of course, encryption is only half the fun, so they also include an example of decrypting the same information.

Before he even gets into the code, he explains how the encryption portion of it works, complete with a chart representing the encryption process. Following this,the two functions are explained, each with their own code to make cut and paste simple.

You run a website that is simple enough it doesn't require a database. But your site features certain pages to which you'd like to limit access. Most of the time, that implies using a database to store passwords and usernames. There is an easier way, however. It's less secure, but it involves a lot less coding.

They step you through the process - creating the form, making the PHP page for it to submit to, checking the password (including a bit on encryption), and validating the user's entry against it.]]> Mon, 27 Feb 2006 09:16:15 -0600 http://www.phpdeveloper.org/news/4584 http://www.phpdeveloper.org/news/4584 this new post on the Sjon.Blog today, he mentions some of the frustrations he's had already with exectly this.

Zend almost convinced me that their Safeguard Suite really secured your PHP scripts. Ofcourse I know that scripts need to be interpreted and executed and are therefore never 100% safe; but I expected some form of obfuscation and rewriting to prevent this. This doesn't seem to be the case though. I have had a look at PHP Obfuscator/Obscurer, but a good illustration of the quality of that script can be illustrated with a simple, readable example.

Also, obfuscating React took me almost an hour; which isn't that strange when you have had a look at the sourcecode.

As far as I've heard/seen so far, there's not really a good solution to this dilema. Sure, some are better than others, but there's still a hole there that is just waiting to be filled with an application anyone can use...]]> Fri, 30 Dec 2005 07:15:19 -0600