License key feature upgrade - pre-purchasing

HI,I've talked about this issue before, and I have now implemented a solution that I thought I would share, just to see if there are any obvious security holes in what I have done (I am by no means an expert in this area).

The basic problem was that I have some resellers for whom I bulk create license keys. This is fine, the resellers sell these and all is well. The problem arises when I add new features to existing licenses - in my case, a couple of optional modules. I needed a solution whereby I could sell pre-made license keys to my existing resellers, and they could sell these on to their customers, without having to contact me (or the buyer) to get existing licenses upgraded.

My solution is as follows:

Create a simple php database with a single table, containing columns for a random license code, feature upgrade type, used flag (has this update been used already), and existing key and timestamp columns (to provide a basic audit trail).

I populate this database (which is on my webserver) with rows containing a GUID and a bitfield containing information about the modules that need to be updated.

In my application, I call a php script on my webserver (just using GET parameters) which takes as parameters the GUID upgrade code and the existing application key. The existing application key is pulled from TurboActivate, and the user enters the GUID code having purchased it from a reseller. I don't see that this communication needs to be particularly secure?

The php script on my webserver does all the Lime interaction - it has the API key. The script looks up the LIME Key id using the supplied text key, checks that the supplied GUID exists in the DB and has not been used already, looks at the features specified and then does an update features via the LIME API. If that is successful, the used flag, text key and timestamp fields are updated in the DB.

Once this web request returns to my application with a success code, I just do a license reactivate and inform the user of any changes.

This seems to me as if it should be secure, and should work OK. All I need to do is create a bulk set of GUIDS and insert them in the DB, and send same set of GUIDS to my reseller.

How does that all sound?

cheers,Matt

Just to add, one of the questions I have is, is a GUID appropriate for these upgrade codes? The way I see it, all I need is a unique(ish) code that I can pre-sell. I don't see any particular risk from someone trying blast my webserver with thousands of combinations, since an existing paid license is required and all the script does is update features on that license. It just needs to be "good enough". Even a random series of, say, 10 letters/numbers would probably be more than sufficient, especially since I do have a uniqueness constraint on that column in the db.

Matt

As far as I understand it that all sounds good. I am a little confused as to why you want to use a GUID, though. Why not just use the product key? You can change license fields for product keys after they've already been generated, so there's no problem there.

Perhaps I'm not seeing the full picture.

Wyatt, the situation is this:

pre-sell x number of license keys to wholesaler, who distributes to retailers in his country, and they sell to users.

Now add feature y. This is an extra cost module, and is activated by adding a feature to an existing (already sold) license key.

How to sell upgrades to Y in a simple way, through a wholesaler? The current mechanism required the user to request the feature from their retailer, who forwards the request (with user's key) to the wholesaler, who forwards the request to me. I upgrade the license and invoice the wholesaler. A painful process, and without doubt losing me a lot of sales as the wholesaler wants to just buy "keys" for the new module.

So now I pre-make "keys" (upgrade codes). I was planning on using GUIDs for these codes, but have decided to go with random 12 character strings instead. When the wholesaler asks for 50 of feature Y for his existing users, I make 50 random strings (random.org) and populate them into my DB. These are what is used in the process I described in the first post. What it lets me do is sell upgrades for existing keys in advance, which lets the wholesaler distribute them and users buy them "off the shelf" to upgrade their existing key.

Does that make sense?

Oh, Ok -- sure, that makes sense. That all sounds good. There shouldn't be any big problems.

Of course, you mentioned "hammering" your servers, which you should be concerned about. But the solution is rather simple. If X failed requests happen in, say 1 hour, then ban that IP (or block of IPs) for 24 hours.

I think getting smashed by hackers trying to guess a code is unlikely, simply because all the script does when successful is update an existing key. The features do not show in the app until after the script call, when we just do a reactivate license call. So the hacker would need a key already, and all of the effort would (could) potentially result in just a single, relatively low priced, update to his existing license. Not impossible, but unlikely is my guess..

Reply
Discard post