2

I need to hide a password to connect with a server. The problem is that the password is given by the service providers, so it is static.

I already thought of using the keychain, but the problem is that even if I use this I need to hard code the password to insert it in the keychain somewhere in the code.

So, is there a way to hide a static password to be available for my app, avoiding to write it in my code?

RK-
  • 12,099
  • 23
  • 89
  • 155
user2115866
  • 33
  • 2
  • You probably want something more complex than that, because someone can put a proxy between your app and the server, getting the password that's on the HTTP request. – Marcelo Apr 10 '13 at 14:40
  • See [this answer](http://stackoverflow.com/questions/10292175/should-i-store-an-encription-key-as-hardcoded-in-my-ios-or-android-app) – progrmr Apr 10 '13 at 14:41
  • 1
    There are a number of ways to do this -- all of them, of course, poor from a security standpoint, since they all involve "security by obscurity". Generally you store the code in small sections here and there and then mash them together with some obscurely-named method like "logEspressionSyntaxError" (which in turn cascades to 2-3 other obscure methods). – Hot Licks Apr 10 '13 at 14:51
  • @MarceloFabri - The protocol can encrypt the password. Presumably the service provider has defined the protocol to do that. – Hot Licks Apr 10 '13 at 14:53
  • And of course be sure to not call your "obscured" password function directly from the code that wants the password, but use a circuitous route, where the password is extracted in some "unrelated" code and cached in some "non-obvious" place for the actual password consumer to grab. – Hot Licks Apr 10 '13 at 14:56
  • I am using https so I think that I can discard the man in the middle problem. Thank you all, I am going to use "security by obscurity" – user2115866 Apr 10 '13 at 15:05
  • It should be noted that this scheme is rather insecure (not only cryptographically) since once the password is cracked for a single user it's cracked for all users. This is a bad corner the service provider has backed you (and himself) into. – Hot Licks Apr 10 '13 at 15:07

3 Answers3

1

I would think about setting up a middle layer server - kind of a proxy - between users of your app and the service provider. It will allow you to:

  • set different password for each user
  • optionally give users a chance to change a password
  • have more control over who uses the service and what data is transmitted
  • be more independent of your service provider (e.g. change it anytime)

It will require more effort but may be it is more advantageous in long run.

Mike
  • 1,332
  • 2
  • 10
  • 14
  • It would be more practical to get the service provider to come up with a better password scheme. – Hot Licks Apr 10 '13 at 15:05
  • I disagree; the proxy layer provides many benefits and gives you control over the interaction. It's my recommended solution. Asking the service provider to do it means that every user must have a way to authenticate against the service provider as well as against you, which is a difficult problem to scale. You wind up needing things like OAuth or Kerberos, which are more complicated than just a proxy IMO. – Rob Napier Apr 10 '13 at 15:19
1

This is not a solvable problem, and has been discussed at length around SO. For one "hub" question that includes links to several others, see Secure https encryption for iPhone app to webpage.

Using obscurity is not a horrible thing. But keep it simple. XOR the value with some random key. Done. Putting more and more layers buy you nothing, and cost you complexity (which means time and bugs, which are the enemies of both profit and security). If someone puts a debugger on your code, they're just going to log all the data you send to the server, so all the hoops you jump through to hide how you compute the password won't matter, because eventually you have to send it to the server. So keep it simple to stop people from just using "strings" to pull it out, and recognize that you cannot stop a debugger.

The only way to secure the service-provider's key is to put that key on your server, and then proxy for the service after authenticating the user. If you put it in the code, then it is discoverable, period. If this were a solvable problem, there would be no unlicensed copies of software, no unlicensed copies of music, no jailbreaks for iPhones, etc etc etc. If Apple can't stop reverse engineering when controlling every piece of the system from the hardware to the OS, you're not going to fix it inside of an app.

What you should be thinking about is how to recover if and when the key is lost. How do you discover that it's happened? How do you expire that key and create a new one? If you're shipping the key in the code, you must assume that it eventually will be discovered, and you should have a plan for dealing with it.

As a side note, one technique I've used in the past is to download the key from our server on-demand rather than encoding it anywhere in the app. We use authenticated HTTPS and check our certificates. Of course it is still possible to fool this system (it's always possible to fool a system that gives a client information they're only supposed to use a certain way), but the thinking is at least we can change the key more easily this way to stem the tide briefly if the key leaks.

Community
  • 1
  • 1
Rob Napier
  • 286,113
  • 34
  • 456
  • 610
0

This is the key and the box problem, you can keep putting your key in a new box every time and hide this key in a new box and you can keep on doing this.... but in the end you always have the last key... and nowhere to hide it.

Personally i would obfuscate the key to the keychain, and hide the real key in the keychain. If it is a realy important secret you can use AES to encrypt your key, but then again your stuck with your encryption key, here you can use something that is device specific instead of a hardcoded value and generate your key out of that property.

For sure not perfect but will do the job in most cases.

Frank
  • 16,476
  • 7
  • 38
  • 51
  • 1
    His problem is that he must embed a hard-coded key in his code, to be present when the app is installed. – Hot Licks Apr 10 '13 at 15:04