Popular PHP projects will get a boost in cryptography
The efforts of the open source community, and especially Scott Arciszewski from Paragon Initiative Enterprises, have resulted into a welcome increase in security for PHP applications, changes that are coming to big projects like WordPress, Laravel, and Symfony.
Starting with WordPress 4.4, Laravel 5.2 and Symfony 2.8, these projects will feature built-in support for CSPRNG (Cryptographically Secure PseudoRandom Number Generator).
CSPRNG is a random number generation algorithm specifically designed for usage in cryptography. Security experts recommend CSPRNG algorithms for generating salt hashes, keys, nonces, and data padding. This is because CSPRNG generates true random numbers with a high entropy (randomness), meaning they are harder to crack in brute-force attacks.
It all started from the Facebook SDK
According to Mr. Arciszewski, the lack of a proper random number generation system in the open-sourced Facebook SDK encouraged him to contribute to this issue.
He first started by recommending a course of action for Facebook to improve the SDK, and then followed suit by taking two cryptographically safe functions added in PHP 7, and porting them to work on PHP 5.x.
Since most of today’s big open source projects still have to provide PHP 5.x support for legacy versions, once his work on the random_compat library was done, it allowed the maintainers of these projects to reconsider their stance on their own application’s support for “true” random number generation.
At this moment, WordPress, Laravel, and Symfony have already integrated the library in their codebase. The upcoming version of CodeIgniter (v4) will also support this functionality, but natively via PHP 7, which will be the project’s minimum required PHP version.
More technical details on this topic are available on Mr. Arciszewski blog post.
Joomla is lagging behind, has some cryptography issues to fix
This news is in contrast to what’s happening in Joomla, where Mr. Arciszewski also opened a few bug reports about the CMS’ poor cryptography practices, but the Joomla dev team has failed to act on them.
We have chatted with Mr. Arciszewski about JCrypt, Joomla’s built-in crypto library via email. His thoughts on the matter reveal that the CMS is lagging way behind when implementing safer cryptography practices.
“JCrypt is Joomla’s cryptography library and it handles a lot of things, from symmetric-key encryption to password authentication,” Mr. Mr. Arciszewski tells Softpedia.
“Their legacy password authentication (pre-bcrypt) is vulnerable to what has been branded as a ‘magic hash’ vulnerability by the PR campaigns of various security firms, but really what it boils down to is: if you have any two hashes that start with ‘0e’ and are followed by only numeric digits, regardless of what those numeric digits are, PHP will think they are equal to each other.”
“Also, their bcrypt doesn’t follow cryptography best practices; it compares hashes with === rather than a constant-time string comparison function,” also noted Mr. Arciszewski.
“NO CRYPTOGRAPHER HAS EVER LOOKED AT THEIR CODE BEFORE“
“The quick patch is to change == to hash_equals() (or, failing that, ===),” added Mr. Arciszewski, who then provided details about three other problems.
● “Their legacy cipher, JCryptCipherSimple, is extremely bad. If you pass it the message ‘AAAAAA…’ (the letter ‘A’ repeated 256 or more times), then take your ciphertext and ‘subtract’ (really XOR) the plaintext string (‘AAAAAA..’) from the ciphertext, you’ve just recovered the encryption key.”
● “None of their ciphers offered Authenticated Encryption. Reference.”
● “All of their Mcrypt-based ciphers are set to use CBC mode, which requires a unique, unpredictable (random) number for each message (called an Initialization Vector). Instead of a random per-message value, Joomla initializes one when the key is generated and uses that for each message. Given multiple ciphertexts, this mistake reduces the security of CBC mode back to ECB mode. (See the ECB penguin for more information.)”
So it was no surprise when Mr. Arciszewski concluded, “All of these mistakes lead me to believe that no cryptographer has ever looked at their code before. And that’s kind of scary, considering how popular Joomla is.”
UPDATE: Mr. Arciszewski also provided us with some good news after the article went live. The Joomla project added random_compat to Joomla 3.5.0 in this pull request, which secures their random number generator in 3.5.0. The other cryptography issues reported by Mr. Arciszewski are still unaddressed.