-1

I've got a PHP product that clients install on their server. It's a pay-monthly product, and I need to protect it.

I did consider Ioncube (and friends), and have used several of them before. However, they're all fundamentally just deterrents because the client has all the code. There are examples (and services) of the web that crack each of them.

Of course a more secure solution would be to run it as a SaaS project, but that's not possible in this case.

So I'm considering a remote licence system...

The licence system would house a section of the PHP code, and a client requires a valid licence key to access it. This section of code would be corn-related functionality that's essential to the running of the program. So essentially an API. Clients could either be limited by IP, or by # API calls.

Clients would be emailed a licence key when they signup, then they'd enter this into the product. The product would use this API key for all future requests.

Pros:

  1. "Uncrackable" from the client side
  2. No special software required for the client (Ioncube loaders etc)

Cons:

  1. If the licence server goes down no clients can access the software (I'd have redundant load balanced clusters in 3 different geographic regions with 3 different providers)
  2. If the product/business dies, clients are left without access (I'd release the code to them in this situation, because there would be nothing to lose at that stage anyway)

Are there any significant issues I'm missing from the pros/cons list above?

So please, tear my idea to shreds :)

Note: This isn't a discussion about the merits of code protection vs plain source code. For this project, I'm required to protect it. This is in a market where anything insecure appears all over the web several days after release.

HappyTimeGopher
  • 1,377
  • 9
  • 14

1 Answers1

1

If the thing you're giving through API is small and simple, they can just replace it by hiring another engineer for an hour - they have the sources, after all.

If the thing you're giving through API is complex, why not host the entire application on your server in the first place?

Amadan
  • 191,408
  • 23
  • 240
  • 301
  • Good point about them rewriting the missing section. It would be doing several DB lookups and using API keys to other services. So good luck if they want to recreate that. But I'm bound by other constrains by the client. They've already got the software written and want protection as an afterthought (usually a bad idea, I know). – HappyTimeGopher May 30 '14 at 09:38
  • Hosting part of the solution should help, though if remote nodes are doing DB writes you now have a complex scenario if needing to keep nodes in sync and handle outages. In the cons section you should also add latency. You say that code would make it "all over the web" in several days. Not sure why your customers would leak the code, but whatever you do is unlikely to stop them trying, so having adequate legal agreements in place would seem prudent. Filling in the missing pieces may also not be as hard as you imagine unless your API contains a significant amount of business logic. Good luck! – Nick May 31 '14 at 13:27