On the Paragon Initiative site they've posted a new article showing you how to safely store a password (in 2016) that discusses both the concepts around good password hashing and how to do it in several languages (including PHP).

The Problem: You want people to be able to create a unique user account, with a password, which they will use to access your application. How can you safely implement this feature?

He advises using libsodium for some of the best protection but points out that it's not widely supported yet. An alternative that is, however, is bcrypt (including PHP. He shows how to hash a password in:

• PHP
• Java
• C# (.NET)
• Ruby
• Python
• Node.js

Each of them is basically a one-line kind of change and doesn't require much effort on the developer's part to implement. He ends the post with a few FAQs around Argon2, PBKDF2 and why he's chosen to advise bcrypt over scrypt.

In a new post to her site Lorna Mitchell encourages you to upgrade to better passwords by using either the built-in password hashing (since PHP 5.5) or by using the userland implementation (that works for >=PHP 5.3.7).

The password features in PHP aren't exactly new, but I see lots of applications from "before" which aren't being migrated to better practices. I have some strategies for doing these migrations so I thought I'd share my main approach, plus a similar-but-different one I saw in the wild (OK it was in CakePHP, so not too wild!).

She offers a few steps to follow to upgrade your application to use the bcrypt solution instead of your current format:

• Update Login Code (change SQL to just fetch the password, not evaluate it)
• Hash existing passwords
• Update registration code (for new passwords to use the new method)
• Migrate users with old passwords hashes once they've verified their current login

She also mentions alternatives to these approaches including forcing the user to change their password on login.

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.

On PHPMaster.com there's a new tutorial that wants to help you keep your application and users a bit safer - a guide to password hashing for PHP applications.

You must always think about security. If passwords are stored in plain text, what happens if an attacker gains access to your database? He can easily read all of the users’ passwords. That’s why we use a technique called password hashing to prevent attackers from getting user passwords. In this article you’ll learn how to store the passwords securely in the database so that, even if your database falls into wrong hands, no damage will be done.

He starts off describing what password hashing is and why it's important (and better than it's plain-text alternative). He gives some examples of using some of the built-in hashing functions PHP has to offer to generate the hashes. He starts with md5/sha1 (note, these are not recommended) but moves into more effective options like sha256, salted hashing and even bcrypting passwords with crypt.

Be sure to check out the comments for other security concerns and links to suggested tools and resources.

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

Oscar Merida has a recent post to his blog about using the bcrypt functionality to more securely store the password information for your application's users.

The linkedin password breach highlighted once again the risks associated with storing user passwords. I hope you are not still storing passwords in the clear and are using a one-way salted hash before storing them. But, the algorithm you choose to use is also important. [...] The choice, at the moment, seems to come down to SHA512 versus Bcrypt encryption.

[...] I wanted to switch one of my personal apps to use bcrypt, which on php means using Blowfish encryption via the crypt() function. There's no shortage of classes and examples for using bcrypts to hash a string. But I didn't find anything that outlined how to setup a database table to store usernames and passwords, salt and store passwords, and then verify a login request.

He shows you how to set up a simple "users" table and the code for a "save_user" method that takes in the username/password and generates a salt and calls crypt on it with the Blowfish prefix on the string ($2a$). His login check function ("validate_user") then takes the user's input, does the same hashing and checks the result.