views:

160

answers:

4

I'm trying to decide how to implement a very basic licensing solution for some software I wrote. The software will run on my (hypothetical) clients' machines, with the idea being that the software will immediately quit (with a friendly message) if the client is running it on greater-than-n machines (n being the number of licenses they have purchased). Additionally, the clients are non-tech-savvy to the point where "basic" is good enough.

Here is my current design, but given that I have little to no experience in the topic, I wanted to ask SO before I started any development on it:

  • A remote server hosts a MySQL database with a table containing two columns: client-key and license quantity
  • The client-side application connects to the MySQL database on startup, offering it's client-key that I've put into a properties file packaged into the distribution (I would create a new distribution for each new client)
  • Chances are, I'll need a second table to store validation history, so that with some short logic, the software can decide if it can be run on a given machine (maybe a sliding window of n machines using the software per 24 hours)
  • If the software cannot establish a connection to the MySQL database, or decides that it's over the n allowed machines per day, it closes
  • The connection info for the remote server hosting the MySQL database should be hard-coded into the app? (That sounds like a bad idea, but otherwise they could point it to some other always-validates-to-success server)

I think that about covers my initial design. The intent being that while it certainly isn't full-proof, I think I've made it at least somewhat difficult to create an easily-sharable cracking solution. Also, I can easily adjust the license amount for a given client/key pair.

I gotta figure this has been done a million times before, so tell me about a better solution that's just as simple to implement and provides the same (low) amount of security. In the event that external libraries are used, I prefer Java, as that's what the software has been written in.

+4  A: 

I'd suggest it probably isn't worth the trouble. The clients may not be all that tech-savvy, but if it is worth their while, they'll hack around it, and if it isn't they won't be using your software anyway.

You don't discuss the configuration process - how do you know which machine contains the MySQL database. You don't discuss what happens if the MySQL database goes down.

Frankly, the first time there's a problem, they'll probably work out that either they don't like the software enough to continue using it or they will work out how to circumvent the system. Even if the end users aren't tech savvy, they probably have in-house tech support who will be.

I would not waste your time on that. If you want a licence management system - use a professional one. Otherwise, work on trust and sensible legal terms.

Jonathan Leffler
I think you've convinced me to force our project into a decision between no licensing or paying for a 3rd-party vendor's solution. Thanks for the advice!
Ross
+2  A: 

I advice not to implement such schemes. What if your client is going to have some connectivity problems or your MySQL database goes down. You will end up with some pissed off clients.

However, if you are going to implement such scheme here is some advice:

  1. Don't make your keys sequential, either generate random keys, or do something like E(K,H(clientID + licenseID)), where E is encryption functions, K is some secret key and H is a hash function.

  2. If you are worried about pointing the app to some validate always server then you are assuming that they are tech savvy enough. So, what would prevent them to just reroute all the connections to your server to the same validate-only server using something like IPTABLES on their outbound router, or changing their /etc/hosts file. Having hardcoded static IP assumes that your server would never move. What if you decide to change ISP. Also, even if you don't ISP sometimes do renumber their networks for various reasons.

  3. To avoid problems stated in #2, you have to implement some kind of challenge response system. By client making send random string to your server together with license data and making server encrypt or hash it with some known keys. Even better to use public-key scheme for it.

  4. These schemes usually work if your server actually performs some calculations for your program. pick something that is not executed very often, so your server doesn't get bogged down. Also it has to be something non trivial, so that would be cracker won't just implement it in the fake server. And of course it has to be something essential without which your program won't be able to function.

Vlad
All valid points. The general idea I'm getting from these answers is: not worth it unless I actually knew what I was doing when it comes to licensing solutions ;)
Ross
+1  A: 

Main thing I'd worry about here is: (a) What if a client wants to run while not connected to the Internet? Well, maybe your application inherently requires a connection to the Internet to do meaningful work. But if not, is it possible that one of your customers would want to run the app on a laptop while on the road, or some other circumstances where an Internet connection is not available? Or maybe their connection is just down at the moment. Etc.

(b) What if your validation server goes down? I get very annoyed when anti-piracy features mess up and prevent me from using software when I am completely legal, and I've heard similar complaints from many others.

On the other hand, while it's easy enough to make a scheme that requires some sort of "license key" to run, it's tougher to prevent a user from using the same license key on two machines. I don't know any way to control the number of installed or running instances without having some sort of "license server" like you describe to monitor them.

How big a problem do you expect piracy to be? Is your app something that most customers would only likely use one or two copies, or would likely want many? If the former, all the extra effort may not be worth it. If the latter, different story.

One technique I've seen used on some commercial products is to have the customer install a "license server" on one box in their own local network, this server then gets loaded up with a number of license keys, and the clients validate against this. It doesn't take a brillian hacker to beat this -- just set up two license servers, duplicate the keys, and point some clients at one and some at the other -- but it enables honest users to comply with license limits without having to worry about Internet outages.

One idea I tried once was to set up a validation server like you describe, but say that if a connection attempt fails, we log it and let it go, and only block access if some period of time -- I think it was a week -- goes by without managing to make a connection. That way temporary Internet outages don't inconvenience the user.

Short answer: Your idea ought to work, but has potential catches.

Jay
The software does need to have a connection to be used at all. My concern is what happens when the machine running the licensing MySQL db goes down for whatever reason. I'm thinking perhaps the potential sales lost to piracy are the lesser evil compared to the headache of implementing my own licensing.
Ross
Another thought: How likely is piracy? If you're selling a video game, frankly, the odds are that customers will make copies for their friends, etc. If your primary customers are large corporations, they usually aren't going to risk the legal issues that would arise if they got caught in order to save a few bucks on a legal copy.
Jay
A: 

Competent commercial licensing systems -such as the one we offer - deal with all these issues and more: not having a direct server connection, ensuring users can't over-subscribe, server fail-over, grace periods etc. For an example - see here: www.agilis-sw.com/orion

Dominic