WARNING: This post contains my own opinions and does not represent the views of my current employers
In the July 2007 issue of php|architect magazine there is an article called “Shell Shock” that advocates using products from Zend and IonCube to encode and protect your PHP applications. Here are some of the nuggets of wisdom from that article:
- “Serious business demands closed source”
- “Maybe your friend will let it (ed: meaning your code) sit on his server for a few years, then dig it up, make some modifications and re-release it as his own script”
- “You prevent would-be attackers from deceiving you by first deceiving them, and you do this by veiling your plain-text source code”
This paragraph is my favourite of the whole article, and it appears at the end:
Many programmers are afraid of deception. They are
accustomed to code that is open, and they feel safer
around it. As a result, many programmers don’t even
check for errors, refusing to entertain the possibility
that the PHP functions they hold so dearly may betray
them one day. Then that day comes, and there’s an in-
explicable bug in the product that is the result of the
programmer’s failure to let go of the illusion of perfec-
tion. Perfection has a very high price. What you really
want from your code is for it to work. You want it to
keep working under varied conditions, and you want it
to keep working next week, next month and after the
next release of PHP. Give yourself all the help you can.
First I laughed when I read this article. Then I sighed. Then I got mad. Then I decided to write this blog post.
To start, I will focus on the paragraph above. What I get out of that is that if only your source was closed and hidden from prying eyes, it would not have bugs in it. Which is, of course, total nonsense. Code has bugs because it’s open and they feel safer? There are two kinds of bugs: application bugs (which is the code I would write) and system bugs (in this case, bugs that that appear from PHP itself). I’m sorry, but there is nothing I can do if there is a bug in PHP that causes my application to crash except to point this bug out to the people who have the ability to fix it. That paragraph I quoted doesn’t seem to make sense to me at all. I fail to see how encoding my code makes it somehow safer and less vulnerable to bugs from either the application level or system level. Perhaps I’m reading something that isn’t there, or have taken that paragraph out of context.
Look, I understand that people want to make money off of the code that they create. This is how I have been making my living for almost 10 years now, writing code for companies and they pay me for doing it. Over time I have come to realize that what I am being paid for now is not just the code I create, but the knowledge that goes with that code as well. Unless I’ve signed a non-compete agreement, I can pretty much reproduce any code I’ve written in the past and probably do it better now.
Having said that, I haven’t been in the business of creating an application that I sell to other people. Well, that’s not entirely true. Way back in the day I wrote a parser for use with a system run by Canada Post called eParcel. You’d send it the size of the object you’re trying to ship and it would spit back XML with data in it about what size box they recommend and how much it would cost to send the item where you were going. I sold exactly one copy of it. I created a license that said they could use my code on as many of their own sites as they wanted but they couldn’t give the code to anyone else. I got paid for the license and that was the end of it as far as I was concerned.
Was I worried they would give my code to someone else? Not really. I figured if they wanted to do it bad enough, they would do it and no license would stop them from doing so. How many unregistered copies of the various versions of Microsoft’s operating systems are out there? See my point? Microsoft made all their money selling programs that ran on their operating system. Did it matter that there were so many unauthorized copies running out there? Sure, but not as much because they were making money elsewhere.
So, encoding / encrypting / hiding your source code won’t stop those who really want to get at it. I’m pretty sure a quick search on google will let me find tools to break through the encryption and then I’ve got what I want. And where does that leave you? The same place as those who didn’t encrypt their source code. I know this will come as a blow to the ego of many programmers, but the stuff you’ve written probably isn’t so earth-shattering as you think it is. Besides, somebody out there probably already holds a patent on what you’ve dreamed up and also probably has a lawyer or two laying around.
Another reason I dislike encoding / encrypting is that it prevents you from fixing flaws in the software you’ve purchased if you are able to do so. Real world example: my previous employer Verticalscope purchased licenses of a mailing list manager that came highly recommended by an employee. It was written in PHP. There were some bugs in the application, bugs that could’ve fixed if they had access to the source code. Bugs that could be seen in the error logs. Instead, it was encrypted with IonCode’s encoder and they were at the mercy of the creators of the application as to if and when bugs would be fixed. Time and money wasted…a lot more money than what the product cost them.
If you charge money for your application and it is good, PEOPLE WILL PAY YOU FOR IT EVEN IF THEY COULD STEAL IT. If you want to be like the record industry and treat all your customers like potential criminals, then you shouldn’t be surprised when people get mad at you and do everything they can to steal your application and distribute it as far and wide as they can. What you want people to do is pay you for what you know about getting that application running (otherwise known as a service contract) and let the people who want to do it themselves (for whatever reason) be on their own when it comes to support or changes.
Some people will steal your stuff no matter what, so you can always build that into the price of your product (don’t think Microsoft isn’t doing that?) if you are so concerned. I say don’t worry about your “intellectual property” in the form of your PHP application being stolen if you are making it available to other people. You’re smart enough to find another ways to make money off it, right?
Now, I believe in respecting the “intellectual property rights” of others because ripping off someone’s stuff and claiming it as your own is just about as dishonest an intellectual act as there is. I just feel that deception gives you a false sense of security. If your stuff is good, people will want it and many of them will pay you for it too. Even if they can get the source code and fix it themselves if a problem occurs.
Trust me, even if my sole source of income was selling a PHP application that I had written I would feel the same. The author of that article probably makes his living selling applications he wrote, and has chosen the “security by obscurity” path when it comes to securing his application. Encode your stuff if you want, but be aware that the minute you choose to do that you are telling your customers “I don’t trust you” and I have a hard time understanding a business model that assumes people are going to want to steal the stuff you sell. My policy would be simple: if you buy it from me, I’ll be happy to give you as much support as I reasonable can. If you steal it from me or can’t prove that you bought a copy from me (which is pretty much the same thing) then you can expect a hearty “screw you, call me when you are willing to pay for your copy” in response to your requests. I’m sure my regular visitors will agree that seems to be more in line with my personality.



I would not compare an average PHP programmer with Microsoft, but I agree with you.
I think most companies are buying PHP code not only because they don’t want the work done on their own, but because they want to be sure that they can come to you with any problems regarding the code.
This is also one of the major arguments (in my opinion) there is against open source code. If you buy code, you buy a warranty that the code will work.
If the code has bugs it will be fixed, or I can at least ask the author.
I don’t know this for sure, but I think vBulletin code isn’t secured and they are still selling their work.
That’s an example that business is working without encrypted code.
BTW: doesn’t make encryption your code slower at runtime, or is Zent using a “compiled/unencrypted” version internally?
[...] a new post to his blog, Chris Hartjes, spurred on by an article in the latest edition of php|architect [...]
Thanks for the post Chris,
I missed that article in php|Architect, but I will certainly go back and read it now.
You must have laughed out loud when you read this nugget… “Serious business demands closed source” I’ll have to read it in context in the article, but that’s just bad….
Well although I’m a great advocate of open source, I’ve got to say that there is certainly some security in obscurity.
It’s simply a fact that it’s far easier to find bugs/loopholes in someones code, if you can actually read the code in the first place. Surely that’s the point that is being made here?
If there is no security in obscurity, why bother turning off server signatures in Apache, or why not just leave that phpinfo page up?
I don’t advocate writing sloppy code and hiding it through encryption, but lets face it… most ‘bugs’ are simply features that weren’t intended. Features that are not part of the regular functionability of the application… Features usually found by studying the source code.
Just look at any security site and you’ll see hundreds of open source applications on there, many quite respected.
[...] Burada, yazd???n?z PHP kodunu nas?l koruyaca??n?z? anlat?yor. Yaz?n?n uyar?s?n? da dikkate al?n ama
[...]
@Jacklo: obscuring sensitive information in and of itself is a good thing, but that isn’t the point. The idea of “security by obscurity” refers to the practice of relying primarily or solely on obscuring key details about the structure of your system in order to secure your application; an ignorant and dangerous practice.
However, the operative phrase there is “primarily or solely,” since obscuring certain details of an application is often an important part of a defense-in-depth strategy.
@Chris: This is possibly the most poignant piece I have ever read on this subject, bravo. I could not agree more.
Thanks Chris. A great read!
Of all of the open source software I have used, I would say I have looked at less than 10% of the code, and modified even less. Generally, I am using that software because it works, not to tinker. I would be willing to bet that most people are like that. However, if I were a devious black hat hacker, I would be all over the code looking for ways to implement my dastardly plans. That part makes me most nervous about using Open Source anything.
I don’t release all of my software source code anymore for that part of that reason. I have unfortunately, had clients go and reuse software I had originally written for them. If I increase my prices to cover the possibility of theft, then it makes it difficult to secure clients. (I’ve gone to Open Office because it is hard for me to justify MS Office’s price.) If the code isn’t provided, and I encode some specific elements for the site into the code, as a security measure against theft, it allows me to keep the prices down. This is the same reason why stores put security tags on their merchandise; it’s cheaper than letting it walk out the door.
@Walter: Your first point is essentially a counter-point to itself; in the case of most Open Source projects (especially the popular ones), the number of Good Guys vastly outweighs the number of Bad Guys, and the Good Guys are constantly on the lookout for security vulnerabilities, too.
The other benefit of Open Source is that good projects tend to attract the best minds and the best talent, which leads to the best possible software design. And secure design is what makes secure software. Compare that to the approach of closed-source vendors, who release their software to the public and patch as necessary. If this were an effective security strategy, Internet Explorer would have run out of vulnerabilities years ago.