-1

I have a desktop application which creates and stores a fair amount of data (mostly on its own, not through traditional user input); mostly statistical in nature.

Currently the data is mostly accessible only to other applications that I've written myself, and isn't exposed to the user other than through these applications.

I'm considering allowing third-party access to this data via a REST API or similar, but in this case the "server" would actually be running on the same machine as the client (or another machine in the same LAN, at most).

However since this access is intended to be monetised I want to have some kind of authentication to allow specific clients access to specific subsets of the data, rather than providing blanket permissions.

(So the goal is not user authentication, but client app authentication; in the human sense all the data is for one user, but should only be accessible through authorised apps.)

Obviously since everything is running client-side I've basically already lost (a sufficiently determined user wouldn't have any trouble extracting and spoofing credentials, and AFAIK it is literally impossible to prevent this) -- but what would be the best practices for providing a reasonable level of security against insufficiently determined users?

Most of the usual recommendations for REST API authentication (SSL, OAuth, etc) don't really seem applicable since they assume a separate and secure server. (And SSL is mostly concerned with validating the server.)

Improve this question
2
  • I think your best bet is to rely on the OS file permisions to prevent unprivileged users from accessing the data Commented Jul 17, 2017 at 0:36
  • I think you've made some unwarranted assumptions. It's not "literally impossible" to prevent an unauthorized user from accessing a REST API, but security is a tradeoff between effort and safety. You need to be more specific about what your "reasonable level of security" is and your "insufficiently determined user". FWIW, some alternatives are discussed here: stackoverflow.com/questions/10161266/… Commented Jul 17, 2017 at 1:53

1 Answer 1

Reset to default
1

You can utilize client certificates that are generated from an external source.

When a third party service is being setup, one of the steps should be contacting an authoritative server to see what permissions it should have and if the user has paid for the content feed. In that step you can also generate a client ssl certificate and sign it with an internal certificate authority. Then when a third party client connects to the API on the desktop, all it needs to do is present its certificate and the API can check the signing authorities hash to verify its authenticity and grant the permissions stated.

The function that verifies the certificate should be as close to native code as possible, as it's trivial to edit an interpreted file to always return true for a certificate check.

Improve this answer
2
  • It's trivial to copy that certificate to another client, though, and then they both have the same permissions. Commented Jul 20, 2017 at 1:34
  • @Mirai Yes, but then to counter that you can generate a thumbprint of the system you're on and include it in the certificate. Options include locating the MotherBoard serial number, the CPU serial. Just include that data in the certificate and verify it on request. Commented Jul 20, 2017 at 5:28

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.