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 <https://paragonie.com> -- 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 post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/13c7b676-f18f-4a9d-a4d9-6b1666ab2c79%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
