RFC: Encryption API

[chillu]

Overview

We've had a discussion about TOTP secret encryption recently. While that's in a module that's not part of the core recipe, encryption comes up in other contexts as well. This is different from the "password encryption" (which is really password hashing) that's already in core.

Laravel provides an encryption API based on OpenSSL. According to their server requirements, they require PHP 7.1+ and openssl PHP extension to achieve this. We require PHP 5.6+ in our server requirements, and no encryption related PHP extensions. I've started a discussion about dropping PHP 5.x support from 4.x, but that looks unlikely. We could state "to use this API you'll need PHP extension X".

[chillu]

Creating a place for discussion, I'll leave it to @ScopeyNZ to drive this. Feel free to edit the issue with more details, notes, goals, etc

[aledbrown]

I don't know if this is of any use but I have used this PHP Encryption library in my non Silverstripe projects and it currently supports PHP 5 and PHP 7. I've both PHP versions on live projects at the moment. It's been reliable and easy to use. When I first looked into it I couldn't find any hosting that it would work with but in the last two years it's reliably worked on every host I've tried and has a nice little test file for testing environments are up to spec.

https://github.com/defuse/php-encryption

[sminnee]

Does this need to be a "part" of SilverStripe, or can we just make use of someone's third party library? What exactly would the value-add be in coupling a library with SilverStripe? Is it about streamlining the encryption / description of database-persisted content?

[maxime-rainville]

I second @sminnee. Encryption is a specialised task. I'd rather rely on a library built by a third-party who fully understands what they are doing.

Would encapsulate it into an injectable service. That would allow people to swap our preferred library for their own one if they wanted to.

[chillu]

@ScopeyNZ This is for you to drive :) I don't have a strong opinion on this yet, other than noting a very similar framework to us (Laravel) has decided to wrap encryption into their own API (using third party libraries for the hard bits of course).

[ScopeyNZ]

Yeah I've been meaning to find some time to get to this. I've also been working on a POC for the Hashing RFC. I've been a bit busy with the last week before Christmas but I really want to get discussion going in the new year and see if we can manage something for 4.4 - and the window is closing fast.

For a sneak peak my arguments will be along the lines of:

• We use encryption in 3 or 4 of our supported modules, but they all do their own thing
• This was a bit of an issue when it came to supporting 7.2 as they all individually required updates to remove usage of mcrypt (and we still have to update the RealMe module we support)
• Having a consolidated simple out of the box option that is easy to use and secure by default just encourages people to use it and be confident that it's done properly.
• Simpler for environments/ops teams to manage keys which are generally stored as some type of environment variable
• I'd suggest our implementation uses an environment variable (.env file) and perhaps we can add a task that will generate an addition to the .env file with a randomly generated key

To be clear I obviously don't want to actually implement encryption by hand or anything - that's completely nuts. Providing an API that can be used that will consume a library would be the recommended approach. See the discussion that was had here: https://github.com/elliot-sawyer/totp-authenticator/issues/1#issuecomment-435284679 (Although also note that I would recommend throwing an error if an encryption library is not available for usage)

[madmatt]

Reference: https://github.com/madmatt/silverstripe-encrypt-at-rest for SS3.

Module is used in production, provides the ability to encrypt specific database columns and decrypt on usage (so providing at-rest encryption). (the README really could use an update)

Having said that, this would be far better solved by either full-disk encryption or having the database engine itself provide the encryption (e.g. tick a box in AWS RDS) but that wasn't possible for the use-case we wrote the module for.

Under the hood, it too uses defuse/php-encryption to do the heavy lifting, and the module is awesome.

[chillu]

Note that we've agreed to end PHP 5.x support end of 2019, and we'll start creating 4.x releases relying on PHP 7.x in mid 2019: https://www.silverstripe.org/blog/our-plan-for-ending-php-5-6-support-in-silverstripe-4/

Simpler for environments/ops teams to manage keys which are generally stored as some type of environment variable

That's the part which I reckon SilverStripe needs to support: Auto-generation of environment-specific keys for encryption and salting purposes. Laravel calls this the Application Key, but works without setting one - presumably by using an unsafe shared default value. Without an application key, every module has to find a way to generate it's own one (hybridsessions, realme, TOTP). This is also in view of potentially making MFA a core feature (adding TOTP to a default recipe).