Here's the scenario:
You have two seperate websites that exist in different environments (I.E. different databases, different web servers/domains)
You have full control over the code for both sites, but from the above point, they can not directly communicate with each other's database
You must transfer user from site A to site B securely
What is the best way to implement this? Simply sending the user identifier between the sites via query string wouldn't be secure, even if encrypted, since someone else could obtain the URL. It seems like the standard solution is to pass the user identifier along with another temporary key that web site A created, and web site B knows about. If this is the case, what's the proper way of securely setting up the system with the temporary key?
Thanks!
I am doing something like this. The best thing I can think of right now is passing a HASH of the user ID, or if that makes you worry, the hash of some other user data.
If yuo want temporary keys(I might do something like this too), how about setting up a web service on A that B can call to to get the user ID based on the temporary key. This way it's a totally separate call, and can be secured.
Take a look at "Pass-through Authentication," its a concept that allows a user's identity to be passed from one system to another.
Additionally, another idea that you may want to try is to create a secure token that does not expose the user's information and pass it on. However, this requires both systems to have similar data to verify the token. As the other answer suggested, hashes are very good uses to create non-descriptive bits about sensitive information.
Write a web-service call over HTTPS, at both ends, to retrieve the users details, and that only works for a specific login-pair. Problem solved. You need to make the login-id's at both ends uniform or use single sign on cookies. More details in the paper by Vipin Samar: "Single Sign on Cookies for Web Applications".
They can't get the URL/Passwords unless they go into the application code at one of the servers.
You need to pass information between Site A and Site B, but you don't need to make the user the conduit for that information.
Site B could have a web-service that allows Site A to create a session for the user. In this design the interaction would go as follows:
User clicks button on Site A
Site A calls web-service on Site B which passes a temporary login URL back to Site A
Site A redirects user to the temporary URL on Site B
Related
I'm trying to implement a GET method with Express in my nodeJs application.
I'd like to do something like this in order to display user data :
router.get("/user/:idUser", (req, res) => {
The user doesn't need to be authenticated in order to execute this code. However I don't want that anybody can execute this request with a user id of someone else. Because he could see data he's not supposed to see.
How could I proceed ? I thought about using some encryption process to have something like :
/user/PdfgdfJFDGTfrfgdsf
Your question isn't really making sense. You don't want authentication, but you only want a user to be able to view their own data so nobody else can view it.
The ONLY way to solve that is by using some form of authentication. The user has to prove to the server that they are allowed to view that data before the user renders the page for them.
Yes, you could obscure the URL (make it some mostly unguessable string of characters), but it's not clear what problem that is solving. The user themselves won't be able to remember it or type it so it would probably have to be a link in a web page and if it's a link in an unauthenticated web page, then anyone can get to it - thus defeating the purpose.
There are cases where temporary links (often done for privileged downloads) such as what you mention /user/PdfgdfJFDGTfrfgdsf are sent via an authenticated channel (either an authenticated webpage or sent to an email address known to belong to an authenticated user) and these links contain some unique and hard to guess code. The user can then click on that link (in authenticated webpage or in email) and access that resource without further authentication. In that case, the knowledge of the code in the URL is serving as a form of proof of authentication. Because URLs may be logged in service providers or corporate infrastructure and thus not remain entirely private, this technique has its limitations and is typically only used for short term (download this resource in the next 10 minutes) type of uses, not a long term substitute for authentication and not used for things that demand real security. You don't explain enough of your use case to know whether this is practical for your situation or not.
The user doesn't need to be authenticated in order to execute this code. However I don't want that anybody can execute this request with a user id of someone else. Because he could see data he's not supposed to see.
That's an inconsistent statement. You say "user doesn't need to be authenticated in order to execute this code" and then you say "I don't want that anybody can execute this request with a user id of someone else.". You can't have both. The user is either required to prove authorization or they aren't. Pick one. It can't be both.
you can use jwt for this and a auth middleware for this
upon decoding jwt token, you can implement logic to check if the decodedToken.user_id (given that you add user_id when encode token payload) is equal to the :idUser in route (or any kind of logic you want) there.
I'm writing a GWT application where users login and interact with their profile. I understand that each form entry needs to be validated on the server, however, I am unsure about potential security issues once the user has logged in.
Let me explain. My application (the relevant parts) works as follows:
1 - user enters email/pass
2 - this info is sent back to the server, a DB is queried, passwords are checked (which are salted and hashed)
3. if the passwords match the profile associated w/ the email, this is considered success
Now I am unsure whether or not it is safe to pass the profile ID back to the client, which would then be used to query the DB for information relevant to the user to be displayed on the profile page.
Is there a possibility for a potential user to manually provide this profile ID and load a profile that way? My concern is that somebody w/ bad intentions could, if they knew the format of the profile ID, load an arbitrary amount of information from my DB without providing credentials.
-Nick
What you are dealing with here is a session management issue. Ideally, you want a way to keep track of logged in users (using random values as the session key), know how long they have been idle, be able to extend sessions as the user is using the site, and expire sessions.
Simply passing the profile ID to the client, and relying on it to send it back for each request is not sufficient - you are correct with your concern.
You want to keep a list of sessions with expiration times in a database. Every time an action is executed that needs user permissions (which should be pretty much everything), check to see if the session is still valid, if it is, extend it by however long you want. If it is expired, kill the session completely and log the user out.
You can store your session keys in a cookie (you have to trust the client at some point), but make sure they are non-deterministic and have a very large keyspace so it cannot be brute forced to get a valid session.
Since you're logging a user in, you must be using a backend that supports sessions (PHP, .Net, JAVA, etc), as Stefan H. said. That means that you shouldn't keep any ids on your client side, since a simple id substitution might grant me full access to another user's account (depending on what functionality you expose on your client, of course).
Any server request to get sensitive info (or for any admin actions) for the logged in user should look something like getMyCreditCard(), setMyCreditCard(), etc (note that no unique ids are passed in).
Is there a possibility for a potential user to manually provide this profile ID and load a profile that way? My concern is that somebody w/ bad intentions could, if they knew the format of the profile ID, load an arbitrary amount of information from my DB without providing credentials.
Stefan H is correct that you can solve this via session management if your session keys are unguessable and unfixable.
Another way to solve it is to use crypto-primitives to prevent tampering with the ID.
For example, you can store a private key on your server and use it to sign the profile ID. On subsequent requests, your server can trust the profile ID if it passes the signature check.
Rule 1 - Avoid cooking up your own security solution and use existing tested approaches.
Rule 2 - If your server side is java then you should be thinking along the lines of jsessionid. Spring Security will give you a good starting point to manage session ids with additional security features. There will be similar existing frameworks across php too (i did not see server side language tags in the question).
Rule 3 - With GWT you come across javascript based security issues with Google Team documents and suggests XSRF and XSS security prevention steps. Reference - https://developers.google.com/web-toolkit/articles/security_for_gwt_applications
We have a Sharepoint Project Management site up and is active amongst our clients. The site url looks like this:
https://projects.acme.com/clients/[client_name]
Each of our clients has to remember (or bookmark) this long url; the users of this site are not very savvy. They fumble with it all the time. We also do not want clients to know who each other are; so client 1 shouldn't know that client 2 is a client.
We would like to put a login form on our website, prompting for user id and password. Then we would like to be able to route the user based on a successful authentication, to the specific web that is theirs.
Is there a good clean way to make this happen? Is forms authentication the way to go? Are there drawbacks to using forms authentication?
Given my url structure, would this approach work?
http://msdn.microsoft.com/en-us/library/bb975136(v=office.12).aspx
Update: I'm not particularly interested in a solution that requires two weeks of effort on the part of a programmer/admin to setup, nor am I particularly interested in one of the commercial solutions that are $4k-8k. I was hoping to discover a pretty straightforward way to get this done in under a day of effort.
Yes, you can implement it using FBA.
However, if you use only the user ID and the password, the user IDs across all websites will need to be unique (i.e. if client 1 creates a john.smith user ID, client 2 will have to use john-smith or johnsmith or something completely different). The easy solution is to ask additionally for the company name on the login form, the user ID and the password, but then you'll probably have to handle different ways the users will enter the company name (i.e. acme, ACME, Acme, Acme Ltd, Acme Inc, Acme Inc.).
Update:
You can also consider host-named site collections and have URLs like https://client_name.acme.com. The downside is that you cannot use Central Administration to create a host-named site collection - you can do it by using PowerShell or custom code.
Generally it is highly unlikely you will find a free solution to get your task done in under a day of effort - admittedly, SharePoint does support FBA, but does not provide basic things like a login form, a change password form or user management; you need to create them yourself or use some existing solution (e.g. SharePoint 2010 FBA Pack).
If you want to separate users and also make URL's more sweet you have a two ways.
Create a web applications per user.
Create one application with multi tenancy support. Check more on this Spence's Harbar article.
Second approach is more flexible, but harder to implement, and if you plan to have many clients (more than 50) it's the only way.
I'm in the process of using the facebook javascript sdk to provide user login functionality for a website.
What I'd like to do is simply take the logged in user's unique facebook id and then put/fetch data to/from a mysql database using the id to determine what data is available to said user.
However I don't really feel like this is very secure. Whilst I'm not storing anything sensitive like credit-card details etc, I'd obviously prefer it to be as secure as practically possible.
My fear is that with javascript being what is it, someone could fake the facebook id and just pull whatever they wanted.
I'm aware that the php sdk would provide a solid solution to this problem, but i like the javascript one mainly because it's easy to use and I have the basis of it set up (I admit it, I'm lazy).
So, my questions are:
Would this set up be as insecure as I feel it might be?
Is there anything I can do to improve the security of such a system, other than switching to the php sdk?
Thanks!
Facebook Ids are pretty hard to make up (at most a user will only know their own). Depending on what you store in the database (which will not be anything that the user cannot get on their own, unless you ask for extended permissions)
If you are worried about a user trying to get information from the database, add an access token or signed request to each row and us that and facebook id to get data. That will greatly increase security.
EDIT
There are few occasions where you get a signed request from a user:
* A signed_request is passed to Apps on Facebook.com when they are loaded into the Facebook environment
* A signed_request is passed to any app that has registered an Deauthorized Callback in the Developer App whenever a given user removes the app using the App Dashboard
* A signed_request is passed to apps that use the Registration Plugin whenever a user successfully registers with their app
Signed requests will contain a user id only if the use has accepted permissions though, and are not passed again if the user enters the application, and accepts permissions (meaning that the signed request would not contain the ID). Because of this saving an access token may be a better idea. Here is more on the signed request
Also the signed request is in the url (param = "signed_request"). I always parse it through c# but I am sure you can at least get one through javascript
It's pretty easy to spoof the origin using curl. I'd imagine Facebook has another mecanism in place to make this possible. If you inspect their code, it appears that they generate an iframe and pass requests through. If I had to guess, they have setup the requests to only be made from the Facebook domain, and ensure that the iframe can only be embedded in a page that has a white listed domain.
I'm sure there must be a simple answer for this but I can't figure it out -
I have a Silverlight 4 OOB application that requires a login screen/security. The View shows a LoginView (Username/pw) which then passes the details to a WCF service and checks it against a database. It will return a result to the client to say if their details were valid or not. This part works fine.
Where I need some guidance is the best way of storing the fact that the user is logged on/authenticated for the current Silverlight session.
It's OOB so we can't use any web cookies/session stuff as far as I know. I assume we have to store some sort of Identity in the thread but I need some pointers please.
The other caveat is that I would like to secure all other pages to check if the user is authenticated and redirect to the login screen if not. I use the Navigation framework so I have a Frame - this may make it easier...
Any tips or pointers appreciated - I just need some ideas to get started please.
Just store the fact that the user is authenticated anywhere you like - I tend to like the Application object since it's an app-wide setting, but you can stick your "IsAuthenticaed" and/or "Roles" properties anywhere, really.
Take a look at WCF RIA Services - even if you don't want to use their solution, you can take a look at the generated authentication code it makes and see a good real-world example of how this can all work.
As for redirecting if the user is not logged in, I suggest using an INavigationContentLoader on your Frame, which can implement this logic in a central location. See these two excellent posts by David Poll on the subject of INavigationContentLoader and authentication/authorization:
http://www.davidpoll.com/2010/01/01/opening-up-silverlight-4-navigation-authenticationauthorization-in-an-inavigationcontentloader/
http://www.davidpoll.com/2010/05/10/common-navigation-ui-and-authorization-driven-sitemaps/