How to hash JAAS j_password on client? - java

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.

Related

Does Java handle HTTPS encoding behind the scenes when I call my SOAP service?

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.

How to authenticate a mobile ADF application

How can I authenticate a user onto IIS. Actually my purpose is that an online user to make supply enter the application by using a kind of verification. And on the other hand we have Microsoft web system. So probably, I need to solve the authentication issue on IIS. Essentially I know how to secure and authentication AMX page within weblogic system. Basic HTTP Authentication is a standard though and ADF mobile useS it too. But can it handle my expectation, I cannot be sure.
What is the best practice and best way?
This is acutally a question to the IIS guys - all you need is a URL on that server that will prompt you for a basic authentication.

Java LDAP auth with a non-cleartext password

JNDI LDAP auth requires a cleartext password to be passed (Context.SECURITY_CREDENTIALS) to almost all security mechanisms (or at least how I understand it). It looks like to be designed in a way, that the password originates from the current JVM. But what about a password, that has to be sent from another machine? This approach forces it to be sent in a recoverable fashion (the most simple is cleartext) with little security.
To be more specific, let's consider a 3-tier setup: client, java server and an LDAP server. The user enters the username and password in the client which is sent to the java server. Then the java server communicates with an LDAP server in order to authorize these credentials. Is there a way to make the transmission from the client to the java server secure?
I understand, that we can use SSL or another way to secure the channel itself, but it's still no good that we have to send the password in a recoverable fashion through this (even secure) channel.
I tried to search for an answer, but it looks like most of them consider a 2-tier setup. There were also some 3d party java libraries recommendations (instead of JNDI), but it wasn't clear, if that they can handle my task. If they actually do so, could you please give an example utilizing them for my task?
My target platforms are Delphi XE3 Client, Java SE 6 Server and an AD LDAP. But I'm also interested in a more theoretical discussion not restricted to these concrete client and LDAP.
This approach forces it to be sent in a recoverable fashion (the most simple is cleartext) with little security.
The approach requires you to use SSL. It's as simple as that.
We found the answer and actually made it work on a production system.
The correct path is to use the Kerberos protocol http://en.wikipedia.org/wiki/Kerberos_(protocol).
In my setup the following happens:
1) The client obtains a ticket to the server service in the AD and sends it to the server. This is done via classes near TSSPIWinNTCredentials class in Indy, but I think it's quite possible to do so without difficulties using Windows functions directly.
2) The server logins to the AD as a service. This is done via LoginContext class using correct AppConfigurationEntry with keys.
3) The server authenticates the client in the AD using client's ticket, obtaining client's username. This is done via Subject.doAs method and classes near GSSManager class.
4) The server performs additional business level checks and grants the client a business session. This is business-specific of course.
At no point in this scenario any insecure communication is made, including sending passwords in a recoverable fashion, because it is the design goal of the Kerberos protocol itself.

GWT RPC: Is it secure to send plain-text password

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

Supplying credentials safely to a RESTFUL API

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

Categories