On Premise software - license generation, validation, revocation

Discussions
#1

Hi all

Currently looking around for my next ‘thing’.

I’m researching a market that would be suitable for a ‘good’ software application. The current offerings seem to have various issues with no clear leader.

Anyway, the market or application isn’t important, it’s relatively small but could do with a shake up.

If I proceed, I’m likely to build this as an on premise browser based app written in php (my primary skill set). I’d implement something like ioncube encoder to protect the ip/source but am wondering about controlling installations via license keys.

I’d be interested to hear what you folks use for generating, validating and revoking licenses. of course also detecting additional installs etc.

Many thanks

Dean

#2

I think you are getting way ahead of yourself.

The most important (and frankly, hardest) part of a startup is getting to the first customer. Anything that doesn’t move you towards that is a distraction and a waste of your time.

But, to answer your question, for a SaaS app, you can generate a unique cookie but that will be browser based. I don’t know of a way for the Browser to know something unique about the computer it’s running on.

We do measure this for our PC subscription (where we CAN get a unique ID for the computer, not just the browser) and it’s not a significant problem (installing on additional computers)

2 Likes
#3

Thanks for the response although it won’t be a SaaS app at least not initially (thanks Ian/helpspot for the model). It will be an on premise thing, server based SQL backend, php/just/HTML/CSS client in the browser.

Ioncube will encode the source and gives some licensing lockdown but wondered if anyone is using anything else.

This ‘tech’ question is really the only one I have at the moment as I’m capable of and have built large web applications but not as a sellable product.

I agree ‘the first’ customer is important and due diligence is underway in that respect, full market research will be done once initial viability questions (tech and business) have been answered.

#4

I’m getting ahead of myself too, but since I’m developing an “on-promise browser-based application” too, I’ll share how I do that.

I’m watching my first customer internal processes and I realized nobody of that scale is going to steal my software intentionally. What is the real risk is a “casual piracy” as Wyatt calls it – i.e. “we need another installation for that critical project of ours, let’s copy the code to that new server and settle the matter of the license later”. Of course, the “later” never comes - project completes, and the installation silently dies, or, worse yet, continue to be used for other projects where people are not even aware there is no license for it.

So my licensing scheme is not trying to protect against hackers. I do not even obfuscate my code.

What I’m doing is:

  1. I tie my application to a specific server address. The address is specified when the license is generated.
  2. The license is a simple list of properties, encrypted with my private key and converted into a hex string.
  3. When the license is placed into the application config, it is decrypted with my public key (kept with the code). If decryption is successful, then the license is not tampered with.
  4. One of the license properties is the IP the code should listen on.
  5. If the code is copied to another server, the IP doesn’t match, the license is marked as invalid and the trial is in effect.
  6. Trial start time is calculated from the time the earliest artifact (file) of the application is found on the file system, i.e. there is no special registry key or anything like that.
  7. Each Nth page request (the closer to the end of trial the more often) is redirected to the license page where it explains that this is a commercial software, it needs a license, but currently it runs on trial which will expire in XXX days, and urges them to obtain the license before that day.
  8. I also have a grace period – when the trial is expired and they still did not get a license, I give them some more time, but increase the frequency and urgency of license message. This is because, as I found, even with trial warnings people manage to push that task to the back of their list, especially when their hands are full. So I give them a one more short chance to correct the licensing situation.

This protection is not perfect, but given what it should prevent, I believe it is satisfactory.

Would I buy a licensing solution? Not at this stage. It took my about 2 days to implement and test my solution (trial expiration test cases take most of the time), and it is good enough for now. If I ever reach 1000s of customers, I may reconsider - many licensing solutions have much more functionality than just checking the license file - but at this point it is impractical.

3 Likes
#5

Great reply, many thanks

I know if someone is determined to, they will hack/crack the code so there is a limit to the energy and cost to be put in to this.

cheers

#6

Pinging @ian on this one, as he might have some valuable input based on experience.

2 Likes
#7

HelpSpot’s gone 11 years without anything nearly as fancy as you’re thinking.

We use Ioncube to prevent modified version and the support they require. If you’re dealing with a segment where modification is unlikely you can kill it and it will help sales if you do. We’re likely to kill it in a future release as well by building detection for modification in so support will know, but gotta find time to build that.

On the licenses, HelpSpot is a just a few bits of data like licensed users, support expiration, trial date expiration, etc in a super weak encrypted text file (many hacks and key gens are available, I ignore all). It’s only encrypted to keep honest people honest, so that in a pinch if they think hey I’ll just up this by 3 licenses for now and buy move later they can’t and have to come buy them. The person who thinks, I don’t want to pay for this and don’t care about support, let me hack it will never buy so don’t think about them.

We do no revocation.

We do no installation count checking.

We don’t do any call home check that could disable the system for any other sort of licensing issue.

The license is not tied in any way to the servers IP (we don’t use any of the ioncube license stuff).

The ONLY goal of the license system is to keep honest people honest. Anyone else can very easily get past any security, especially in a PHP application where the code is never truly compiled and cannot be effectively obfuscated or encrypted.

3 Likes
#8

awesome, I really appreciate the reply, thank you.

I guess the support is the key rather than hardcore licensing, if you can’t be verified when you need support then you don’t get it.

many thanks again.

#9

For sure, you absolutely want to make sure the person you’re dealing with is a licensed customer so that you’re not giving support to stolen installs and what not. That’s their only real impact.

1 Like
#10

Honestly, I wouldn’t waste time thinking about this until you have some paying customers.

If you are really concerned about monitoring installations, then maybe you could get each server to access a .xml file on your server to see if it is running the latest version. At the same time you could log the IP and this will give you an idea of how many servers are being used.

#11

Thank for the reply Andy.

It’s just me thinking through everything before i put a huge amount of work in to it. TBH building the product is the easy bit as I’m sure you know but it’s something that i need to have considered before i start whichever ‘system/tool’ i’m building.

I am fully down with Ian and Vlad’s philosophy, keep the honest customers honest and don’t waste energy on the pirates, instead use the time and energy to generate more legit sales :wink:

#12

It is not that simple in corporate networks. Under Windows you just need to read the proxy settings, but under Unix the proxy must be manually configured, and the hacker won’t do it.

But there is a workaround – since the application is a browser-based, the “call home” can be made from the browser window, via AJAX. The browser is configured to use proxies, and the call most likely will succeed.

#13

We do desktop software, we had a product that was downloaded as beta about 20k times within 2 weeks and hyped a lot. The beta was not much different from the final software - we thought about software protection early on and that was a good choice. We use LimeLM, it does take away a lot of hassle and it makes sure that “a valid purchase does not get used beyond his intended number of activations”. I think that is important. People are not honest and share keys/access etc. very often. However, I don’t how how it could be integrated into your solution. I would NEVER do a software protection solution on my own. There is so much hassle with all those details like firewalls, security settings, etc. - just doesn’t work.
I wish I could agree with “keep the honest customers honest and don’t waste energy on the pirates, instead use the time and energy to generate more legit sales” - but people are simply dishonest. If we did not have the software protection, I have no doubt we would have only generated 1/10th of the revenue MAX and we would have been out of business. Don’t take this easy. They will take your work for free, bother you with support tickets and badmouth you on forums. Well, maybe I have been too long in this business :wink: At least think about whether you can find out if people use your software through another customer and make sure you can call them up. I have subscribed to a few (paid) newsletters and they tracked down abuses really well and threatened the “sharing party” to cease the subscription. It worked really well - nobody in the “scene” dared to share the newsletters… Have a plan for that at least.

Cheers
Jan

1 Like
#14

Thanks for the reply, more food for thought :slight_smile:

#15

I did have this happen once. A customer of an on-premise PHP script I wrote a decade ago downloaded the demo, contacted support a few times during the trial period, ultimately didn’t purchase… which would be fine! Until I noticed a couple of months later they were still running the software in production, and had deliberately hacked out all my “trial version” code. I eventually sent a polite “Hey, what’s going on?” email, and they did (eventually) pay up. But it definitely wasn’t worth the time I spent stressing about it.

As for generating license keys, Brandon Staggs has an excellent article on the basics of key generating algorithms.

#16

Pretty complicated.

I wonder what are the benefits comparing to signing the license with a private key and including the public key into the code?

In both cases the cracker can patch the code to work around the check completely, but with the public key cryptography there is no way they can produce a keygen – that would require to generate a matching private key, which is considered out of reach for mere crackers.

3 Likes