0

Quick Background: I am designing some aspects of a licensing system. The main app can be thought of as a client "portal", where we will have many versions of "the app" installed across multiple environments/clients/etc.

The process of validating a license will happen daily: the client app will send some data up to a central licensing server to check if the license is still valid. This also provides a way to blacklist or revoke licenses from our end.

I know hard coding credentials is a bad idea, which is why I plan on making this REST "validation" step be unauthenticated. When it comes to the URL I am trying to figure out how to make it flexible while not giving users access to it.

If I put the URL in an properties file somewhere, if a user can manipulate the file they could find a way to bypass/hijack this daily license health check. But by locking in the URL it makes it harder to change (requires code pushes to client to update a URL), which also seems like a bad idea.

Is there a method or patterns that I can use to allow a URL like this to be flexible, easy to change, yet still secure and locked to where only my team can edit it if URLs change? This same question could be applited for any property that could change but needs to still have some sort of lockdown applied to prevent user tampering.

Walls
  • 3,972
  • 6
  • 37
  • 52
  • I'm not really sure why they would change the URL in the properties file. That would disable their application - since they would not be able to access your server for verification of their license. Also, maybe have a central URL which is first contacted by all users applications which will then provide a new dynamically changing validation servers URL, maybe? – jiveturkey Apr 27 '17 at 14:12
  • @jnbbender my worry was them figuring out some way to create a quick app that mimics ours, being able to point the URL to that server to spoof validation. Another worry is clients that are offline (IE secure government) who really dont have access out at all. – Walls Apr 27 '17 at 14:14
  • Offline clients change the paradigm entirely. – jiveturkey Apr 27 '17 at 14:17
  • @jnbbender yes I know, which is another whole issue I have to figure out ;) – Walls Apr 27 '17 at 14:17
  • @jnbbender the central server that provides a dynamic url seems ok, but just makes me think it loops the issue of what if we need to change the url of the central server providing the url? I may be over complicating it, and adding too many hooks in to prevent things that will likely never occur. – Walls Apr 27 '17 at 14:24
  • 1
    Use Java's KeyPair facilities. Have the user send you some machine specific info, generate a public/private key on your side with a specific seed, send them the public(?) key and have all your apps verify the same seed. That may be convoluted too. Hey man I'm thinking! – jiveturkey Apr 27 '17 at 14:27

1 Answers1

1

I can think of various ways:

  • Store the plain URL and a hash (with a secret salt) so you know when someone tampered with the URL.

  • Store an encrypted version of the URL

But I think more important would be the protocol you use for the licensing. No matter where the URL is pointing, you still can divert requests by adding a hosts entry, so I think more has to be done.

Axel
  • 13,939
  • 5
  • 50
  • 79
  • Wouldn't a "secret" hash and salt still be hardcoded to a degree into the code? Also if a URL going to a service is easy to divert anyway (via the hosts you mention) can you think of a more secure and efficient way to handle that back and forth between client and licensing server? – Walls Apr 27 '17 at 14:16
  • Every measure can be circumvented. It depends on the resources put into the effort. The question is how much are you (or your company) willing to invest. IMHO it is also important to think about the consequences for the user of your software who has paid for a license. Many might not be pleased to know that your software "phones home" every time you start it. Also, is it acceptable for your customers if the software does not work in case internet connectivity is lost? It may be difficult to find the right compromise between protecting your rights and not scaring away potential customers. – Axel Apr 28 '17 at 08:17