It's not that people don't think you can know security AND write PHP, it's that it's seen as very uncommon, largely because of historical context and PHP's ecosystem.

PHP, as you probably know, started as a really basic (if obtuse) preprocessor for HTML pages. It plugged nicely into Apache via mod_php, and was relatively simple and low-footprint to set up, so a lot of cheap shared-hosting sites set it up. For beginning/inexperienced web developers on small projects, this was great; you no longer had to go host your own Java/ASP/whatever web server to have server-side logic, now you could just use a text editor and FTP.

Unfortunately, this also meant that PHP attracted a lot of inexperienced developers -- the kind who haven't yet learned things like why you should hash (and salt) your passwords, why you should use stored procedures, and so on. (Editorial: it didn't help that the language itself didn't, at the time at least, make it obvious how to do such things.)

Granted, there were some developers who knew better who picked up PHP. But generally developers who have some working knowledge of web security best practices get that knowledge by working in the field -- which at the time, typically meant "heavier-weight" stuff like Java or ASP.

So with large numbers of inexperienced, security-unaware devs enabled to write webapps in PHP, large amounts of poor, insecure PHP code was written. So PHP got a bad rep, which only exacerbated the problem by creating a self-fulfilling prophecy that turned companies who could hire more-experienced devs off from PHP.

I haven't personally touched PHP in a long while -- I personally just don't like some aspects of the language -- but I've heard some steps have been made in the PHP community to make best-practices more easy/commonplace. Which is great! But the old reputation is still there, and bad reputations are hard to dispel -- especially in the corporate world.

>> it didn't help that the language itself didn't, at the time at least, make it obvious how to do such things.

Why should a language "make it obvious" what are clearly implementation details?

Hashing passwords is not the job, or the concern, of any language I've used.

> And yet, I've never succeeded in extracting a straight answer from anyone about why they believe that someone cannot simultaneously have some working knowledge of security and enjoy building PHP applications.

These people are probably thinking: "If you truly knew infosec, you would have moved onto a more advanced language by now."

PHP has a reputation as a "training wheels" language. It's seen as a great starter language to learn the fundamentals of web development, but the expectation is that a "good developer" will eventually migrate to Python/Ruby/Node/whatever once they outgrow PHP.

By staying with PHP, you're signaling that you haven't cleared the bar of being a "good developer" yet.

Is this fair? Hell no. But that's life. My advice? Get familiar with another scripting language. The difference between "I'm a PHP developer" and "I'm a developer that knows Python, PHP, and Javascript" to a lot of people is huge.

I can superficially claim some familiarity with each of PHP, C, C++, Java, VB.NET, Delphi, Perl, Python, HTML(5), CSS(3), Node.js, Javascript, jQuery, Fabric.js, MySQL, PostgreSQL, MS-SQL, sqlite, XML, and webserver administration (Apache HTTP Server and nginx).

In terms of real experience (i.e. I've finished a project in this language), the list narrows down to HTML/CSS, Javascript (plain and with jQuery), PHP, Java, C, and the SQLs listed above.

But if any degree of "expertise" is required, I'm only comfortable claiming that I have the requisite experience and environment familiarity with PHP projects (at least, in terms of server-side programming languages).

I could easily call myself much more than a PHP developer (and if my experience with some other devs has been any indication, get away with it!), but I'm hesitant to do so until they feel natural to build projects in.

I'm sure it's possible to write secure PHP code but PHP actively works against you. The language has improved a bit over the years (magic quotes is no longer a thing) but I don't have any confidence that the PHP developers will make reasonable choices in the future.

Take something like == to compare two strings. A reasonable person would compare them as strings. A PHP developer would try to compare them as numbers (losing information in the process). Many PHP users don't consider that a problem. Many PHP developers don't consider that a problem. (Some realize it's stupid but don't want to break backwards compatibility).

I typically use === or hash_equals() depending on the use case ;)

Magic quotes needed to die.

There are also a lot of other improvements in the past few years that I've grown to appreciate.

MD5/SHA1 password hashing need(ed/s) to die; password_hash() and password_verify() needed to become a thing.

Register globals needed to die.

There are still some changes that I believe are necessary to clean up the rest of the ecosystem.

MCRYPT_RAND needs to die.

Devs choosing MCRYPT_RIJNDAEL_256 thinking it's AES with a 256 bit key rather than a non-AES flavor of Rijndael still needs to die.

Composer's unverified curl | php needs to die.

If I had to guess, it is because many people came into web development and would write PHP code with basic security bugs - some of the old built in functions didn't help PHP any (mysql and mysqli).

I don't share this belief mind you.

1)Memories of the older days where mysql_escape vs mysql_real_escape 2)It's 2014 and Drupal just got exploited by a sql injection attack. 3)Because of php's weak typing, php will accept a lot of strange input such as arrays with variables in them. Which is weird and can lead to some remote code execution 4) If you're busy defending against xss and sql injection still who is defending against more esoteric attacks like csrf, denial of service, timing attacks, etc? (If you can tell me about csrf and have set up csrf protection in a project you're in the minority of php developers)

> (If you can tell me about csrf and have set up csrf protection in a project you're in the minority of php developers)

Incidentally, I wrote this: https://github.com/resonantcore/lib/blob/master/src/Security...

#3 is surprising to me. I've seen some strange behavior (throwing [0] after a post field can lead to unexpected errors and sometimes lead to an information leak) but never RCE.

Like it or not, a cross-sample of PHP developers will have more bad programmers than possibly any other language (barring ColdFusion, Flash, and ASP, possibly).

Our good developers are just as good as the good developers in Python or Ruby or JavaScript, but we have enough bad developers to keep the guys at Soylent fed for a long, long time.

Edit: It also doesn't help that two of the biggest PHP projects are Drupal and WordPress, two pieces of software with atrocious security records.

Is WordPress's record really that bad? Most of the vulns I hear about come from shoddy plugins, not WP itself.

WordPress core for a long time was very vulnerable, probably still has vulnerabilities, and if you're running even a slightly out of date version of the software (which might be a requirement if you've made a lot of customizations or are using a plugin that is no longer supported), you are likely vulnerable and it is almost trivial to identify that you're running WordPress and your WordPress version.

Experience has taught me that no one is going to make a distinction between WP core and a third party plugin when they could instead shit on PHP and PHP programmers.

Heh. Well, I'm going to be contributing to the WP core soon (making their auto-updater use openssl_verify), I'll fix anything I find there.

The worst thing I spotted when I was looking through it in June was a lack of a CS in their PRNG. I don't consider md5(uniqid(mt_rand())) adequate; urandom or bust :)

Insecure code can be written in any language. Its not something that is built-in (to some extent its true). Its not the language to be blamed, but the one who is developing insecure code. PHP is bad reputed only due the the inexperienced developers. Actually, PHP is so easy to pick up that any one can start building stuff with it. PHP is a great language, it has some odd sides, but overall its a great language if you use it wisely.

While I agree in general, security holes can be (and often are) introduced at the interpreter level. PHP even has a project that attempts to patch these with an independent module[1].

A good security practice is to stand on the shoulders of giants. Just as Windows is highly secure because it's widely used and incessantly attacked, so are the major web software stacks.

1. http://www.suhosin.org/stories/index.html

>> Just as Windows is highly secure

That's a bold statement.

I don't presume to know more than you, but I don't hear that sentiment echoed very often.

This depends on your definition of secure. The way I use it, "security" is the lowest level of vulnerability to the highest level of attack.

Some OS's (notably OS X a few years ago) are thought to be secure because their installed base is low, so they're low-value targets for attackers. Apple, in general, has a terrible track record with security, and OS X's lack of malware was just security by obscurity -- the vulnerabilities hadn't been discovered because no one was looking for them.

Windows, on the other hand, has been incredibly high-value target for decades. It has a huge installed base, and it's used by many governments, militaries, banks, and corporations.

For that reason, Microsoft has been forced to become a leading security organization. You can't keep selling massive contracts to governments and large corporations if you're vulnerable to malware.

There are obviously ways to misuse any tool, including an operating system. Many operating systems are insecure if you configure them incorrectly. My statement was just about the incredible volume of attacks that Windows is resistant to, simply because it's been attacked so heavily for so long.

When something becomes more resilient the more it is damaged, it can be said to be antifragile.

However, a closed source product that is engineered centrally still has elements of fragility contained within it that you will not find in decentralized approaches. In the very long-run, antifragility wins over robust yet fragile systems.

That is one reason why I will consider GNU/Linux and BSD to be more secure than Windows. In the long run.

GCHQ recently came out with a statement that Ubuntu is the most secure-by-default consumer grade OS out there.

http://insights.ubuntu.com/wp-content/uploads/UK-Gov-Report-...

" person pretty much said that they will never take me seriously in the realm of [computer/cyber/information/network/application] (select appropriate) security as long as I write PHP code."

that's reason enough not to take that person seriously - a truly experienced fellow programmer would have a tough time making that presumption about another programmer in ANY language

The sad part is that a lot of people (especially local) who are at least mildly respected in software development or infosec give me crap for being a PHP dev.

None of the people I've ever talked to who are far in their field (Zooko Wilcox-O'Hearn, Thomas Ptacek, Anthony Ferrara, Dan Kaminsky, Matthew Green, etc.) ever gave me flak for PHP though. :)

I wouldn't pay them any mind

There is no true scotsman according to people with that view