I have a question about how to send password over the wire from the GWT web app to the server.
My client talks to server using HTTPS. My understanding is that GWT RPC uses HTTP POST to communicate. So I assume it is OK to send plain-text password using GWT RPC.
Am I wrong? Is there any other options for sending password securely between GWT client and server?
Many thanks
There will be no problem because you are laready using HTTPS.
If still you have a narrow edge in mind then you can send the strings like passwords..account numbers in a secured way by using a thirdparty light weight library called GWT-Crypto.
It uses TripleDesCipher to encrypt your strings with an byte array key(known by you only).
Here is an example ,and not exactly but some related question here.
GWT is not different to any other browser app. Almost authentication systems use the same approach: send password using POST over HTTPS.
You are right that it is OK to send plain-text password using GWT RPC
This might help
1) GWT/Javascript client side password encryption
2) GWT with SSL security
Related
In Java, I am building a stand alone web service client that manipulates records in a cloud based CRM by using its SOAP API. I generated my classes using the wsimport utility with WSDLs that all have addresses prefixed with https in the port binding section of the WSDL. Is Java handling behind the scenes all the wire-level security simply because the address is https? If so, how can I confirm that the SOAP message is being encrypted? My code does work, and I have not needed to worry about security until now, because I am developing in a staging environment with temporary passwords.
Thank you for your help!
Putting https in the URL will almost always do the trick. Even if your code is not capable of https, the webserver at the other end will almost never allow you to talk in HTTP when using the HTTPS port. At least, I've never seen one that does.
It's not a 100% guarantee that you'd bet your business on, but it is close.
If the code you write works on any website that does require https, you are the rest of the way there in terms of assurances.
You can confirm the traffic is encrypted by running a traffic analyzer aka packet sniffer.
I was just running through a few basic tutorials on using JAAS in web applications.
I got everything setup fine but noticed that the j_password parameter is sent from the client browser in clear text.
Is there a way to make JAAS hash this value before sending it?
My application is running on Tomcat 7, so I don't know if this could achieved through some server specific setting or via some web app setting?
Have a look at The definitive guide to form-based website authentication
In short: Client side password hashing requires javascript on the client; there is no such standard if you use form based authentication that you can simply enable on the server. In any case, make sure your connection is encrypted (HTTP over SSL). Then it is less/not important to hash passwords on client side.
I want to use OAuth in one of my apps, specifically a Google Chrome extension. Can it be done through JavaScript code? My only requirement is that it should be done with client side Javascript code, and the server can use either JavaScript or Java.
If this cannot be done, then can I use simple userid-password authentication?
Again, my only requirement is that it should be done with client side Javascript code, and the server can use either javascript or java.
You can definitely use OAuth in a Google Chrome extension, although bear in mind that your application keys and secrets will be readable in the bundle.
For more information: http://code.google.com/chrome/extensions/tut_oauth.html (the example uses one of Google's API enpoints but you could use any OAuth1.0a provider). Since you are interested in doing a Chrome extension you will not be affected by the normal hassle of request origin (cross site scripting) restrictions.
You can use "normal" userid and password authorization as well of course (especially over SSL/HTTPS). If you plan on going public with the APIs then I would recommend OAuth though.
JavaScript is pure client side scripting language. It cant be used in server side.
Second, If you want your client get authenticated there must be a server side program to do so.
i m using java,gwt.while login or creating account when user will enter the password,on server side i m encrypting it but i also want to apply encryption to passord on client side.which i will decrypt on server side and will use it for further process.
i googled but i m not getting which technique should i use for encryption on client side.
Thanks in advance.
Client side encryption in javascript will not be secure because you must somehow provide the key to the client and server. So key will need to be sent over unencrypted network.
This scheme is really a security through obscurity and is not secure, because someone could reverse engineer your protocol and get the key.
The only way to secure data on the web is HTTPS. You can simply configure this on the server without changing your code.
GWT-Crypto is what you need.
Hope this helps.
I've created a RESTful server app that sits and services requests at useful URLs such as www.site.com/get/someinfo. It's built in Spring.
However, these accesses are password protected. I'm now building a client app that will connect to this RESTful app and request data via a URL. How can I pass the credentials across? Currently, it just pops up the user/password box to the user, but I want the user to be able to type the username and password into a box on the client app, and have the client app give the credentials to the RESTful app when it requests data. The client is built using Struts.
Cheers
EDIT - I don't think I made the question clear enough. I'm already forcing HTTPS, my question is more, in-code, when I'm requesting data from www.site.com/get/someinfo, how do I pass my credentials alongside making the request?
You more or less have 3 choices:
HTTP Auth
Roll your own protocol, ideally HMAC challenge/response based
OAuth
OAuth is currently susceptible to a variation of a phishing attack, one that is largely undetectable to the target. As such I wouldn't recommend it until the protocol is modified.
OAuth should also be a lesson about how difficult it is to design secure protocols, and so I'm hesitant to reccomend the roll your own route.
That leaves HTTP auth, which is likely best if you can use it.
All that said, almost everything on the internet uses form based authentication, and many don't even bother with https for transport level security, so perhaps simply sending the password text in the clear is "good enough" for your purposes. Even still I'd encourage using https, as that at least reduces the dangers to a man in the middle attack.
If you can add HTTP headers to your requests you can just add the Authorization header:
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
where you're using basic authentication and the QWxhZGRpbjpvcGVuIHNlc2FtZQ== bit is "username:password" base64 encoded (without the quotes). RFC 2617
Well, https has nothing to do with authentication, it's just transport-level encryption.
if you interact with an HTTP api, be it that it's https or not, and the dialog box pops up, it means its using HTTP authentication, either basic or digest. If your client instantiates an http client to read data from those "services", then you can pass those credentials when you instantiate the object.
If you use client-side script, XmlHttpRequest supports http authentication as well.
So in terms of code, how you pass the credentials to the RESTful services is dependent on the http client you're using (the object you instantiate to retrieve the data). You can simply collect such a username / password yourself from the client, and use it to call the other service.
look at existing solutions. In this case, oauth