1

I want to build a client that connects to my server and uses server API. You can consider this as a banking application because data security is the most important thing. Since the users or hackers going to try breach software security to get into flow and see what is going on, we need to protect everything from user too. Simply, I want to take precautions against this (but not limited) situations:

  1. Reverse engineering attacks: No one must see my source code. If someone see it they can understand the algorithm and learn how API is working. Since the API is not a public one, it must never happen. Is obfuscating an irreversible process and best way to hide real source code? Also how can I secure my variables that can be dumped from memory at the runtime? What is the best way to secure local configuration or created files under Windows?

  2. Pirate clients: How can I prevent other softwares from using my API? If someone gets the source code, alter it anyway or create theirs this will be uncomfortable situation. Is there a way to limit access of service to my own original, not modified clients? (Hash control? Client certificates? Assembly signature maybe?)

  3. Data channel & data security: Software should be able to run in every network that connects to Internet, so it seems I have to use web requests & responses to communicate clients with server. I think data channel can be secured with https easily. Should I prefer a paid certificate (like Verisign) or creating my own certificate (signed by me) is enough? I want to secure the data itself too, I think a public & private key pair for each client will be enough for both identify and communication. Is it a good approach? I'm also thinking connecting that clients with a HTTP Proxy, can it increase security?

I know my software is working on enemy soil that I mustn't trust and there is nothing an user can't do with it. But I want to secure this as much as I can. No one can make it fully secure but I want to do everything I can to increase it.

Batuhan
  • 672
  • 4
  • 17
  • If there's an algorithm to protect then make it run on your servers. As for the API access there is nothing you can do, not that you should do anything - if the user wants to do bad stuff with their account, then what's the big deal ? It's *their* account (and their money, if we're talking about a bank) after all. Same goes for "pirate"/third party clients. About the data security part, the actual certificate doesn't change anything about security, so assuming your app correctly verifies the certificate before transmitting sensitive data, you're safe with using a self signed cert. –  Mar 05 '15 at 02:28

1 Answers1

3

All your client side security efforts are doomed to failure.

Obfuscation and hiding your source just isn't going to work. The more valuable the data you are working with the sooner your code is going to be reverse engineered. The only logical approach to consider everything client side public.

Your approach should be to focus your security on server the server side, generate an authorization keypair for each client, and monitor for abuse and revoke keys in these cases. Just like Amazon AWS.

  • HMAC for authorization and TLS for transport encryption.

  • It doesn't matter whether you generate your own cert (you may trust yourself more than verisign) as long as you tell each client to trust it.

  • Adding a proxy will not increase security, using TLS will.

  • If it makes sense for the application add a password to encrypt the HMAC key and the client side data, to make it a bit more secure.
  • On the detection side consider automated ways to detect abuse. How many queries is too much? Maybe throw some juicy honeypot API endpoints in the client source code. When an attacker connects to /payments/swissbank/million then you know the key has been compromised and should be revoked. Whatever else is outside normal behavior, including validation fails.
Antonius Bloch
  • 507
  • 2
  • 9
  • TLS won't do much against a malicious client unless the operating systems keystore is not used. since there is little that one can do to prevent a HTTP proxy from sniffing, decoding, re-coding with a SSL key generated by a hand-made CA and then re-transmitting back to the application. – Damian Nikodem Mar 19 '15 at 12:06
  • Right, TLS is for transport encryption. Using HMAC for authentication will prevent the man in the middle attack you describe. – Antonius Bloch Mar 23 '15 at 22:03