Anthony Ferrara has a new post today looking at a potential security issue in PHP applications when using bcrypt with encryption and other hashing functions. His findings have to do with some research he did on long passwords and denial of service attacks they might lead to.

The other day, I was directed at an interesting question on StackOverflow asking if password_verify() was safe against DoS attacks using extremely long passwords. Many hashing algorithms depend on the amount of data fed into them, which affects their runtime. This can lead to a DoS attack where an attacker can provide an exceedingly long password and tie up computer resources. It's a really good question to ask of Bcrypt (and password_hash). As you may know, Bcrypt is limited to 72 character passwords. So on the surface it looks like it shouldn't be vulnerable. But I chose to dig in further to be sure. What I found surprised me.

To find out exactly how things are processed he gets down into the C code behind the PHP functionality in the crypt function. He discovers something interesting about the way it determines the length of the input password. It loops over the key, taking one byte at a time but resetting when it comes across a null byte. While this method is safe in itself, he points out the real issue - using pre-hashing before the bcrypt password checking to, possibly, allow for longer passwords.

The problem is that this method could lead to those null bytes and cause issues with the password checking, especially if opting for the use of raw data. He includes a simple script to illustrate this problem, finding a few collisions for his made up key and "random looking" password. Thankfully, he includes a method for checking to ensure the hash doesn't contain a null byte. He points out that not all hashing combinations are at risk and suggests a few alternatives that can keep your application 100% safe.

The underlying problem is that combining cryptographic operators that weren't designed to be combined can be disastrous. Is it possible to do so safely? Yes. Is it a good idea to do it? No. This particular case is just one example where combining operations can be exceedingly dangerous.

In this new post Joseph Scott takes a look at hashing in PHP, specifically around md5 hashes, and a better alternative (that's also more secure.

The majority of the Coding Horror: Speed Hashing post talks about speed based on MD5. [...] If you are still using MD5 to hash passwords (or worse, aren’t hashing passwords at all) then please stop and go use bcrypt. For those using PHP phpass is a great option.

He talks about the crypt method, how its encryption method and "cost" value effects the speed and how difficult it would be to generate all possible hashes for a password (hint: crypt with a cost of 13 is worlds better than md5).

On PHP.net they've posted the official announcement about the release of PHP 5.3.8, an release following 5.3.7 to fix some issues with the crypt functionality.

The PHP development team would like to announce the immediate availability of PHP 5.3.8. This release fixes two issues introduced in the PHP 5.3.7 release: Fixed bug #55439 (crypt() returns only the salt for MD5), reverted a change in timeout handling restoring PHP 5.3.6 behavior, which caused mysqlnd SSL connections to hang (Bug #55283). All PHP users should note that the PHP 5.2 series is NOT supported anymore. All users are strongly encouraged to upgrade to PHP 5.3.8.

As always you can download this latest release from the downloads page (Windows binaries here). This upgrade is highly recommended if you were running 5.3.7.

In a quick note from the PHP.net site, they have a warning for those running PHP 5.3.7 (the most recent release) - there's a bug that's serious enough (with crypt) to where upgrades should probably wait until 5.3.8.

Due to unfortunate issues with 5.3.7 (see bug#55439) users should wait with upgrading until 5.3.8 will be released (expected in few days).

The issue causes the crypt() function to only return the (MD5-only) salt it was given instead of the correctly hashed string. If you need to replace this immediately, you can pull the latest from the snaps site (or binaries for Windows). Keep an eye out for PHP 5.3.8 in the near future.

Shay Ben Moshe has a new post to his blog looking at a method he's come up with for hashing passwords the proper way and saving them to a database for future checking. His encryption methods of choice crypt and a random salt generator.

The easy and common solution for this particular problem is to use an one-way hash function, such as md5 and sha1, which takes the password and encrypts it. Unfortunately, this method is not as strong as you may think. [...] We can protect our password from rainbow tables and similar attacks by using salts.

He talks about storing passwords in a database (never as plain text!) and what rainbow tables are and how they can make it simple for a user to break a poorly hashed value. He shows how to use the crypt function together with the sha512 hashing tool to make a salt.

On NetTuts.com today there's a new tutorial from Burak Guzel about keeping your passwords (and web applications) safer by using hashing with passwords and understanding which of the PHP functions is right for you.

From time to time, servers and databases are stolen or compromised. With this in mind, it is important to ensure that some crucial user data, such as passwords, can not be recovered. Today, we are going to learn the basics behind hashing and what it takes to protect passwords in your web applications.

The article is a simple introduction to the topic and doesn't claim that it will protect you 100% but it's good to get the ball rolling. They talk about md5 hashing and the crypt method. He also outlines a few problems that surround hashing - hash collisions, attackers using "rainbow tables" and how quickly the average computer can run through hashes (an average 8 character password could be broken in around 60 hours). For each, he includes a few things you can do in your code to help prevent them from happening.

The Zend Developer Zone has a new tutorial posted today showing how to use the open source encryption tool GnuPG from inside PHP.

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.

Padraic Brady has an announcement posted to his blog today - his OpenID PEAR has officially been proposed to the PEAR group for consideration.

Yes, my OpenID 2.0 PHP5 Consumer has finally been proposed to PEAR. This brings the OpenID fanaticism on PEAR to four packages: OpenID_Consumer, Services_Yadis, Crypt_HMAC2, Crypt_DiffieHellman.

He'll be working to get the code "further up to par" including Nonce validation, more consistent error reporting and other operation modes (like check_immediate). He's also included a screencast in the post for those not familiar with OpenID to get their first dose.

Padraic Brady has an announcement posted to his blog today - his OpenID PEAR has officially been proposed to the PEAR group for consideration.

Yes, my OpenID 2.0 PHP5 Consumer has finally been proposed to PEAR. This brings the OpenID fanaticism on PEAR to four packages: OpenID_Consumer, Services_Yadis, Crypt_HMAC2, Crypt_DiffieHellman.

He'll be working to get the code "further up to par" including Nonce validation, more consistent error reporting and other operation modes (like check_immediate). He's also included a screencast in the post for those not familiar with OpenID to get their first dose.

Stefan Esser points out the latest release of his PHP security enhancement patch, Suhosin 0.9.20, and some of the features it adds, a major one specifically.

The most important addition is that a mutex is placed around the call to the system's crypt() function to ensure thread safety. This mutex is necessary to close a bunch of possible attacks on the libc crypt() function on multi threaded systems.

He goes on to explain why it's so important - correcting a possible race condition between competing threads looking to use the crypt() function at the same time. They use the same shared memory space and, because of this, can return possible invalid data. The patch changes this behavior and replaces it with a blowfish implementation to make things more thread-safe.