0

I am currently working on a project where I am developing a library which will do HTTP POSTs to a backend service on my server. The data that the backend service receives is processed and stored in a database and allows the user using the library to see the data.

I want to ensure that the backend service only processes requests from the library, if anything else tries, such as bots etc, the request is rejected.

I was thinking I could achieve this by the library sending an encrypted string in a header in the HTTP request, then when the backend services receives the request, it checks if the header exists and if not rejects the request, if it does, it decrypts the header and then checks if the decrypted string matches what the backend service expected, if so, continues processing, otherwise rejects it.

I was thinking that the library could have the validation token hard coded in the library (the library won't be open sourced) however, I was thinking that this could be problematic if the validation token ever gets compromised, I would need to release a new library version with the new token, and anyone using the library, would then need to update their apps to use the new library.

I was then thinkin the token could be stored on the server and the library requests what the token is and then sends the token to the backend service, but I then have the same problem I'm trying to avoid, how do I make sure only the library retrieves the token and not anyone else.

Is there a recommended best practice for doing what I am trying to achieve.

Thanks for any help you can provide.

Improve this question
1
  • 1
    This is typically what client tokens are used for. Your encrypted string could also count as a client token when you use it in the HTTP authorization headers. Commented Sep 30, 2017 at 14:06

2 Answers 2

Reset to default
2

You can't do this, not in any way that provides security. If someone has your client library, they have the encrypted key. Anyone that wants to spend time and extract the key from your library, and then make calls to your service.

The normal approach is to allow users of your library to create an account on your system, and then issue them a token. The token is authenticated on each call to your service. If you want to stop someone from calling your service, you can deauthorize the token and maybe their entire account. This is what OAuth2 authentication is about, so you don't even need to create your own scheme.

There's nothing technologically you could do however which would prevent people from creating their own client to your service. If they can call it with your client library they can reverse engineer it and create their own.

Improve this answer
1

As noted this is impossible. However there are a number of steps you can take to approach a solution.

  1. Force individual users to login and rate limit or charge them for the use of the service.

  2. Frequently update the protocol and client. forcing hackers to gave to continually redo their hacks.

  3. Use hardware cryptographic dongles which require manual input. To prevent automation.

  4. Attempt to verify the client through secret rarely used messages and degrade rather than completely stop invalid clients. Making it harder for hackers to debug/test/verify thier hacked client.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.