What I am doing?
- I am building an application where users signIn with Google in order to use my App.
- Since Server has no idea is request is coming from a device, a trust mechanism is needed in order to handshake.
- I created pair (private key, public key) using RSA algorithm. The intent is that public key will be staying on device(with application).
- Once user signs in, application encrypts user information with public key and sends to server using REST API. The server validates and inturn returns a token, that client(iPhone app) can reuse to communicate further with server.
Question
- Since I am new to developing iOS(or any mobile) application, I wanted to know where this public key will be stored in my iOS application
Related
I'm building an Electron application that uses Google's YouTube Data API v3.
For accessing the API, I decided to use the standard API key (instead of OAuth, since I am not going to be accessing any personal data).
But the problem is, I cannot hide the API key in my app, and I also cannot use referrer restrictions (referrer restrictions allow you to filter which web sites can use your API key (by HTTP address)), since this is an Electron app. So basically, if someone looks at the source code (or even just at the developer tools), they can see the key, and use it freely.
Any advice on what to do? Thanks.
The only way to secure your API key for an application that does not require users to register or log in, is to place it behind a server proxy. So, when they start the app, the app reaches out to your server, the server then returns the API key so it only resides in the app in dynamic form, it is never visible to users.
However, this is still insecure if they use a packet sniffer or local proxy they can grab your token.
The most secure way to do this is to make all your API requests from a private server that your app has access to. So, the app makes no requests to Youtube, it only gets the data from your server.
Then, you can secure your app by signing API requests to your private server with a private key. For example, you could have a config file in the app with a private key that is sent in the header of every API request. Then, they only way to get your key would be to decompile your app, and then access that config file, then make API requests to your private server using the same private information. Then, to prevent malicious users, you can monitor traffic and set up request limits, like 1 request per second per app. Any app exceeding that limit could be black-listed as a DDOS attack or a malicious user.
The data flow would look something like this.
App -> Server (with Api Key) -> youtube (data) -> Server (data) -> App
I have an iPhone app that uses a Rails server HTTP API. The API is public at this point - no authorisation is required to get the data.
Currently anyone can go to API's URL and download the data.
http://server.com/mydata
The data is not very sensitive. But I still want to prevent people from easily getting it. What are the ways of doing that? I do not want iOS app users to log in either.
Current solution I have
iPhone app adds a secret token to the HTTP header or query of the request. The data goes over HTTPS.
https://server.com/mydata?secret=my_secret
Is there a better approach?
You could try an approach where the client is only allowed X number of requests per time period (based on IP address or username)
HTTPS is extremely easy to man in the middle on a device you control. You can do SSL cert validation, but there is always someone out there with more time, so best off to handle it server side.
Distribute and use your own SSL certificate.
Apps that transfer sensitive customer data, like credit card and payment information, must be protected from man-in-the middle attacks. The best protection is a mutual authentication scheme, where certificates are exchanged to make sure the app is connected to a trusted server and to make sure the server is connected to a trusted app.
Then only individuals (who have presumably installed your application) have access. If someone digs through the code and gets the public certificate then they can impersonate the client; but at that point they win anyway and two-factor authentication should be explored.
I want to create a iOS app, and I am starting to design a api using node.js+mongodb+express. I know people can use charles to set up a proxy and when user open the app in the iphone device, they can see the api requests in charles app. So people can use this api to do some harm to the app services or what. I want to secure my api. I won't open my api to others. So, I don't need oauth. What else I can do to secure my api? And if any tutorial is provided, that will be good.
Do it with https, just make sure your app stops working if the certificate is invalid.
Alternative:
Crypt/decrypt your http(s)-body before sending/after receiving with a global password (not recommended) or a public key on your phone and a private key on your application.
If someone gets that pw or public key, they can still manipulate the API.
What you want to do is use https with additional security.
First: In the app "pin" the server certificate, that is validate the server certificate in the app, this is quite common these days. AFNetworking supports this.
Second: Add a certificate to the app and verify it on the server. Now the server knows it is communication with your app.
Now both the server and app have assurance they are communication with authenticated end points.
I am creating an API that will only be used by specific devices. I'd like to authenticate using a public and private key pair, similarly to the way that github authenticates using SSH.
The scheme I think would work is as follows:
The device will request authorization with it's ID.
The server finds the public key of the device by the provided ID and encrypts a random string. The string is sent to the device.
The device receives the encrypted string and decrypts it with its private key, sending the result back to the server.
The server checks the string to make sure it matches and sets the correct session variables for the device if the check was correct.
All of this is over an SSL connection, so step 3 can't be snooped and used to authenticate again. Some devices will not need this type of authorization, so the SSL connection can't just verify that the public key of the device was generated by the server's certificate authority and close the connection if it was not.
First of all, does this make sense, or is there a better way? And second - is there some gem that already does this in rails? It seems like this would be a somewhat common method of doing things.
I'm planning to use Facebook as the only sign-on mechanism for an application that I'm building and need some feedback on the design. Here it goes -
User opens the app and is presented with a register screen. The facebook authorization flow starts and let's assume it succeeded and the user has successfully registered himself. Upon success, the app calls the Facebook graph API and gets the user's firstname, lastname, email, date of birth etc. With this data, the app then calls a web service method called RegisterUser(string Fullname, string FirstName, string LastName ...) which creates the user record in the database.
Now for subsequent calls to the API, I need to authenticate that the request is really coming in from my application (not necessarily a particular user). I've looked up the S3 REST API and it seems that with every request there's a HTTP header called Authorization that the client creates by appending a bunch of other HTTP Headers like Date, Method, Request data, signing it with the client's private key and computing its base64 encoded value. This is verified on the server side to authenticate the client.
Now, I'm comfortable implementing all this, but a few questions:
If I have a private key, is it safe to include it as a part of the iOS application itself? Can someone extract the key from the iOS application binary? If so, how do I deal with this?
Are there any other changes you'd make to this design ?
Thanks,
Teja.
Make sure you apply a one-way hashing algorithm to the value to base64 encode - base64 is a two-way encoding, so you don't want eavesdroppers reverse engineering your private key from that. Amazon S3 does this with performing a SHA-1 before doing the base64.
As with all (AFAIK?) compiled binaries, your app shouldn't be able to be decompiled.