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 Le mardi 4 juin 2024 à 17:41:47 UTC+2, Vincent de Lau a écrit : > 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 > > -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/4e3b73e2-d298-46d3-ad5b-f0b58b74680cn%40googlegroups.com.
