Six months ago, I wrote a blog post titled Let's Make 2017 the Year of Simply Secure PHP Cryptography, which at the time seemed ambitious and possibly erring on the side of idealism. The goals were as follows:

1. Get the sodium extension into the PHP core in version 7.2.
2. Write a pure-PHP polyfill that supports all the way back to PHP 5.

I'm happy to report that, halfway through 2017, both efforts have been successful.

PHP is Getting ext/sodium in 7.2

The PHP Internals team has a reputation for being somewhat change-adverse because too many breaking changes without a good reason will change the language in weird ways and likely make everyone unhappy. So you can imagine my surprise when the libsodium RFC I proposed passed unanimously, 37-0.

(Of course, in total fairness, there's a similar level of consensus among security and cryptography experts about recommending libsodium. Ask your cryptographer about it.)

The pull request was merged yesterday, thereby cementing Sodium's status as a core extension to the next version of the PHP programming language. This means several huge, practical wins for developers:

1. Simple and secure public key cryptography is baked in, using Diffie-Hellman and digital signatures over Curve25519.
   • The old standby, OpenSSL, had public key cryptography interfaces that were vulnerable to a 1998 vulnerability by default, that not even Zend used correctly the first time around.
2. Interoperability with other protocols that use NaCl or libsodium. (e.g. Noise)
3. The ability to wipe memory buffers for the first time since PHP's inception.
4. Encryption algorithms that are not vulnerable to side-channels in the absence of special hardware (PDF).
5. Authenticated encryption, almost exclusively.

I wrote a libsodium quick reference guide last month to demonstrate how the new PHP extension should be used to solve common problems. I gave a talk at B-Sides Orlando about solving weird problems securely.

PHP 7.2 is scheduled to be released on 2017-11-30 (November 30, 2017).

Sodium_compat: Modern Cryptography for Legacy Environments

The other part of the equation was to build a pure-PHP implementation of the cryptography offers. We tagged the first version 1.x release of paragonie/sodium_compat last month, and are currently focusing on making sure we're forward compatible with PHP 7.2 and supporting 32-bit operating systems (which was missed during our beta testing because most of the world has moved onto 64-bit hardware).

We've previously covered the design decision we made in sodium_compat in a post titled, Cryptographically Secure PHP Development, which we hope serves as a starting point to anyone implementing cryptography algorithms in PHP.

Sodium_compat will be coming in a future release of Joomla!, a CMS that powers over 3% of the websites on the Internet.

Where Do We Go From Here?

We still have half a year left, and our ambitions for the year have already been realized. We don't rest on our laurels, however, and we've already begun on even more ambitious projects to make the Internet more secure.

• We designed Sapient (Secure API Engineering Toolkit), which uses the Sodium cryptography library to authenticate and/or encrypt HTTP message bodies.
• We used Sapient to build Chronicle, a self-hostable microservice that obviates the need for most companies to invest in blockchain technology.
• We've proposed the start of a plan to make Composer, the package manager used by the PHP community, use Chronicle and libsodium to offer secure code delivery by streaming software release metadata into a dedicated Chronicle instance.

We still have our work cut out for us. I'm giving a talk at the Crypto and Privacy Village at DEFCON 25 about secure automatic updates, which will cover a lot of the challenges we anticipate and how we plan to engineer a solution that's easy to use and analyze but very hard to attack.

How You Can Help Make the Internet More Secure

Whether security experts like it or not, PHP powers about 5 out of every 6 websites. Making the PHP ecosystem even a little more secure will make the Internet as a whole far more resilient to attack.

1. Clean up old tutorials, forum posts, and blogs.

One of the hardest challenges to solve for the PHP ecosystem is the high ratio of insecure to secure tutorials and example code on the Internet.

Some of the highest ranking search results for domain-specific problems will make your application vulnerable to trivial (OWASP Top 10) attacks if you follow their example. Additionally, it's difficult to unlearn bad habits once you've committed them to muscle memory.

When an instance of bad security advice ranks highly in search engines, it is potentially very harmful. When this bad advice is on a Stack Exchange website, we can correct it by providing a dissenting answer and adding a security warning to the high-ranking and/or accepted answer.

However, the Internet doesn't live on Stack Exchange. If you have a blog or forum post that ranks highly and contains bad security advice, take the opportunity to write an up-to-date article and link to that instead. (Also, it might be a good idea to remove any hyperlinks to websites like W3schools that peddle bad advice for years while ignoring feedback from security experts.)

To clean up the PHP ecosystem, we're going to need to enlist the help of the PHP community.

2. Share our blog posts with other developers.

We cover a lot of security-related topics, ranging from the trivial stuff like SQL injection and cross-site scripting, to the more advanced topics like adaptive chosen-ciphertext attacks.

We don't serve advertisements on our website, nor do we ever intend to do so. Our blog posts are also released under a Creative Commons license. We publish this information because we want people to learn from it. Whether we have 10 readers or 10,000, our revenue remains unchanged.

If you need a place to start, our Quick Answers page is probably the best place. If you've read everything we've published and want to learn about topics we haven't covered, we have an application security reading list on Github.

3. Contribute to Open Source Software

Chances are, most PHP developers might not consider themselves to be security experts, but our regular blog readers may be pleasantly surprised with themselves the next time they read through an open source library looking for the sorts of vulnerabilities we've discussed at length.

Open source software is near-ubiquitous and a lot of it should be considered critical infrastructure. For example, you will be hard-pressed to find a programming language that doesn't use OpenSSL in some way. Whether you contribute time or money, you'll be moving the needle towards a future that is secure-by-default, and difficult for crooks to thrive.

4. Hire Security Experts

Don't wait until you've been hit with ransomware or your customer's credit cards are stolen to reach out to security companies or individual consultants for help. When it comes to cybersecurity, a milligram of prevention is worth several tons of cure.

If you don't know any companies or consultants that could help your company stay secure, you may want to consider hiring Paragon Initiative Enterprises. (Disclaimer: That's us.)