Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am building a web service that has to be only accessible for iOS apps. In the future I want to expand to a mobile website to make my service also available for other mobile operating systems.

Now, I have everything working through an API. my users can register, search companies, order products from those companies and track their orders. It's not active yet, but it's working..

I am facing one major problem: How to secure this?

For the last few days I have stopped coding and I have constantly been busy with searching the web, StackOverflow and Information Security for how to do this. I have found that the way amazon secures their API would be the best solution for me. The way amazon secures it's service is explant here. I have tweaked it a little bit for my service:

  1. User registers and gets private API key + public (identification) key
  2. User enters credentials and taps "log in". App creates hash out of the variables + private key. App sends variables + time stamp + hash + public key to API
  3. API looks up public key in database, finds private key belonging to that public key (if public key is valid). The API then creates hash the same way as the app did. If the hashes are the same, the request (log in in this case) is executed.

This way of securing a service makes sense to me, and I can code most of it. but I have a major problem and I can not find any solution to it:

  • The user gets a public & private API key when an account is created. The public key can be send from the server to the user device, because that is not necessarily a secret. Since the private API key can never be sent over the wire, how on earth can I make sure that an account logged in on a user's device knows the private API key that is created on the server?

Does anybody know how to solve this problem?? any help would be highly appreciated!!

share|improve this question
Not sure if this is what you're looking for...but maybe you might want to use HTTPS to prevent eavesdroppers from intercepting your key. Certificate Pinning is the best way to do this and here is an example program that does it. . Also...Your architecture sounds extremely confusing to me...There are far simpler authentication scheme to use – Rell3oT Dec 9 '13 at 14:28

Why do you want the clients to have their own private keys? I'm trying to understand how your scenario is supposed to work but am a bit confused about what you're trying to achieve.

In general here are a couple of comments that may help:

  1. HTTPS is how you can establish a secure communication channel with clients. Once you do this you can transfer whatever you want securely over the wire client <-> server. This is the same thing your bank does.

  2. Article you link to doesn't say anything about HTTPS, looks like they're intending to send that over just HTTP. You should use HTTPS not HTTP for anything you wouldn't want compromised (such as a logged in user). Why try to build your own encryption mechanism when you can use HTTPS? Using HTTP for any kind of authentication sounds like terrible advice to me.

  3. I'm not sure that your clients really need their own public/private key pair. Typically it's a server that's securing your application communication and that has a certificate with private key. Clients will still have a user name and password right? That's the authentication for your client (not a certificate) and you can send the user/pass to the server once you have a secure HTTPS channel established. Server side your app will verify the client login credentials are valid and give the client a way to say "I'm already authenticated for 30 minutes" via a cookie or session mechanism. Obviously once a client is logged in, communication needs to continue to happen over HTTPS or your authentication token/session could get stolen.

Bottom line, if you're just trying to secure communication between clients and a server then use HTTPS and don't re-invent the wheel.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.