The Paragon Initiative has a recent post to their blog that's kicking off a new series of posts called "Slice of PIE". In these posts they hope to provide answers in a Q&A style, answering questions commonly asked of them via Twitter or other means.

Astute readers have noticed that our blog posts have decreased in frequency this year. We put a heavy emphasis on quality, not so much on quantity.

At the same time, we field a lot of questions on social media, where our answers (and, sometimes, the questions themselves) are difficult to locate, especially when people close or lock their accounts.

With both of these thoughts in mind, I asked my Twitter followers if they'd be interested in a Q&A-style blog series. I expected maybe a 55:45 split on yes/no responses, but the final tally was overwhelmingly "Yes".

So with that in mind, I'd like to introduce the pilot for our new series, Slice of PIE.

In this inaugural edition they start by sharing how readers can get their questions answered and what kinds of questions will be answered. To kick things off they answer a question about the use of asymmetric encryption and comparing it to hybrid encryption.

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.

On the Websec.io site there's a new tutorial posted showing a potential method for keeping secrets safe in PHP-based applications.

One of the most difficult things in any kind of application (not just web applications) is how to protect "secret" values. These values might be API keys, database passwords or even special bypass codes. Ideally, you're not having to define these directly in the application and can have them loaded from another source.

While a lot of the issues around protecting secrets can be removed by better secret handling, it seems like there's still always a need for some kind of secret value to exist in an application. Using this sort of pattern is, obviously, recommended against. The Common Weakness Enumeration database even has an entry specifically about it: CWE-798. Hard-coding credentials, especially plain-text ones, can be a huge risk if an attacker were able to somehow access the code and read them directly.

The post then goes on to talk about specific issues with secrets/credentials handling in PHP and some of the common approaches (mostly using a .env file). It covers some of the basics of using the phpdotenv package before getting into the encryption of the secrets it contains. It makes the recommendation of using an "Apache pull" method to pull in the encryption key when Apache starts, putting it into an environment variable and using the psecio/secure_dotenv library to work with the encrypted values.

In the latest episode of the Three Devs and a Maybe podcast, hosted by Michael Budd, Fraser Hart, Lewis Cains and Edd Mann, they welcome back a guest for another round of security discussions: Scott Arciszewski around symmetric and asymmetric encryption.

In this weeks episode we are lucky to be joined again by Scott Arciszewski. We start off the show by discussing the difference between Symmetric and Asymmetric Encryption, what Authenticated Encryption is and how secret-keys are exchanged using Diffie-Hellman. From here, we move on to highlight how Elliptic-curve cryptography works, what DNSCrypt is and why prime numbers are so important in cryptography. Finally, we touch upon multi-factor authentication, how one time passwords work, SMS vulnerabilities and how to manage password recovery.

There's a wide range of security and cryptography related topics mentioned and linked in the post. You can listen to this latest show either using the in-page audio player or by downloading the mp3 directly. If you enjoy the episode, be sure to subscribe to their feed and follow them on Twitter to get updates when new shows are released.

On the php[architect] site they've posted an article that appeared in their December 2017 issue, an article that introduces Libsodium (by Eric Mann), a new addition to PHP's "security toolbelt" for encryption.

By the time you read this, the PHP community should have introduced the world to the newest version of our favorite language. This latest version adds better support for type annotations, allows trailing commas in lists (just like JavaScript and other dynamic languages) and introduced several security improvements. The most notable security addition, however, is the introduction of the Sodium cryptographic library as a core extension.

In the article he covers the basics of the Sodium library (that libsodium is built on top of) and what makes it different from other encryption methods. He also talks about what's been done to support it on pre-PHP 7.2 versions including the sodium_compat polyfill library and the PECL extension for PHP 7.0+. Example code is included showing how to use this new functionality via native functions once support for it has been compiled in.

On the AWS PHP SDK blog there's a new tutorial posted showing you how to use the multipart uploader with client-side encryption via the library.

The AWS SDK for PHP released support for multipart uploads with client-side encryption in version 3.48.0 via the S3EncryptionMultipartUploader. With client-side encryption, data is encrypted and decrypted directly in your environment. This means that this data is encrypted before it’s transferred to Amazon S3, and you don’t rely on an external service to handle encryption for you.

Multipart uploads are designed to improve the upload experience for larger objects. With it, you can upload objects via parts that can be uploaded independently, in any order, and in parallel. You can use a multipart upload for objects from 5 MB to 5 TB in size.

The article then starts you off with the requirements you'll need to follow along and some sample code to get the client up and running. The code then shows how to perform the file upload, making use of a file stream (via fopen) to pull in the contents of the file. The tutorial finishes by describing some of the other fields that can be used with the client and links to other SDKs that support this same functionality in other languages.

On the SitePoint PHP blog today they've reposted an article that was originally posted on the ParagonIE blog about searching encrypted information in database fields from author Scott Arciszewski.

This question shows up from time to time in open source encryption libraries’ bug trackers. This was one of the “weird problems” covered in my talk at B-Sides Orlando (titled Building Defensible Solutions to Weird Problems), and we’ve previously dedicated a small section to it in one of our white papers.

You know how to search database fields, but the question is, How do we securely encrypt database fields but still use these fields in search queries?

Our secure solution is rather straightforward, but the path between most teams asking that question and discovering our straightforward solution is fraught with peril: bad designs, academic research projects, misleading marketing, and poor threat modeling.

They start off with some of the examples of bad ways to perform the searching of encrypted information, mostly around either using poor encryption levels or custom created encryption solutions. With those out of the way, the tutorial moves on to their recommended method: using an authenticated encryption scheme (libsodium) and blind indexing. The key to the method is to use a secondary column for the actual searching process, encrypting the value provided and running the search against that, not the encrypted value itself. The article then covers two questions that need to be asked before putting this method to use. The article ends with a method to enhance the previous searching to allow for "fuzzier" searching through the generation of some additional index values in a joined table.

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.

With the recent release of the latest version of the zend-crypt package, the Zend Framework has announced that it's possible to use it to create end-to-end encryption in your applications (Zend Framework based or not).

Recently, we released zend-crypt 3.1.0, the cryptographic component from Zend Framework. This last version includes a hybrid cryptosystem, a feature that can be used to implement end-to-end encryption schema in PHP.

A hybrid cryptosystem is a cryptographic mechanism that uses symmetric encryption (e.g. AES) to encrypt a message, and public-key cryptography (e.g. RSA) to protect the encryption key. This methodology guarantee two advantages: the speed of a symmetric algorithm and the security of public-key cryptography.

He starts with a brief overview of how the system works and the flow of the request/response messaging. With this base in place, he gets into the code required to perform the encryption, first generating the keys needed for the encryption (and why he chose the mode/cypher he did for each). Then, using these keys, he shows how to use zend-crypt and its "Hybrid" handling to encrypt and decrypt a simple message. He also shows how to encrypt the contents of a file using a password.