Pre-Draft for Opaque Objects

[Grégory Planchat]

Hello,

I would like to make a proposal for Opaque and Ciphered objects. Both are related to securing sensitive data such as passwords and keys while you need to manipulate them in your code.

The need for Opaque Objects comes from securing sensitive data while they are in clear in your system. Instead of manipulating passwords as strings, we manipulate them through an Opaque object that can't leak its contents through var_dump/var_export, trace dumping or serialization. The only way of leaking the protected data would be by calling a `disclose()` method.

As the serialization feature would be blocked by Opaque Objects alone, the Ciphered Objects and encrypt/decrypt functionalities are added to keep a safe way of serialization of those sensitive data.

I have a specification I use as an ADR in some of my projects currently in production that I would be happy to use as a PSR draft.

Would such proposal interest people from the FIG to transform it to a PSR?

Grégory

[Vincent de Lau]

On Tuesday, June 4, 2024 at 4:16:10 PM UTC+2 Grégory Planchat wrote:

Hello,

Hi Grégory,

 

I would like to make a proposal for Opaque and Ciphered objects. Both are related to securing sensitive data such as passwords and keys while you need to manipulate them in your code.

The need for Opaque Objects comes from securing sensitive data while they are in clear in your system. Instead of manipulating passwords as strings, we manipulate them through an Opaque object that can't leak its contents through var_dump/var_export, trace dumping or serialization. The only way of leaking the protected data would be by calling a `disclose()` method.

Are you aware of SensitiveParameterValue [1][2]? This class was introduced as part of the  'Redacting parameters in back traces' RFC [3]. Is this essentially what Opaque should be?

 

As the serialization feature would be blocked by Opaque Objects alone, the Ciphered Objects and encrypt/decrypt functionalities are added to keep a safe way of serialization of those sensitive data.

I have a specification I use as an ADR in some of my projects currently in production that I would be happy to use as a PSR draft.

Would such proposal interest people from the FIG to transform it to a PSR?

 

As far as this being PSR worthy, I wonder how this problem space has impact on interoperability. Maybe in the broader context of configuration and service locator this might be an enhancement. What use cases do you see that would require this to be a PSR and not just a library?

Kind regards,

Vincent

[1]: https://www.php.net/manual/en/class.sensitiveparametervalue.php

[2]: https://3v4l.org/Vso8g

[3]: https://wiki.php.net/rfc/redact_parameters_in_back_traces

[Grégory Planchat]

Hello Vincent,

> Are you aware of SensitiveParameterValue [1][2]? This class was introduced as part of the  'Redacting parameters in back traces' RFC [3]. Is this essentially what Opaque should be?

Yes, I am aware of SensitiveParameterValue. The ADR I wrote requires to use this attribute in the constructor arguments of the Opaque Object.

However, it is one part of the solution of the Opaque Objects. It does not solve the risks related to serialization and var_dump/var_export.

> As far as this being PSR worthy, I wonder how this problem space has impact on interoperability. Maybe in the broader context of configuration and service locator this might be an enhancement. What use cases do you see that would require this to be a PSR and not just a library?

Managing passwords is a common need for domains like dependency injection, API clients, database access or user authentication.

It can be extended to everything that also requires managing keys/tokens or sensible data in general, like logs management. In this case you would be required to identify the sensible data and hide them if present.

Today, if you wish to secure your sensible data through Opaque Objects, it would be possible to do it in the code you own.

However anytime you need to pass this value to a 3rd party code you would be required to extract (disclose) the data from the Opaque Object and depend on the vendor's ability to keep secured the sensible data in all cases.

For example, it can be possible to leak an API password in the logs if your 3rd party library throws an unhandled exception.

Creating a PSR would bring an interoperable minimum security level for all libraries wishing to implement such security.

Kind regards,

Grégory

[Larry Garfield]

(If someone bottom-replies, please continue bottom-replying. Don't top-reply.)

I'm a bit unclear what such a spec would even look like. Do you have any rough examples of what you're talking about, even if not definitive yet?

--Larry Garfield

[Grégory Planchat]

Hello Larry,

> I'm a bit unclear what such a spec would even look like. Do you have any rough examples of what you're talking about, even if not definitive yet?

I've copy/pasted in a gist the ADR I wrote and use in my application: https://gist.github.com/gplanchat/9939898a1ca852fffcd7a651d188c5ed

This would be the starting point for writing a PSR.

Grégory

[Adrien Crivelli]

Hi,

https://3v4l.org/IPXe0#v8.2.20 seems to demonstrate that the plain native `SensitiveParameterValue` does not disclose any more information than your custom `Secured` class. Unless there is more features than you did not mention, I'd also suggest to directly use the native  `SensitiveParameterValue` for maximum interoperability and ease of use.

Cheers,

Adrien

[Tim Düsterhus]

Hi

On 6/7/24 04:39, Adrien Crivelli wrote:
> https://3v4l.org/IPXe0#v8.2.20 seems to demonstrate that the plain native
> `SensitiveParameterValue` does not disclose any more information than your
> custom `Secured` class. Unless there is more features than you did not
> mention, I'd also suggest to directly use the
> native `SensitiveParameterValue` for maximum interoperability and ease of
> use.

As the RFC author of the RFC in question: One thing a userland class
cannot protect against that SensitiveParameterValue as an internal class
protects against is an `(array)` cast.

Best regards
Tim Düsterhus

[Grégory Planchat]

Hello Tim and Adrien,

Thank you for your answers.

I am thinking now a PSR is maybe not the appropriate response for this use case.

The SensitiveParameter attribute and the SensitiveParameterValue give some solutions for opaque objects, however it is not sufficient alone.

Do you think it should be better achieved as internal classes/functions?

Grégory

[Adrien Crivelli]

Why do you think SensitiveParameterValue "is not sufficient alone" ? What do you need more than a value that cannot be dumped by mistake ?

[Grégory Planchat]

Hello Adrien,

I need a value that can be protected against dumps by mistake or malevolence, also through serialization by mistake and malevolence.

However, I need to keep a way of serializing the protected data through ciphering.

See: https://gist.github.com/gplanchat/9939898a1ca852fffcd7a651d188c5ed#opaque-and-ciphered-data-object-interfaces

I would like to keep the following possible:

$opaque = new OpaqueText('Value to protect');

$encrypted = $crypto->encrypt($opaque); // the returned CipheredInterface object can be serialized

serialize($encrypted);

Where $crypto is an object implementing the CipherInterface described in my ADR, it will encrypt object of type OpaqueInterface.

In the ADR, a CipheredInterface is an opaque object that can be serialized, where the OpaqueInterface cannot be serialized.

In both cases, those are opaque objects that cannot be dumped.

Grégory