I know it is very basic question but I need a solid answer to clear my thoughts on it.
I am sending user credentials, key etc in header part in POST method,
Is it a good way? if not then why?
It's a bad way of doing things like these since if somebody could intercept your request - they would get your credentials easily. Better to avoid or at least encrypt this kind of requests.
One of the most popular solutions nowadays is to use OAuth 2.0 (or even better - OpenID Connect). They will bring some complexity to your system but the cool thing about it is that your application doesn't have to deal with passwords at all. Everything is delegated to Authority Server. And there are a lot of the authorization servers ready to use, for instance Keycloak (we have been using it and it and it was really good experience for us)
Related
Let's say I've created a mobile application named 'Foo'(iOS). This app talks to a Java-running backend at 'java.com' and works perfectly. Now, I'm trying to create the website 'Foo.com' to let users enjoy the 'same' service on a browser/computer. So far, I've found that almost all calls needed to the API from the website can be done in JavaScript directly to the backend at 'java.com', including a login-function.
On the backend, I've implemented the standard 'doPost'-method to handle the login, and I create a Cookie to attach to the request.
The problem, I think, is that the users get the JavaScript from 'Foo.com', and the JavaScript tries to log in by using an AJAX-call to 'java.com', thus the cookie will be 'stamped' by www.java.com', not by 'www.foo.com', and the user will never receive the cookie. (At least, I don't receive a cookie now)
I've been trying to find a way to accept cookies from 'api.com' into the application, but it doesn't look good. Honestly, I'm not even sure this is the actual problem causing me to not receive a cookie, but I've read several places that cross-domain-cookies aren't allowed. So I ask the general question, how should I proceed?
I've been toying with the idea to add a .php-page to the server-side of the website 'foo.com', and from there handle the requests from client to API, hopefully causing the cookies to be 'stamped' as 'foo.com' instead of 'java.com'. (In that case, I'd also wonder if the .php can forward the information in the cookie or something similar).
But I really want to avoid as much traffic on the webhost as possible. An all-script-website would be optimal, but I don't really see how cookies can work with that.
Is there anything else I can do to handle this? If I simply want a persistent login-function from a client of 'foo.com' handled at 'java.com', are there any options, with or without the use of cookies?
I am currently in the early stages of creating a web application (HTML5, JS, etc.) that uses a REST API on the backend (Java, specifically Jersey v1.18). The nature of the data that will be stored is highly sensitive, so security is something that I’ve started looking at, even though the application is only in the early stages. The eventual goal will be to have native mobile applications as well, and to potentially provide access to the data for external clients via the same API.
In my research thus far, I have identified a variety of authentication methods, including HTTP Basic, token-based, session cookie, OAuth, HMAC, etc. The key component here is that the REST API will be primarily accessed by users, rather than other applications or backends. Thus, having a “login/logout” equivalent is important, and this boils down to user level authentication.
So far, HMAC authentication looks to be the most promising, as we have no plans to integrate with any OAuth provider at this moment.
I have already read through dozens of SO posts, as well as articles such as:
http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/
http://www.errant.me.uk/blog/2013/04/authenticating-restful-web-applications/ (note: this is clearly bad, as salting with the username is not recommended)
Ideally, HMAC seems like the way to go, but I have yet to see a recommended approach to handling the shared secret. The idea of using a resource to validate credentials, which then provides a token/nonce to be used with the HMAC scheme, seems to be an option, but I’m questioning the advantages over just using this token/nonce strictly as a token.
I know that HMAC authentication for a REST API has been discussed at length, but when used in conjunction with the authentication details that users have come to expect (username, email, password, etc.), is there any recommended approach that doesn’t require a pre-shared secret key?
This is primarily an opinion-based question, but I'll offer my two cents: just go for a session cookie.
If your primary audience is humans, and you don't need to integrate with third parties, don't bother with OAuth. Just make sure your API is only available over HTTPS, and issue a session token that the server can revoke after login. Strictly speaking it doesn't need to be a cookie; I've seen APIs that stash the token in HTML5 session storage and provide it in the Authorization header or as a query param.
If you have SSL set up properly, your users will get the expected padlock in the browser, and you'll be safe from anyone in between you and the client. If the client is compromised, you're screwed anyways. And since the client can't keep a secret, there aren't a lot of advantages to more complex HMAC schemes.
I am designing my first GAE app and obviously need to use HTTPS for the login functionality (can't be sending my User's UIDs and passwords in cleartext!).
But I'm confused/nervous about how to handle requests after the initial login. The way I see it, I have 2 strategies:
Use HTTPS for everything
Switch back from HTTPS (for login) to plain ole' HTTP
The first option is more secure, but might introduce performance overhead (?) and possibly send my service bill through the roof. The second option is quicker and easier, but less secure.
The other factor here is that this would be a "single-page app" (using GWT), and certain sections of the UI will be able to accept payment and will require the secure transmission of financial data. So some AJAX requests could be HTTP, but others must be HTTPS.
So I ask:
GAE has a nifty table explaining incoming/outgoing bandwidth resources, but never concretely defines how much I/O bandwidth can be dedicated for HTTPS. Does anybody know the restrictions here? I'm planning on using "Billing Enabled" and paying a little bit for the app (and for higher resource limits).
Is it possible to have a GWT/single-page app where some portions of the UI use HTTP while others utilize HTTPS? Or is it "all or nothing"?
Is there any real performance overheard to utilizing an all-HTTPS strategy?
Understanding these will help me decide between a HTTP/S hybrid solution, or a pure HTTPS solution. Thanks in advance!
If you start mixing http and https request you are as secure as you would be using http, because any http request can be intercepted and can introduce possible XSS attacks.
If you are serious about your security read up on it, assuming that you only require https for sensible data and transmitting the rest with http will bring you in a lot of trouble.
You pay for http and https the same for incoming bandwidth and you should see any difference in instances hours. The only difference is the one time pay (per month) that you need to pay for SNI or VIP
This question is more towards Design and Architecture and I want to know SO Readers think on my scenario.
I have a requirement where in my Application should provide other application interface when the user logs in to my application.
For example, lets say my application is www.gmail.com and other application is www.stackoverflow.com so what am trying to accomplish is that when the user log's in gmail account he should see his home page of stackoverflow and a particular questions.
From technology point of view, we have to use Java and so am not sure of what design and architecture consideration would go in to implement the requirement.
One Approach, am thinking on is that when the user logs in to gmail than I will populate the request object with all the login credential parameters for stackoverflow website and also question_id which would be passed in as parameter and then on Stackoverflow side, I would parse the request object and authenticate the user credentials and depending upon request parameter, I would render the question_id which I received from request.
I want to know what would be best approach and issues encountered in designing such an system.
Edit
After seeing all the answer, I would like to add little update to my question. What I am looking for is to get the feel of issues and challenges what I would have to face while trying to accomplish my task, also I am using Java and am not sure how can I accomplish my goal using Java as we do not have something like OLE which we have in Microsoft Technology stack to achieve the task.
Hope I am making some sense here.
I can think of three ways you could solve this.
Implement single sing-on. You log-in to all enterprise applications, and once logged all of them use the same authentication credentials (I think this is the best option. you don't need a full-fledge SSO, at least for these two application you could use the same credential validation mechanism)
You could also do what your are proposing creating the authentication credential for the user (i.e a cookie) and then do a redirect. Keep in mind that both application will need to be in the same sub-domain in order to work.
As mentioned before, you could also expose through your application the data/services you want to consume from the other application.
In my company we have what we call "Graphical Services", which are managed by a central server which also do credential validation, if the credentials are right it display a user interface for the user (generally in a Pop-up or an iframe).
Hope it helps.
You can't definitely do that at client side or java script as it will lead to cross site scripting issues. Or you can use iframes (which isdeprecated).
The other way of doing it would be to have your own interface/UI for the application and use only the service layer from your back end (java/j2ee in your case) which you may end up duplicating all the front end again (on the positive side, you will get your own branding of the site).
Regarding credentialing all most all the sites now used "OAuth" or similar and it should not be that difficult for authorizing
If both applications are web-based in-house applications, you could write a master login component, independent of either application, that will perform the user authentication, load any useful data it can at login time, and send the user's browser to the correct URL, making sure to pass any relevant information to the target app (as part of the forwarding request or behind the scenes in some distributed shared memory). Just a thought.
When a user uses a client like Twitter Client to update their status message, they have to provide their username and password. The server then authenticates the user and updates status message.
My question is how to ensure the security of such sensitive information over the internet.
Is JSSE the correct way to go about it?
What points are to be kept in mind when writing such a client?
Kindly help.
From the JSSE Reference Guide:
Once the client and the server are comfortable with each other's identity, SSL provides privacy and data integrity through the encryption algorithms it uses. This allows sensitive information, such as credit card numbers, to be transmitted securely over the Internet.
So yes, JSSE is a good way.
For Twitter specifically, they have a whole page dedicated to security best practices. A lot of those things apply to applications generally, so it's worth a read. In a nutshell, they highly recommend a protocol called OAuth to handle the password safely, and it's going to be mandatory soon. The actual programming environment you use is much less important than the process you use.
For twitter use OAuth instead of basic authentication. Its much more secure way to authenticate users in your case. Some info could be found here:
https://dev.twitter.com/docs/auth/using-oauth