On his site, Daniel Gomes has written up an article that makes a suggestion about working with objects in PHP. In it, he suggests performing a deep copy of them rather than just cloning them into a new variable.

As you know, PHP has a well-known clone keyword that shallow copy all of the object’s properties. So under the hood what it does is to create a new Object with the exact same values of that object properties – unless you change its behavior by implementing the __clone() function in your class.

This behavior seems what we expected. However, it might give “weird” results if the object that you are cloning contains properties that are objects.

He gives an example of this "weird" result when cloning an object that has a model property containing an instance of a CarModel class. He shows the hash IDs for the objects (different), the model properties (the same) and how changing one changes the other. This could lead to some unintended consequences so he suggests a deep copy instead using a handy library. He finishes the post with example code using this library and the resulting hashes/value differences.

Loïc Faugeron has a post on his site covering the concept of short identifiers and covering some of the common types along with some of the downsides of the use of each.

Sometimes resources can be identified by one of their attributes (a name, title, slug) and sometimes they can't (no name, or confidential name). In the later case, an ID needs to be artificially crafted.

Two of the popular strategies is to use either an auto incremental one or a universally unique one, however when it comes to share them publicly, both strategies present some drawbacks

He lists several different types including:

• Auto Incremental IDs
• Short IDs
• Hashes
• Alphabetical representation

In the end, the method he recommends is hashing the ID value and using the first few characters (much the way you can refer to commit hashes in the Git version control tool).

On the Zend Framework blog today there's a new post from Enrico Zimuel showing you how you can use Argon2 password hashing in PHP applications (coming natively in PHP 7.2).

PHP 7.2 will be released later this year (2017). This version contains some interesting additions, including two new security features: support of the libsodium library.

With these new features, PHP is the first programming language to adopt modern cryptography in its standard library.

In this article, we demonstrate the usage of the Argon2 password hash algorithm.

He then walks you through the installation of the pre-release version of PHP 7.2 and the argon2 library to get the environment up and running. He briefly talks about what the Argon2 hashing algorithm is and how to use it directly in PHP via the password_hash function. He also mentions the password_get_info function and shows what the result of inspection on an Argon2 application contains.

On the Tighten.co blog Matt Stauffer shows how to make a password-less authentication system similar to what the popular site Medium uses centered around emails sent to the account for the user.

Recently I was working on a project where one of our major pain points was users' passwords. Users were added to the application by administrators, so they didn't have passwords when they were first added, and forcing them to set and remember passwords was a big hitch on the project's usability.

So, we decided to try out a Medium/Slack-inspired password-less login. If you've never had the chance to work with this, the login system works like this: enter your email address on the login page, get emailed a login link, click the link, and now you're logged in. Access to your email address proves your identity without the need for a password.

He walks you through the process of disabling the current password-based flow by creating and modifying the default "make:auth" results. When the user comes to the site, they're asked to log in via sending an email. This email contains a unique token attached to a link that matches one on the server side related to the user. He shows how to build out this relation table, the matching model and the endpoint used to verify the hash once the user clicks on the link.

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.

A recent issue has come (back) to light in the security community around how PHP compares hashes. In this post to the Security Affairs site they talk about the problem of hash comparison and how to prevent the issue in your own PHP code.

Because of a security flaw according to which PHP tackles ‘hashed’ strings in specific situation attackers are given the opportunity to try and breach passwords, authentication systems and other functions being run on PHP hash comparisons, WhiteHat security researcher says. VP of WhiteHat, Robert Hansen, declared that any website is vulnerable to the flaw – the only thing is, two specific kinds of PHP hashes the vulnerable site uses for comparing ‘hashes’ in PHP language.

The problem comes with how PHP handles its typing behind the scenes mostly. When a string starts with "0e.." PHP interprets it as scientific notation and sees it as a value equal to zero. As a result, two strings, even if they don't match, that start with "0e..." will evaluate as equal. Fortunately, the answer is relatively simple (though could be time consuming to fix): change == (double equals) to === (triple equals). This prevents PHP from trying to do the type juggling and compare them on the types they are when presented (string to string in the case of hashes).

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.

Evert Pot has shared some of his thoughts about why he has a problem with password_hash (and friends). His thoughts are initially about this particular feature but they're actually wider than that.

The initial introduction and rfc for these functions made me uneasy, and I felt like a lone voice against many in that I thought something bad was happening. I felt that they should not be added to the PHP engine. I think that we should not extend the PHP engine, when it's possible to write the same API in userland, or there are significant benefits to do it in PHP, such as performance. Since the heavy lifting of the password functions is done by underlying libraries that are already exposed to userland-PHP, it didn't make sense to me to expose it as well in the core.

He includes a list of things he sees as drawbacks for new C-based functionality in PHP including the fact that it extends the "PHP specification" and forces other projects to implement it (like HHVM). He does include a few positives, though, such as the increased visibility and legitimacy, but still thinks they don't outweigh the negatives.

In the latest post to the SitePoint PHP blog Vova Feldman shows you how to create an integer from a hash string that's both 64 bit and unique each time it's generated.

PHP provides the popular md5() hash function out of the box, which returns 32 a hex character string. It’s a great way to generate a fingerprint for any arbitrary length string. But what if you need to generate an integer fingerprint out of a URL?

He describes the real-world situation he was facing - a rating widget that needed a randomized integer based on the page using it - and the two "sub-challenges" that make it up: url canonization and the string to unique 64 bit problem. He tackles each problem and shares code snippets showing the process and how it can be put to use. He also includes some interesting metrics at the end of the post showing the level of hash collisions (hint, it's a very low number).