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.
Related
I am building an ios app that communicates with the server for getting the data.
If its just a normal app, I can send csrf token via forms (since all from same domain). But, for ios apps, I dont think I can set csrf token .
So, when making requests from ios apps, to the server, I am getting error regarding csrf. So, whats the solution for this? Disabling this csrf feature or some other better way ? This is my first ios app, so please tell me a better way so i will follow that.
For those URLs ("API end points") that your iOS app is accessing, you will need to specify #csrf_exempt on the corresponding view functions to disable csrf protection.
More details here - https://docs.djangoproject.com/en/dev/ref/contrib/csrf/#django.views.decorators.csrf.csrf_exempt
And protect those urls via other authentication methods, such as session authentication.
For your authentication purposes, you can easily take reference to what django rest framework and django tastypie has done. Both use SessionAuthentication classes to handle authentication and protect the exposed urls (API endpoints) that your iOS app can connect to.
References:-
http://django-rest-framework.org/api-guide/authentication.html
https://django-tastypie.readthedocs.org/en/latest/authentication_authorization.html
Django tastypie also has an authorization class, which is not to be confused with authentication. It also has an APIKey authorization class which becomes useful when you do want to expose your django URLs to other 3rd party developers who may want to build an app of their own to talk to your django URLs to access data (think "facebook APIs"). Each 3rd party developer can in essence be provided a unique API and because you have the APIKeyAuthorization class and a unique API Key provided to each 3rd party app, you can be sure that only "authorized" apps can consume your django URLs. This is the essence of how various big platforms like "Google+" or "Facebook" etc work.
Details of how django's csrf works
https://docs.djangoproject.com/en/dev/ref/contrib/csrf/#how-it-works
The CSRF protection is based on the following things:
A CSRF cookie that is set to a random value (a session independent
nonce, as it is called), which other sites will not have access to.
This cookie is set by CsrfViewMiddleware. It is meant to be permanent,
but since there is no way to set a cookie that never expires, it is
sent with every response that has called
django.middleware.csrf.get_token() (the function used internally to
retrieve the CSRF token).
A hidden form field with the name ‘csrfmiddlewaretoken’ present in all
outgoing POST forms. The value of this field is the value of the CSRF
cookie.
This part is done by the template tag.
For all incoming requests that are not using HTTP GET, HEAD, OPTIONS
or TRACE, a CSRF cookie must be present, and the ‘csrfmiddlewaretoken’
field must be present and correct. If it isn’t, the user will get a
403 error.
This check is done by CsrfViewMiddleware.
In addition, for HTTPS requests, strict referer checking is done by
CsrfViewMiddleware. This is necessary to address a Man-In-The-Middle
attack that is possible under HTTPS when using a session independent
nonce, due to the fact that HTTP ‘Set-Cookie’ headers are
(unfortunately) accepted by clients that are talking to a site under
HTTPS. (Referer checking is not done for HTTP requests because the
presence of the Referer header is not reliable enough under HTTP.)
This ensures that only forms that have originated from your Web site
can be used to POST data back.
I want to create a Rails application which exposes an API to be consumed by only authorised client applications (will be mobile apps for iOS / android). I've not started working on the app yet, but the primary method of accessing the underlying data will be through the api. I've been looking at using the grape gem, but would need to add an authentication layer to it. I was thinking about using devise and adding another model for storing client details, api key and secret key. Upon sign in through the api, the api key and secret are returned. The API key is transmitted with each request, but the secret key is not. Instead, it is used to sign each request; the request parameters are ordered by name, hashed using the secret key as the hash key. This signature is then added as a parameter to the request.
Does this system of authentication sound logical and secure?
I tried to prototype the system earlier, but ran into difficulty signing up a user using JSON with devise. At first I was getting a CSRF error. I then turned off protect_from_forgery and was getting another error. Is it safe to turn this off if I am authenticating in this way?
Yes you can turn off rails CSRF protection since you are using a different authenticity method as long as a date or timestamp is always inside the parameters that are being signed. You can use this to compare the request time to the server time and make sure you aren't undergoing a replay attack.
protect_from_forgery helps you protect your HTML forms. If you're consuming JSON from mobile clients, you don't need it.
Here's what I would do if I were you:
on user's account page, have a button that says "(re)generate API key"
client then embeds this key into his calling code and passes with each request.
your API server checks whether this API key can be used with this client id.
Very easy to implement and serves well.
Signing parameters also works and I used it in several projects with success. But it increases code complexity without any real gain (secret key is on the client, attacker already knows it).
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.
I'm using Flex 4(beta2) with Ruby on Rails 2.3.5 and using RubyAMF to transfer data back and forth between Flex and server.
I set up Authlogic on the Rails side for authentication.
I wasn't sure what's the best method to handle user sessions. I know this is done automatically with Rails by sending session id with cookie which Rails use to authenticate the user.
What do you suggest the best way to do this with Flex?
I thought of couple of options:
1. Manually fetching the cookie from the browser and then figuring our a way to send that to the server with every request I send.
2. Handling sessions expiration and flow on Flex side by manually expiring the session
Do you have other suggestion or recommendation?
Thanks,
Tam
Network requests in Flash use the browser networking stack so cookies in Flex work just like any other browser application. Usually authentication in Flex is no different than it is with a standard web application. Send credentials to the server which it correlates with a session id. Every subsequent request (RemoteObject, HTTPService, etc) also sends that session id.
We have seen that the flash plug-in propagates the session cookie when we do blazeDS (http) remote calls
In the past we have worked with BlaseDS and HTTPServices. In both the cases the request is sent to the server over HTTP. Our server stack as Java (JBoss to be specific).
We noticed that the flex client used to send the session information with the requests to the server. We used same information to store and fetch Principal on the server.
In one case, we propagated the token to the client. This was to avoid multiple submits for same requests - hence we used the common HTML submission approach of token generation where with every response carries with itself a new token and the client has to sent it back to the server for executing the next request.
For the session expiration, there is a good chance that a user is working on the client for any local needs and not working with the server which may have caused a expiration on the server without impacting the server. In this case, we disabled the session expiration on the server and wrote custom code to handle events - keyboard and mouse on the flex client. If the application was not used for a specified time, the flex client would expire both the sessions i.e. local and server
What do you suggest the best way to do this with Flex?
$loggedIn=Authenticate::isAuthenticated();
if(!$loggedIn)return false;
$user=Authenticate::getAuthUser();
First Authenticate the user and if he is logged in create the session. Include this in your every PHP or Ruby file, and check it. Send the Session ID to Flex to maintain the state and you set the time for your session to expire.
The above code does check, whether the user is authenticate to access the PHP or ruby class files.
I have a server side app written in Rails using the authlogic plugin. I am not sure how to login to the rails app from my iphone client. I think I know how to write get/post code in Obj C, but I'm not sure what the best approach is of authenticating with my rails server. Here is what the server side HTML looks like when you go to this URL:http://localhost:3000/user_sessions/new : http://pastie.org/596279
To authenticate from your iPhone app you will need to:
Disable cross site request forgery for the form actions
HTTP POST user_session[username] and user_session[password] to your FQDN + '/user_sessions'
Capture the session cookies returned from the site (and return these with subsequent requests) to take further actions in the application.
Depending on what your overall goal is, it might be better to write a custom authentication piece that would use the iPhone's internal ID and a combination of the username and password to create unique token to use for the session on the site.