PHP 7.2 – New for security


PHP 7.2 presents interesting news especially from the point of view of security, as well as some minor improvements and a new set of deprecated features.


Let’s start with the first important news dedicated to security concerning the function password_hash(), introduced with PHP 5.5 but which until now had only support PASSWORD_BCRYPT. PHP 7.2 introduces Argon2i as an alternative, it is a more modern algorithm for saving passwords, particularly fast and designed to resist attacks. In particular, compared to PASSWORD_BCRYPTcan be configured according to 3 parameters that determine the behavior:

A “cost” that defines the use of memory by the algorithm.
A “cost” that defines the execution time of the algorithm and the number of iterations.
A parallelism factor, which defines the number of parallel threads.

For example:

// Use of Argon2i with default cost factors
password_hash ('password', PASSWORD_ARGON2I);
// Use of Argon2i with custom cost factors
password_hash ('password', PASSWORD_ARGON2I, ['memory_cost' => 1 << 16, 'time_cost' => 5, 'threads' => 2]);

Another important difference between the two is that it PASSWORD_ARGON2Igenerates a hash of 96 characters against 60 of PASSWORD_BCRYPT.


The other big news for security is the libsodium cryptography library integrated in the core of PHP 7.2. Libsodium is easy to use for encryption, decryption, signatures and password hashing. Its goal is to provide all the basic operations necessary to build higher level cryptographic tools. In practice it provides:

  • Public-key cryptography using Diffie-Hellman and digital signatures on Curve25519.
  • Interoperability with other protocols using NaCl or libsodium (eg Noise).
  • The ability to clear memory buffers.
  • Encryption algorithms that are not vulnerable to side channels in the absence of dedicated hardware.
  • Authenticated cryptography.

Objects, types of data and values

The significant changes not only concern the security theme, with PHP 7.2 it will also be possible to pass an object as a parameter type to a function and specify an object as the returned data:

function myFunction (object $ myObject): object {
    $ obj = json_decode ('{}');
    return $ obj;

This means that in version 7.2 it objectbecomes a reserved word and can not be used for class names or similar, this should help to generate cleaner and more easily tested code.

Another important change concerns the possibility of ignoring the declaration of data types in the child classes

class PadreClass { 
    public function myTest (string $ parameter) {} 
class SonClass extends FatherClass { 
    public function myTest ($ parameter) {} 

Up to now PHP did not allow to change the parameter types in the child classes. It was therefore decided to omit the type declaration in the daughter class by eliminating the risk of rendering the code malfunctioning during the extension of the classes or the implementation of the interfaces. This will provide an easier upgrade path for libraries to start using scalar types, to replace manual checks within the methods, without requiring an upgrade for all sub-classes.

Furthermore, with PHP 7.2 it will be possible to count scalar values. In practice, calling count()on a scalar or on an object that does not implement the interface Countablereturns 1.

Other minor changes are

  • get_class()with parameter null.
  • Upload extensions by name by omitting the extension in the file php.ini
  • Use of deprecated unlisted strings.
  • Use the comma after the last element of an array.

Deprecated functions

Now let’s move on to what the new version makes deprecated, and therefore it will be good to put aside in our programming habits, at least for those who have not already done so. These features will probably be removed starting from version 8.0.

The magic function __autoload()has been replaced by spl_autoload_register()already version 5.1 and its use has been discouraged by the documentation. The main advantage of this spl_autoload_register()is the ability to provide chained autoloaders, thus facilitating the interoperability of the library. Remember that the two constructions are mutually exclusive and therefore can not live together.

If we enabled the function in php.initrack_errors , an error is generated that does not block the execution of the code nor is it intercepted by an error handler, it is then, or rather, captured by the variable $php_errormsg. From the PHP 7.2 version, it will be appropriate to use the function error_get_last()to recover the last error generated for this purpose.

Before closuresPHP 5.3 was introduced, it was possible to create functions using create_functions(), passing the name of the function and the body as a string. There is no point in using this function which, moreover, could introduce security issues.

Deprecated also the setting php.ini mbstring.func_overloadthat allowed the overwriting of some functions for the manipulation of strings with others defined in the extension mbstring; this made this setting incompatible with the rest of the code. The recommendation is to use the features directly mb_*.

Another deprecated function will be (unset)cast which returns a value null. This means that it (unset) expris simply an expression that always returns null. Besides being useless, this behavior is also confusing, since many programmers think it (unset) $variabilewill behave similarly to unset($a), what is not true.

It will then not be possible to use parse_str()without the second argument, as already recommended by the official documentation. On the other hand, direct access to the variable, in this case, is nothing but a survival of the old codes based on the logic of register_globals, the need to abandon this programming technique, even in this case, is linked to security reasons.

The function gmp_random()is deprecated in favor of gmp_random_bits()and gmp_random_range()which are not related to platform dependency like the first.

The function is also deprecated for the each()benefit of its analogous foreach(), better to say, similar in behavior but ten times faster.

The function assert()has two modes of operation: if something other than a string is passed, it tells us that the value is truthy. Instead, if a string is passed, it will be executed through eval()and the assert verifies that the result of it eval()is truthy. The explanation for this lies in the fact that before PHP 7 this was the only way to prevent the expression of affirmation from being evaluated. Starting with PHP 7, the zend.assertions in option php.inican be used to avoid evaluating assertion expressions.

Finally, the use is deprecated $errorcontextto refer to the error handlers, it is recommended to use debug_backtrace()or better still a debugger.


Please enter your comment!
Please enter your name here