Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Securing MY REST API for use with MY IOS APP only

I am designing a REST API in Laravel to be used with my ios app. Currently I am stuck on the following point: How to secure my REST API to allow access to ONLY my ios app?

I have read about HTTP Basic Authentication, HMAC, oAuth2.

1) Basic authentication requires SSL and it requires you to send the username:password on every api call.

  • But this doesn't stop others from using the API from other applications assuming they post their login credentials to the endpoints?

2) I understand the HMAC method and how the client & server both know of a Public & Private key. The private key is encrypted along with the request and other data. The public key is sent in the headers. When the server receives the request it detects the public key in the headers and associates it with a private key in the DB. It then recalculates the hash and checks if it matches. So, I have the following questions:

  • How does a newly registered user get the private key to be stored in the IOS app if the private key is not to be sent over the wire?
  • Is this more geared towards applications that will utilize your app? I normally see this in a API dashboard like Instagram & Facebook where they give you an app secret key, right?

3) oAuth2 - To me this seems more like allowing people to login to my app utilizing another API. For ex, allowing users to login to my app with FB and allowing my API to utilize Facebooks data? I am not really needing to do this at the moment.

  • am I misunderstanding this?

It sort of sounds like I need to incorporate something similar to the HMAC method by granting my IOS APP a private key where I store this in my IOS APP code. When a request is ran from within the ios app i pass along a hash with the private key and other data and then when the request is received on the server I detect if the request came from a user within the app by recalculating the hash. I have no idea if this is secure & I would assume it isn't?

What knowledge am I lacking? I am so confused at the moment that writing this question was a big struggle. I will revise it as soon as things become more clear.

like image 957
Alex Lacayo Avatar asked Oct 21 '14 10:10

Alex Lacayo


1 Answers

1. You're right, this doesn't prevent non-approved clients.

2. This isn't really a way to prevent unapproved clients, it's more about verifying that a message isn't tampered with over the wire.

3. You're understanding oAuth correctly, it's about authenticating clients to use your API in a specific way as well as limiting permissions.

It's not really possible to lock down your API so only a specific client can use it, because there's no way to verify who the client really is. Additionally, any form of authentication or verification done on the client side can eventually be be reverse engineered, and then can be sent to the server as an 'approved' client.

Something like this could be done with a token. The server sends a token the the client, the client performs some known operation on the token, such as salting and hashing, with a known salt and hash operation, then returning the token to prove that the client is a real one.

The problem is, if someone reverse engineers your client, they can determine what that operation is, and then create their own client which authenticates the same way. Any form of client side authentication isn't true security and can't be trusted.

Another way this is broken, is if someone can MiTM your request. The request could be captured and modified before it reaches the server, and there's not really any ways to prevent that from happening aside from using SSL, which can be broken with something like SSLStrip.

Any attempt to prevent a non-approved client is basically security through obscurity, since there isn't a provably secure way to do what you're asking.

The best way to protect your API isn't by limiting which clients can access it, but by making it secure already. Best practices would include forcing SSL, only send the password once and use tokens for authentication from then on, etc.

like image 103
Adam Avatar answered Oct 03 '22 17:10

Adam