
Cryptographically Secure PHP Development - CiPHPerCoder
https://paragonie.com/blog/2017/02/cryptographically-secure-php-development
======
mi100hael
This Paragon shop is the only group I ever see putting out any quality
code/docs in the PHP ecosystem. They're simultaneously proof that it's
possible to develop good software in PHP, and that PHP is otherwise a mess,
insecure, and should be pretty much avoided.

~~~
tyingq
> PHP is otherwise a mess, insecure, and should be pretty much avoided

That doesn't ring true to me. Personally, I think a lot of the perception is
just that PHP appeals to a broad audience, so there's a lot of unskilled
people producing code.

There are some language inconsistencies so "messy" might be justified. I don't
see it, though, as inherently less secure than other popular languages.

If you mean, for example, SQL injection, php does provide the correct path,
and it's in their documentation. Sure, it's possible to use aribtrary strings
in SQL, but it's also possible in Python, Ruby, Perl, and so forth. Similar
for traps like eval().

~~~
CiPHPerCoder
They might be alluding to some of the specific examples in our blog post.
Like, mbstring.func_overload, or chr() being a great way to leak crypto keys
via cache-timing.

These sort of things aren't obvious and can very easily (and justifiably) be
blamed on the language itself.

A lot of PHP crypto libraries are very cavalier about using functions without
understanding their implementation details.

[https://github.com/devi/Salt/blob/fde775cf52402013efce812759...](https://github.com/devi/Salt/blob/fde775cf52402013efce81275919dcfd9f381fba/FieldElement.php#L19)

[https://github.com/phpseclib/phpseclib/blob/ab1da5ac1f2fa60b...](https://github.com/phpseclib/phpseclib/blob/ab1da5ac1f2fa60ba97d6f6f6909b0123704bc36/phpseclib/Crypt/RC4.php#L327)

[https://github.com/zendframework/zend-
crypt/blob/9b7da4a6d4d...](https://github.com/zendframework/zend-
crypt/blob/9b7da4a6d4db0bfc5c1cd0910d08b3e4af6d9cc5/src/Symmetric/Padding/Pkcs7.php#L28)

Fortunately, most cryptography libraries these days just wrap OpenSSL and
rarely implement their own ciphers or hash functions.

~~~
tyingq
Hmm. Most languages have some equivalent to chr() and ord(). And clunky
unicode support isn't exclusive to php.

------
throw2016
Its a well known fact PHP powers a ridiculous number of very high traffic
sites. It's also a well known fact that HN favourites like ruby struggle.

PHP is extremely easy to set up and use. Ruby is a quagmire of dependencies
and build environments.

This makes php bashing on HN tedious and disconnected from reality. There is a
clear preference here for tech that pays more and but let's not try to pass it
off as a technical preference.

~~~
234dd57d2c8dba
Agreed, I've pentested php apps and some are very hardened and difficult to
breach and I've tested Python django apps where I completely compromised the
server. Language has only a weak correlation to security for web applications.

------
sbarre
Nice to see this work being shared with others.

------
a4753e66
Is there an analysis out there which evaluate some of the largest PGP projects
regarding these cryptographically best practices?

~~~
CiPHPerCoder
I'm assuming that's a typo (s/PGP/PHP/).

There isn't such an analysis yet, but I intend to do one in the near future.
We have a similar analysis for out-of-box security features of popular open
source CMS: [https://paragonie.com/blog/2016/08/on-insecurity-popular-
ope...](https://paragonie.com/blog/2016/08/on-insecurity-popular-open-source-
php-cms-platforms)

Our security page has some of the audits we've done (at least, the ones we
were permitted to publish) as well as our security advisories.
[https://paragonie.com/security](https://paragonie.com/security)

I'm pretty active in the PHP community and get looped into a lot of pull
request discussions (e.g. [https://github.com/facebook/php-graph-
sdk/pull/552#issuecomm...](https://github.com/facebook/php-graph-
sdk/pull/552#issuecomment-182123879) for Facebook's SDK), but it's possible
I've missed a few.

~~~
fictioncircle
I'm curious why you submit CVEs for development repositories of code that is
not supposed to be run in production?

SMF 2.1 for instance is purely development releases that are _not_ supposed to
be used in production.

[http://www.simplemachines.org/community/index.php?topic=5354...](http://www.simplemachines.org/community/index.php?topic=535446.0)

> As always, keep in mind that Beta Releases are NOT recommended for
> production sites.

It is just the first time I've ever seen someone create a CVE for what is
essentially a do-not-run-this-in-production code branch for an open source
project. I'm used to people waiting until at least a Release Candidate version
before doing that.

~~~
CiPHPerCoder
In the case of SMF, the same vulnerabilities were present in the production
versions.

Do you have any other instances you'd like to inquire about?

~~~
fictioncircle
> In the case of SMF, the same vulnerabilities were present in the production
> versions.

I'm just curious which production version you are talking about now since
2.1.X has 0 of those?

It doesn't really impact me one way or the other, so feel free to ignore me if
you prefer. Its just odd.

~~~
CiPHPerCoder
The vulnerability is also present in the v2.0.x branch.

The development 2.1.x branch (which is what was on Github) had the
vulnerability, and that's where I reported it, but it's not only in the new
code.

I think maybe you're confused somewhere?

