Recently PHP 5.5 was released into beta, which puts us one step closer to another release of PHP. This week, I thought I would spend a little time explaining a new feature that will be implemented in 5.5 that will hopefully make dealing with passwords easier for developers to grasp and properly implement. I cannot tell you the number of apps, even ones written within the last year or so, that I open up only to find either an md5 hash, or worse, clear text password storage. I keep telling myself that eventually this will come to an end, and people will stop taking the easy way out. Maybe PHP 5.5 will have made it so easy that there is simply no further excuse not to implement solid password hashing.

He includes an example of the four new functions that will come with the hashing functionality: password_get_info, password_hash, password_needs_rehash and password_verify. He includes the parameters that should be included in each call and the details from the call to get the hash's info. If you're not going to be able to move up to PHP 5.5 when it's released, you might consider looking into this compatibility library to have a similar interface and functionality (for 5.3.7 or greater).

The other day, PHP 5.5 Alpha 1 was released to the public for the first round of testing the new features that are coming out. One of those new features is the Simplified Password Hashing API that I proposed (and was accepted). I have received a lot of feedback and criticism of the new API in the months since it's been committed. I figured now that Alpha 1 is out and people can play with it, I should respond to some of those items, and give a little bit more insight into why it was built the way it was...

He talks about some of his goals with the use of the functionality (simplicity, something "the 99%" can use) ans answers questions about:

• Why the functions aren't namespaced
• Why it's not just a class that can be included when needed
• The choice of not going with an OOP interface
• Why PBKDF2 and Crypt-SHA-512 aren't supported

...and several other questions, but you'll have to read the full post for the rest of those. You can find out a lot about the API for this functionality from its wiki page and, if you'd like to try it out (in an alpha state), you can download this version of PHP and compile it yourself.

Michael Maclean has written a very good article on what is wrong with this. His point essentially boils down to this: you have no way of knowing what you are actually installing on your system and if it's the software as intended by the original developers. Especially developers tend to do this more and more often, and in even more dangerous ways. Now, this is bad by itself of course, but this is not a simple app you run on occasion (if that was an excuse to begin with). Composer is the software that pretty much controls ALL your application dependencies. What would happen if this software would fetch its packages from packagists.org, or packagits.org?

He brings up a scenario where, say Packagist.org gets hacked and links to repositories are altered. If you're blindly installing via Composer, you'd have no idea that the code you're working with is potentially tainted. He notes that it boils down to trusting the source and how some simple hashing could help some of the problems. He also talks briefly about security issues that have been discussed (like "use SSL" or "don't run as root") to help prevent issues.

He suggests the implementation of the hash-based signing of the downloads to ensure that the software you're getting is what you're expecting. He mentions getting rid of auto-updates and the creation of signed packages/tarballs to help increase the security checking abilities of the installer.

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

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.

Even though it is true in effect that using a salt increases the overall security of your hashes BUT it's not only because your passwords are longer. There is a another (maybe even more important) factor that comes into play, namely the fact they are more secure against rainbow table attacks, but that depends on HOW you season your hashes. Season it incorrectly, and you gain nothing in security even though you think you did...

He gets into some of the details about hashing your information, how you can break that hash easily and how salting your information can help reduce that risk. He also points out things like rainbow tables and brute force that could still break these salted passwords.He recommends using a different method than a single salt - a different one for each user with a part stored in plain-text along with the user record.

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.

If you are using the Memcache functions through a PECL extension, you can set global runtime configuration options by specifying the values within your php.ini file. One of them is memcache.hash_strategy. This option sets the hashing mechanism used to select and specifies which hash strategy to use: Standard (default) or Consistent.

The recommendation is to set it to consistent to allow for the most flexibility on adding and removing servers from the caching server pool without the need for outside intervention.