I'm developing iOS app(Swift) using 3rd party(facebook) authentication. I encountered a question which is how I can throw the access token from facebook to my own server.
I've been writing something like below..
Alamofire.request(.POST, "https://example.com/user/fb", access_token: facebook_access_token)
but I'm not sure this is safe enough.
Not only that, when I implement email/password login as well, I've been writing something like below..
var user = [email: "ex#mple.com", pass: "password"]
Alamofire.request(.POST, "https://example.com/user/", user: user)
Are those safe enough? Or if there're best practices please let me know.
Thanks!
Sending your credentials via SSL prevents others from reading the values in the middle. So, it's theoretically secure. ie: It goes through the security provided by the transport layer.
However, it's not the recommended approach to send plaintext passwords to the server. The correct way is to hash the password at each client, then send the hash value to the server. At the server, you should compare whether the hashes match. You might need to do some changes to your server logic. But, in the long run, it should be worth.
I assume you are asking whether its safe to send it over the network. If you are using SSL encrypted URL and pinning the SSL to your app then yes it is. Here is blog post explaining how to do SSL pinning on IOS
https://possiblemobile.com/2013/03/ssl-pinning-for-increased-app-security/
Related
When we configure Server-to-Server Notifications, we Specify our secure server's URL in App Store Connect and the apple server communicates on that URL. but is there a way to authenticate this request?
It is not safe to keep url open without authentication
in case of PlayStore we can use GOOGLE_DEVELOPER_API_KEYFILE_JSON for authentication, but how to do this for iOS server-server notification?
As the comments have already clarified that there is no built in way.
So, here is my work around of this problem.
Apple sends password in the notification which is App secret key which ideal should only be known by API and Apple.
And to verify receipts coming from the App this password must already be stored somewhere (configuration?) in the API.
So I suggest to check whether the password in request matches with the one stored in our API?
If yes then this is a valid request.
If not then it may be sent by a hacker.
My only concern is that does this App shared secret key aka password change? by Apple or developer? If not than this is the solution.
One way to do it is to use Basic auth. As you cannot specify a header you can use the url format: https://username:password#SERVER_ENDPOINT. This will automatically encode the username:password and construct a basic auth header with the encoded string.
Source:
https://en.wikipedia.org/wiki/Basic_access_authentication
I was wondering if there are any advantages/disadvantages in using POST/GET method in Swift 2 to send password and username to the web server in order to authenticate the user. I am working on the iPhone application that fetches data from the web. The request passes the parameters to the URL and server sends data back. I modeled the current application with Enums defining a different endpoints for each request and it would be really easy for me to model Login the same way. However, I am not sure if that is the right direction.
So essentially GET is used to retrieve remote data, and POST is used to add/update remote data.
For security reasons, it does not make any difference. Just be sure that your connection is secured with an https certificate, and do not allow http connections.
I want to ask you, is it safe to save LinkedIn ConsumerKey and ConsumerSecret inside of my code, like constants?
If it's not safe, what is the right way of authentication with LinkedIn?
Even compiled code, it would still be possible to get the key out if someone was determined.
Generally, the user would pass credentials to your server and on your server side you would store the private key, and pass an expiring token back to the user so they can access the service. It looks like LinkedIn can handle the server-side for you, so you can do minimal processing on your server-side.
https://developer.linkedin.com/docs/oauth2
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.
For iOS applications that require push notifications, it must first request the user for permission to do so. After that, a device token is generated and with this, the remote server may communicate to the user through this token.
I have read a similar question here and I do not feel it is enough. The picture below is a trusted certificate, it allows me to view all traffic that happens on this device.
With Fiddler2 as well as CertMaker, I can sniff HTTPS traffic, which means the client can probably know what data they are sending, and to where.
My question is, knowing that SSL is not secure from protecting my clients from seeing what I send to the remote server, should I simply encypt with a secret key found within my application?
Such as encrypt("device_token","secretkey_a0a0a0a") (pretend this is Objective-C)?
Couldn't someone just find that key within my application? I also read this question, and it seems that it would be possible to get back the secret key.
My plan for this goes like this:
Within the iOS application, Generate a random string named activate.
Encrypt (not hash), the token by the random string and a secret key that I only know. (secretkey_a0a0a0)
Send the encrypted string along with the generated randomly generated string (active).
Within serverside, I check if I can decrypt a valid token from using the active and my secret key.
I save the token in my database if it is valid.
This prevents people from random entering tokens yes, however, secretkey_a0a0a0 is a string literal. It's very possible to get this within the application binary itself.
My question is, how do I protect this secret key? The answer can also be, how can I prevent people from sending invalid tokens to my server as well.
I have heard of encryption, but doesn't that only apply to resource files?
How should I approach this?
If you do SSL-Pinning ( AFNetworking has this implemented ) you won't be able to (in a reasonable timeframe) sniff the https traffic between the client and server if you don't have the servers private key.
If your fear is that man in the middle can steal your token and send fake push notifications to users of your application, be sure that this cant happend. Since requests to apple apn servers must be signed with pem file, the main concern should be how to keep certificate file secured, and not apn token. If you want to prevent writing invalid tokens in your database then you should implement some CRC or odd/even bit mechanism.
You might want to check the security section in the Push Notifications Guide, in particular the section titled "Token Generation and Dispersal".
The device token is generated by the device connecting through the Apple's APNS. My guess (they don't say in the docs) is that it's unique for a given app identifier.
The APNS then will probably match those identifiers with the pem certificate you use to communicate with it thus validating that the push notifications are actually originating from your app.
Encrypting the device token seems overkill in this scenario.
To prevent someone maliciously spamming your server with tokens, I would hash the token when a secret key and send both the token and the hash to the server. You can then hash the token again on the server, with your secret key, and check that the request is valid.