On the Interoperability of Cryptographic Components -or- Stop Writing In-House Cryptography Features

[Scott Arciszewski]

Hi FIG,

I've noticed that a lot of frameworks and platforms provide their own cryptography features, and they're almost always insecure from the outset. Some historical examples:

• CakePHP: https://github.com/cakephp/cakephp/issues/6139
• CodeIgniter: https://kivikakk.ee/cryptography/2016/02/20/breaking-homegrown-crypto.html
• Joomla!: http://www.openwall.com/lists/oss-security/2015/11/08/1
• Laravel: https://labs.mwrinfosecurity.com/blog/laravel-cookie-forgery-decryption-and-rce/
• Magento: http://www.openwall.com/lists/oss-security/2016/07/19/3
• Mako: https://github.com/mako-framework/framework/issues/183 (discovered yesterday)
• Zend\Crypt: https://framework.zend.com/security/advisory/ZF2015-10

It's somewhat surprising that this keeps happening even in brand new frameworks, when independent cryptography libraries exist that solve virtually every use-case for cryptography features that a PHP developer is likely to encounter.

To wit:

• Password storage
• password_hash() and password_verify()
• https://github.com/ircmaxell/password_compat
  
• Random data
• random_bytes() and random_int()
• https://github.com/paragonie/random_compat
  
• Secret-key cryptography
• Encryption
• https://github.com/defuse/php-encryption
  
• Authentication
• hash_hmac() and hash_equals()
• Public-key cryptography (via RSA)
• Digital signatures
• https://github.com/phpseclib/phpseclib (or EasyRSA below)
• Encryption
  
• https://github.com/paragonie/EasyRSA (combines phpseclib with defuse/php-encryption to guarantee best practices are followed)
  
• RFC 4648 character encoding
• https://github.com/paragonie/constant_time_encoding
  

None of the libraries linked above require a particular framework or any PHP extensions. Most cryptography features are a solved problem-- and the ones that remain unsolved probably aren't the sort of features you expect a framework to provide for you. (Multi-Party Elliptic Curve Diffie Hellman over Curve25519? Merkle trees based on the BLAKE2b hash function? Probably not commonly requested Symfony features.)

I would like to propose that any FIG members who provide their own cryptography features assess whether they will continue to in-house their cryptography (and thus assume the liability for enlisting cryptography and security experts), or make plans to migrate towards something well-studied and highly regarded by PHP security experts.

This isn't something I can conceptually see as a PSR-### document, but rather something that FIG members would almost certainly benefit from considering.

Thank you for your time,

Scott Arciszewski

Chief Development Officer

Paragon Initiative Enterprises

[Alexander Makarov]

Hello Scott,

While it's important, I think it's out of scope of the group. Each project decides individually.

[Alessandro Lai]

Why should it be out of scope? A PSR is a reccomandation, and advocating this kind of security best practice is a good thing here.

[Alexander Makarov]

FIG always focused on interoperability i.e. multiple implementations, same interface. What Scott proposed makes sense but doesn't fit into "multiple implementations".

[Larry Garfield]

That's an over-simplification of FIG's scope and activity.  PSR 1, 2, and 12 don't really have "one interface, many implementations", but that's because it wouldn't make sense in that problem space.  PSRs 9 and 10 likely won't, either.

That said, I'm not sure what exactly would fit here as a PSR.  The proposal seems to boil down to "don't roll your own crypto!", which I heartily support and endorse as a policy, but is a bit thin for a PSR.  "Only use these libraries" would be out of scope, as we don't endorse specific libraries we don't maintain (and we don't maintain much in the way of libraries, by choice).  Beyond being an extra section in PSR-9/10 somewhere, I'm not sure how this would fit into FIG's model.

Scott, what exactly were you thinking of?

--Larry Garfield

--

[Woody Gilk]

I would be in favor of a PSR that defines best practices for crypto. I
think it is similar to PSR-(0-4) that define proper methods and not
specific implementation.
--
Woody Gilk
http://about.me/shadowhand

> --
> 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+u...@googlegroups.com.
> To post to this group, send email to php...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/694325b8-a91d-dc44-2291-85381add8f9b%40garfieldtech.com.
>
> For more options, visit https://groups.google.com/d/optout.

[Paul Jones]

> On Jul 30, 2016, at 12:13, Scott Arciszewski <sc...@paragonie.com> wrote:
>
> Hi FIG,
>
> I've noticed that a lot of frameworks and platforms provide their own cryptography features, and they're almost always insecure from the outset.

...

> This isn't something I can conceptually see as a PSR-### document, but rather something that FIG members would almost certainly benefit from considering.

I don't preclude it from being a PSR out-of-hand, but I do think it sounds like a better candidate for "PHP: The Right Way" than the FIG.


--

Paul M. Jones
http://paul-m-jones.com

[Scott Arciszewski]

​

​Scott, what exactly were you thinking of?​

My intention was simply to address the representatives for all of the major PHP frameworks and libraries at a place they all congregate rather than attempt to enumerate them and contact them individually with specific recommendations. I don't have anything resembling action plan in mind.

The original post was the action.

I'm really not interested in carrying this further into the realms of policy or standardization. Everyone is of course free to write their own crypto. In other words: that is something you can do; but should you?

Personally speaking, I find it a bit concerning that the reflexive response to my post was the consideration of "Should we make this a rule?" Some of the most stable structures in nature are an emergent property from chaotic systems. We don't always need more rules.

Scott Arciszewski

Chief Development Officer

Paragon Initiative Enterprises

--
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/oQVs1WjJ3UQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

[Christopher Pitt]

I find it a bit concerning that the reflexive response to my post was the consideration of "Should we make this a rule?"

To be fair, this isn't an unreasonable assumption of intent given where you've posted it. :) 

[Nate Abele]

On Monday, August 1, 2016 at 1:29:23 PM UTC-4, Scott Arciszewski wrote:

​

​Scott, what exactly were you thinking of?​

My intention was simply to address the representatives for all of the major PHP frameworks and libraries at a place they all congregate rather than attempt to enumerate them and contact them individually with specific recommendations. I don't have anything resembling action plan in mind.

Hey Scott, thanks for taking the time to post this, and on behalf of the PHP community, allow me to apologize. :) Your first bullet point there was at least partially if not completely my fault. What can I say? I was young and stupid. Anyway...

 

The original post was the action.

I'm really not interested in carrying this further into the realms of policy or standardization. Everyone is of course free to write their own crypto. In other words: that is something you can do; but should you?

Personally speaking, I find it a bit concerning that the reflexive response to my post was the consideration of "Should we make this a rule?" Some of the most stable structures in nature are an emergent property from chaotic systems. We don't always need more rules.

Well, informally, rules are sort of what we do here. You're coming to us with something very high-level which, in principle, everyone here probably agrees with. We're just not sure what to do with it. Generally speaking, the standards recommendations we publish are a formalization of what the community is already doing, and most of us tend to shy away from anything that could be perceived to be dictatorial.

If there was an opportunity to roll this up into a higher-level 'security guidelines' PSR, I think that might make sense. In the meantime, I would echo the previous suggestions of PHP the Right Way as a pretty good venue.