We have a large number of websites which need to implement cross domain login, ie. If someone is logged in to site X with the credentials, he should automatically login to the site A or B when the user navigates to site A or B.
Also, we want to give a common UI/Javascript, which all the sites can put on their HTML file, and which will internally call a common API and which will somehow log the user in the site A or B.
Its is similar to what Facebook has. If one logs on to facebook, and goes to a site, he will automatically be logged in, if he has given the permissions for that site.
Also, the same facebook UI is present on every site which has the facebook social plugin, and the site including the facebook plugin does not have to make any call to facebook from its own server(i guess that call is made from the browser).
I saw that a call to facebook includes an API key which is used by that app, but since the API key is visible, it is no longer a secret. How does FB prevent random DOS attacks to its servers by the same API key, and if the user changes his IP address at random?
Lets say we try to implement similar of all the websites A, B which are associated with X, since the API key is exposed(just like in case of FB), how can i stop a different rogue site, say ABC.com from using the same API key, and acting as if it was part of the network.
I guess since the call is from the browser, and from a javascript, the API key is always exposed. Does the call always have to be from the server so that the API key is kept a secret?
In my case, how can the UIs of various networked websites like A, B etc pass something to the server of X, so that the server X can identify that the call is indeed coming from a reliable source and is not impersonated?
Thank you
Tuco
I saw that a call to facebook includes an API key which is used by that app, but since the API key is visible, it is no longer a secret.
No one ever said it was.
How does FB prevent random DOS attacks to its servers by the same API key, and if the user changes his IP address at random?
For certain actions, f.e. login, apps are tied to certain domains set up in the app settings. If my app allows user logins through Facebook from example.com, logins will not work if example.net takes my app id and tries to have users connect to it from their domain.
I guess since the call is from the browser, and from a javascript, the API key is always exposed. Does the call always have to be from the server so that the API key is kept a secret?
Calls using the app secret should always be made server-side only.
In my case, how can the UIs of various networked websites like A, B etc pass something to the server of X, so that the server X can identify that the call is indeed coming from a reliable source and is not impersonated?
The Facebook JS SDK checks for example which domain it is currently running on.
Since that’s client side and could be manipulated, there’s other security measures in place as well. F.e., Facebook will only redirect a client to addresses under a certain domain, and in server-side communication gives you a signed_request which can be verified using your app secret.
Related
We are developing a hybrid mobile application and for certain function calls, there is a url called. Here is a sample request for getting user information
http://someurl.com/1234/account
where: 1234 - is the user id in the database.
We figured that a "man in the middle attack" is possible for this. The url called by the mobile app can be sniffed, then the hacker just changed the value for the user id and with that he can see information for other users. The question is - would simply changing the url called to https solve this security flaw?
No, it will not. You are exposing user data based on an unauthenticated URL and it is trivial for unauthorized parties to access modified URLs even away from the mobile platform.
I want to create a web page, that will serve to authenticate users based on credentials I give them (user1, pswd1 etc).
Only after a user authenticated, he should have access to a few other web sites,
on different folders of the web server, but which have no server side code(otherwise it would be simple.)
The user should be allowed access to the other sites, e.g. based on his IP,
for 24 hours or another period, or while he has the authentication site open on his browser.
The purpose if that the user will not have to enter credentials on each site,
and will enter his credentials only once, or once a day.
Restrictions:
I don't want to modify the target web site javascript code at all, e.g. to query a web service.
The user should be granted access using any browser,
so I assume I cannot use cookies.
If I would develop such a mechanism on Apache,I could, for example, have the authentication site PHP code add a line "Allow from ip" to the htaccess file of each target web folder, whenever a user authenticated successfully.
The issue is that I don't want to develop it as I am sure a solution already exists, and also I need a similar mechanism for both Apache and node.js (although i can live with two different solutions)
What information does the user have to identify themselves? How do you guarantee the user is who they say they are?
The whole point of authentication is to establish the user is who they say they are and that may create a session so that users need not reauthenticate.
If you want the user to authenticate in a single location and then reuse that "session" or set of credentials elsewhere, what you are looking for is single-sign-on / identity federation.
For instance, take airbnb.com. I do not need to authenticate there. All I have to do is authenticate with a third-party e.g. Google or Facebook. As a matter of fact, SO works in the same way.
One of the standards behind this technique is called Open ID Connect. Look into that. If you are willing to dish out money, you can look into commercial solutions e.g. Ping Identity. There is an open source implementation provided by Mitre / the MIT. It's available here.
In fact it occurs to me I can use simple routing.
In the top level folder have php code that does the authentication.
If the user is authenticated, route/redirect to the requested target site,
based on the requested url.
The url should be for example http://mysite/site1, where the authentication code is in the folder mysite, and site1 is not directly accessible.
Perhaps I can use something like php-express to reuse the same php code on node.js.
I'm building an (amateur) application that uses the Twitter API, which supports authentication via the OAuth protocol.
Part of the OAuth sign-in process involves each application being assigned a Consumer Key and Consumer Secret (both strings), which are used to generate signatures for communication with the Twitter server.
The Twitter dev guide explicitly states that one should 'Keep the "Consumer secret" a secret. This key should never be human-readable in your application.'. This is obviously important, as if a malicious individual obtains your credentials, they can impersonate your app.
However, I do not see how this can be achieved. In order for the application to use the string, it must be accessible to the app somehow (either directly coded into the app, stored in a bundled database, or accessible via a linked web service) - and if it's accessible to the app, it must be accessible to the user. It can be obfuscated by splitting, character-shifting, etc., but not (as far as I can see) in any way that can't be undone.
This SO answer confirms my suspicions that this is a problem - I was wondering if there had been any progress since it was posted in December '09?
The problem with mobile devices is that is in the users hands. And with enough time/effort the user can pull any data out of the device. It isn't an OAuth security problem, it is an overall security problem that there really isn't an answer for.
I have a main website running on AppEngine. It's on a subdomain like main.example.com. This main application is a content portal for our customers. It offers an Ajax application built on YUI. Customers can upload data to it. Users authenticate using Federated Login.
The Ajax application on it allows users to process the data previously uploaded. To do it it should use an webservice running on other subdomain like service.example.com. The webservice does not run on AppEngine but on our services - it's CPU heavy and built on other set of technologies. It would need to download the data on main application - but the downloading service - like everything on the main application - is behind the authentication wall.
I could programatically always allow the service to download wharever it wishes but I think this can turn into a major security problem.
How can I reuse the OpenID authentication "token" to allow it (the service) to appears to the main application as the authenticated user so it can download data? Or If I can do this what would be the best way to accomplish what I intend to do?
You can't really reuse the authentication token. What you should use is something akin to OAuth, though since you control both ends you can make it somewhat simpler:
Generate a shared secret, accessible by both main.example.com and service.example.com
When a user accesses service.example.com for the first time (no authentication cookie), redirect them to main.example.com/auth?continue=original_url (where original_url is the URL they attempted to access)
When you receive a request to main.example.com/auth, first log the user in the regular way (if they're not already). Then, take their user ID or other relevant credentials, and generate an HMAC from them, using the shared secret you established in step 1. Redirect the user to service.example.com/finish_auth, passing the computed HMAC, the authentication details such as user ID, and any parameters you were passed in such as the continue URL.
When you receive a request to service.example.com/finish_auth, compute the HMAC as above, and check it matches the passed in one. If it does, you know the request is a legitimate one. Set an authentication cookie on service.example.com containing any relevant details, and redirect the user back to their original URL.
This sounds complicated, but it's fairly straightforward in implementation. This is a standard way to 'pass' credentials between mutually trusting systems, and it's not unlike what a lot of SSO systems use.
We have one web application (sharepoint) that collects information from disparate sources. We would like to be able to link users to the main websites of those various sources and have them pre-authenticated. I.E. they enter their credentials for the other sources (which are a number of different types LDAP, AD and home grown!) and we retrieve some information for them, and remember there details (Possibly Single Sign-on to keep em nice and safe). The user can then click a link that will open the full app in another window already authenticated.
Is this even likely to be possible?
Office Server has a Single-Sign-On api as a builtin feature. you may want to look into that. It enables you to register user credentials securely, and to access it at runtime.
You need to act as a web browser acts to different sites with storing credentials (usually in cookies) locally. Use therefore a a proper client library with cookie support. This could go probably for most of sites. There are sites using HTTP authentication, which are also easier to access from appropriate client libraries. The most demanding can be access to SSL websites, but again, most client HTTP libraries cover that nowadays as well.
All you need now is just to prepare your web application to act as a proxy to all those separate web resources. How exactly this is done in Sharepoint, well, I hope others will answer that...
True Single Sign-on is a big task. Wikipedia describes common methods and links to a few SSO projects.
If you want something lighter, I've used this approach in the past:
Create a table to store temporary security tokens somewhere that all apps can access.
From the source app (Sharepoint in your case), on request of an external app, save a security token (maybe a guid, tight expiration, and userid) in the token table.
Redirect to a request broker page/handler in the destination app. Include the final page requested and the guid in the request.
In the broker, look up the security token. If it exists and hasn't expired, authenticate, authorize, and redirect to the final page if everything is good. If not, send a permissions err.
Security-wise, a guid should be near impossible to guess. You can shrink risk by letting the tokens expire very quickly - it shouldn't take more than a few seconds to call the broker.
If the destination app uses Windows Auth and doesn't have role-based logic, you shouldn't have to do much. Just redirect and let your File/UrlAuthorization handle it. You can handle role-based permissions with the security token db if required.