authenticating an app

Discussion in 'iOS Programming' started by kas1234567, Aug 26, 2008.

  1. macrumors newbie

    Joined:
    Aug 26, 2008
    #1
    hi,
    i want to create application that connects to a web server but the webserver needs to be absolutely positive the request was initiated by my app and not someone else impersonating my app.

    i figure including a static key hard coded in my code is bad, since apples fair-play has been hacked.

    is there any way to do this? any help would be appreciated.

    thanks
     
  2. macrumors 68040

    Joined:
    Apr 22, 2005
    #2
    It could work like this:

    1. Your app tells the web server it wants to connect.
    2. The web server generates some random string and sends it to the app.
    3. The app manipulates the string in a non-obvious way to generate a new string and sends it back to the server.
    4. The server checks to make sure that the new string is the correct mutation of the original string and if so allows the connection to proceed.

    This isn't totally hack proof but I think it should be good enough.
     
  3. macrumors member

    Joined:
    Apr 10, 2008
    #3
    can't you check the header of the web request to see if there is any iphone specific information in it?

    i am sure there must be some information there..
     
  4. macrumors 68040

    Joined:
    Apr 22, 2005
    #4
    He could send all kinds of info about the phone to the server, but that doesn't prove to the server that his app is sending it.
     
  5. thread starter macrumors newbie

    Joined:
    Aug 26, 2008
    #5
    Thanks for the advice. This is what I though of when I mentioned hard-coding a key into my code, but like you said it isnt hack proof. If someone disassembles my code, or i make my code public, then its pretty much useless. The only plausible way I can think of doing this is somehow getting the Iphone OS to "certify" my request. Is this possible? In fact, is solving my problem possible?

    Thanks again for the proposed solutions.
     
  6. macrumors 68040

    Joined:
    Apr 22, 2005
    #6
    I could be wrong, but I think my solution is basically as good as it gets. Note that it doesn't require hard-coding a key into your code, but in some sense the app's code (i.e. the algorithm you use to manipulate the string you get from the server) is the key. So yes if someone is able to disassemble your code they can potentially break your security, but it isn't as simple as just finding a string (the key) in your binary. I don't think that there are any methods that will be immune to code disassembly.
     
  7. Moderator emeritus

    robbieduncan

    Joined:
    Jul 24, 2002
    Location:
    London
    #7
    You solution is exactly the same as a hard coded key: the data is static over time and can be intercepted on the wire and then impersonated.
     
  8. macrumors member

    Joined:
    Jul 28, 2008
    #8
    Hi,

    I think this is called challenge-response authentication, its point is to prevent someone from getting the password by eavesdropping. You can achieve the same thing by using HTTPS, which is probably much easier to implement.

    No, you could make the code public, minus the password that is known only to your app and your server.

    True. You can try to obfuscate the password to make things very hard, but it is still theoretically possible to get it.

    Certify what ? To the best of my knowledge (which is very shallow I admit :p), use of certificates at some point requires a private key.

    So no, I don't think your problem has a 100% secure solution. I don't know however how hard it is to disassemble an iPhone app. That is an interesting question :)
     
  9. macrumors 68040

    Joined:
    Apr 22, 2005
    #9
    It's not exactly the same. With a hard coded key inside the app, a hacker just needs to figure out the key and then they can open an unlimited number of connections to the server. With a challenge-response scheme, they would need to eavesdrop and impersonate the client each time they wanted a new connection (or do a man-in-the-middle attack). With proper encryption added to the client and server, this method is secure.
     

Share This Page