In a new post to his site, Rob Allen walks through the process of migrating an older site to use the password hashing functions in PHP instead of the previous custom implementation.

I’ve recently been updating a website that was written a long time ago that has not been touched in a meaningful way in many years. In addition to the actual work I was asked to do, I took the opportunity to update the password hashing routines.

This site is so old that the passwords are stored using MD5 hashes and that’s not really good enough today, so I included updating to bcrypt hashing with password_hash() and password_verify() in my statement of work.

I’ve done this process before, but don’t seem to have documented it, so thought I’d write it the steps I took in case it helps anyone else.

He starts off by taking all of the current passwords (not plain-text, already hashed) and migrating them all to their bcrypt-ed version. He then updates the login functionality to select the account by email and check the record's password value with the password_verify function. Finally, he updates the system to rehash the plain-text password value (received from the user and verified) with bcrypt and save that back to the database and updated the password hashing method on user account creation.

On the Tighten.co blog there's a tutorial posted from Jake Bathman for the Laravel users out there covering the APP_KEY value - what it is and how its used in your application.

A recent Laravel security update fixed an issue with how APP_KEY is used. For someone to exploit this issue, they'd need to have access to the production APP_KEY. The simplest fix for the exploit is to rotate (change) your APP_KEY. That led some of us at Tighten to ask the question: What does the app key do? What is involved in rotating it? What are best practices for managing these keys for our Laravel applications?

In this post, we'll talk about what APP_KEY does and doesn't do, some common misconceptions about its relationship to user password hashing, and the simple steps to changing your APP_KEY safely without losing access to your data.

Before diving in too deep, he reminds the reader about a security release Laravel recently made to correct an issue with APP_KEY handling (and the recommendation to rotate it). It then moves on to talk about what the setting is, how to generate a new one and its use in cookies. It also tries to dispel myths around:

• its use for password hashing (it's not)
• where it is used for encryption
• rotating the key
• multi-server use

It also makes a recommendation of the process to use for currently encrypted data that was created using the previous APP_KEY value and how to re-encrypt.

On the Delicious Brains site, there's a new tutorial posted sharing some of the methods included with PHP to improve protection of sensitive data using encryption.

I recently attended Laracon EU 2018 where Marcus Bointon gave a great talk on Crypto in PHP 7.2. I left the talk having a much greater appreciation for how vastly complicated cryptography is, but also for how PHP is making encryption more accessible thanks to the introduction of Sodium. Data encryption in PHP is something I’ve been working on as part of my work on SpinupWP so I thought it was time I shared a few insights. Buckle up, because this could be a bumpy ride!

The author then spends the remainder of the article covering the different types of encryption that are included with recent versions of the PHP language:

• one-way hashing (such as the bcrypt password hashing functionality)
• secret key encryption (symmetric)
• envelope encryption (such as Google's KMS)

Code examples are provided to show each of the types in action and links are also included for more information on several related topics/resources.

The PHP Roundtable podcast, hosted by Sammy Powers, has posted their latest episode covering Security: Encryption, Hashing and PHP. This time Sammy is joined by guests Scott Arciszewski, Chris Riley and Chris Cornutt.

We chat about security in the the PHP community, encryption & hashing in PHP and a new-hotness crypto library called libsodium.

You can catch this latest episode in a few different ways: either using the in-page audio or video player or you can watch it directly over on YouTube. If you enjoy the show, be sure to subscribe to their feed and follow them on Twitter for updates when new shows are being recorded and released.

In this recent post to his site Dries Vints shares two quick tips you can use to help speed up the execution of the tests for your Laravel application.

I've seen two different tips for speeding up your tests in Laravel in the past week and thought I'd share them with you. For me, they made a significant impact on the speed of my tests.

His two tips involve lowering the "cost" factor on the number of "rounds" the user password is hashed and the use of a pre-computed hash in your testing factories. These both help reduce the overhead needed, especially when working with tests that need to create the user every time. He includes code and reference links for more information about these two tips and applying them in your testing.

The Paragon Initiative has posted an article about cryptography, introducing some of the basic concepts and explaining why "you wouldn't base64 a password" to adequately protect it in your application.

If you feel that cryptography is a weird, complicated, and slightly intimidating subject for which your feelings might be best described as lukewarm (on a good day), we hope that by the time you finish reading this page, you will have a clear understanding of the terms and concepts people use when this topic comes up.

He starts with some of the basics around hashing (keyless cryptography) and the advantages/disadvantages of the method. He moves from there a step up and gets into secret key cryptography, using things like HMAC hashing to ensure message validity. The next move up is to secret key encryption, using some kind of "secret" as a part of the encryption process along with the right algorithm and mode for the encryption level desired. He also covers authenticated key encryption, public key encryption, shared secrets and digital signatures. He ends the post covering some of the common pitfalls of using cryptography in things like password storage, file verification and a reminder that encoding (like base64 encoding) and compression aren't encryption.

The IBM developerWorks site has a new tutorial posted talking about how PHP has been "renewed" in recent versions, more specifically in the password security department.

When PHP was first crafted in the mid-1990s, the term web application didn't even exist yet. Password protection, then, wasn't one of the features that the PHP creators devoted resources to. After all, you didn't need to worry about passwords when you used PHP just to put a site-visit counter or a date-modified stamp on your web page. But 20 years have passed, and now it's almost unthinkable to create a web application that doesn't involve password-protected user accounts. It's of the utmost importance that PHP programmers safeguard account passwords by using the latest and most secure methods.

The article goes on to talk about the importance of using secure hashing methods for password storage, the speed at which "cracking" programs can run and the use of "rainbow tables". It then gets into some of the older methods commonly used for password storage and protection and shows how to refactor them into the new password hashing functionality introduced in PHP 5.5.

Anthony Ferrara has a new post today looking at password hashing and a type of hashing that's beginning to get more attention in the PHP community - scrypt. However, he doesn't recommend it for production password storage and shares his reasoning why.

Scrypt was not designed for password storage. It was designed as a key derivation function for generating keys from weak material (namely passwords). The prime type of attack that scrypt is designed to defeat is ASIC based attackers. It is not designed to try to favor CPU over GPU (and thereby defeat GPU based attacks). It is this fact that we can leverage to gain an advantage when used as a password hashing mechanism.

He covers some of the basic design decisions that were made when scrypt was created. He also points out that none of the results of these decisions are strictly fatal, they just make it a bit weaker than something like bcrypt for password storage. He goes through the basic inputs scrypt requires and includes a quick snippet of code (not PHP, but easy to understand) showing its use. He talks about its "chain of 4 operations" and gets into what he sees as limitations: loop unrolling and the tune-able reduced memory usages. He finishes off the post mentioning that scrypt is still secure, but despite this he doesn't recommend it for password storage specifically.

The SitePoint PHP blog has a new post today about the challenges of password hashing and some of the common risks that can come with it. It's a continuation of a previous article about the actual techniques for hashing in PHP.

The fact that the output of a hash function cannot be reverted back to the input using an efficient algorithm does not mean that it cannot be cracked. Databases containing hashes of common words and short strings are usually within our reach with a simple google search. Also, common strings can be easily and quickly brute-forced or cracked with a dictionary attack.

He points to a video demonstrating a method for getting the password data and why just salted hashes aren't a secure method for storing this information. He mentions a "randomness issue" (and PHP's rand function). Instead, he shows an example with openssl_random_pseudo_bytes o pull a chunk of randomized data. He then talks some about password stretching using the PBKDF2 handling in PHP. Finally, he goes past the hashing and gets into encryption, mentioning "password tweaking" as an alternative to generating a single key for every user.

In this recent post to his site Jeremy Kendall shares some of his thoughts about password hashing and a new library he's written to help make it simpler - event with an existing password hashing method in place.

We all know to encrypt passwords for highest level of security. Unfortunately, too many do it [the wrong way]. While there was never any excuse for getting it that wrong, there’s now no excuse for getting it wrong at all. Developers, meet the new(-ish) PHP password hashing functions (and the userland implementation password-compat).

He shows how to use this password hashing correctly with the "default" hash and how to store that in the database. His Password Validator library aims to help make this even simpler and adds in other features like rehashing and upgrading of legacy passwords. The remainder of the post shows how to use the library for these functions and how to persist them in the tool's storage decorator and interface functionality.