In this post to the CodeOfANinjs.com site, they walk you through password hashing, salting and storage using the PHPAss tool from OpenWall. The post itself is a bit older, but the content still provides a good example to teach the basics.

I think the main reason why we have to hash passwords is to prevent passwords from being stolen or compromised. You see, even if someone steal your database, they will never read your actual or cleartext password. I know that some PHP frameworks or CMS already provide this functionality, but I believe that it is important for us to know how its implementation can be made.

The tutorial shows you how to use the library and how to store the result in a simple "users" table in a MySQL database. The examples hash the password given from a simple form and use prepared statements (via PDO) to save it to the database. All PHP, HTML and CSS code you'll need - including the login form that checks the username/password - is included. There's also a few screenshots showing what the resulting forms and data should look like.

On Mike Dalisay's site there's a recent post showing how to use the Phpass tool to salt, hash and store passowrd data in your application.

I think the main reason why we have to hash passwords is to prevent passwords from being stolen or compromised. You see, even if someone steal your database, they will never read your actual or cleartext password. I know that some PHP frameworks or CMS already provide this functionality, but I believe that it is important for us to know how its implementation can be made.

His sample application stores the user data in a MySQL database and does the salting+hashing at the time of the request. It uses a hard-coded salt and a value of 8 for the hashing/stretching. Screenshots of each page in the example application are also included.

If you're going to be rolling your own user handling in your application, no doubt you've heard that something like bcrypt-ing your passwords is a good idea. Well, Anthony Ferrara has some suggestions for you and shows you seven ways you can "screw up" when trying ti implement it.

There are numerous articles on the web about how to properly use bcrypt in PHP. So this time, rather than write yet-another-how-to-use-bcrypt article, I'm going to focus on the mistakes that are commonly made when implementing bcrypt.

Here's the list of seven ways (each has its own description in the post):

• Using A Non-Random Salt
• Using An Incorrect Random Source for Salt Generation
• Using Too Weak Of A Cost Parameter
• Using The Wrong PHP Version
• Using The Wrong Prefix
• Not Checking For Errors
• Not Using A Library

He also includes two "bonus" things to consider: "Not Using A Timing Safe Comparison" and "Not Encoding The Salt Correctly".

In this new post to his blog Anthony Ferrara looks at a common idea that comes up when the discussion of encryption of passwords in PHP - the global salt (or "pepper").

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.

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.

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.

On Kavoir.com there's a new post that reminds you that hashing isn't enough anymore to protect your users and their passwords. They offer a suggestion or two of what you can do to help lock things down a bit more.

The common practice is to hash the user password and store the hash string of the password in the database. When the user tries to log in and supplies his password, it is used to generate a hash string to be compared to the one stored in the database. [...] This approach may be secure in the 70s of the last century, but barely any more.

Computing has evolved enough to where hashed can be matched, sometimes in less than two or three minutes. Their answer to the problem? Generate a random salt each time you create the hash with a constant being used as a base. A code snippet calling a user-defined function and the sha1 function are included.

On NETTUTS.com today there's a new post by Dustin Blake with a few simple tips and helpful techniques to locking down and protecting your website with some simple PHP scripts.

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.

PHPBuilder.com has a new article by Hillel Aftel about his method of choice for securing the data that you send over the GET string when moving things around on your site.

In this article I'm going to show you how you can use PHP to encode your data for transit. Most importantly, it will be done in a way that makes the data decodable, and therefore much more usable, by the receiving page.

His encryption method - sending everything in a single string and modifying the scheme each time - uses static pairs of values (of your choosing) to "encode" the outgoing string. It actually consists of three different files: the script itself, a single-use script that makes the third file, an include file to handle the conversion back from the encoded results.

PHPBuilder.com has a new article by Hillel Aftel about his method of choice for securing the data that you send over the GET string when moving things around on your site.

In this article I'm going to show you how you can use PHP to encode your data for transit. Most importantly, it will be done in a way that makes the data decodable, and therefore much more usable, by the receiving page.

His encryption method - sending everything in a single string and modifying the scheme each time - uses static pairs of values (of your choosing) to "encode" the outgoing string. It actually consists of three different files: the script itself, a single-use script that makes the third file, an include file to handle the conversion back from the encoded results.