Difference between client (java standalone client)application authentication and user authentication

views:

answers:

Difference between client (java standalone client)application authentication and user authentication

Hi, In case of webapplicaiton I can understand that there is no difference between the client authentication and user authenticaiton; Ignoring XSS and other exploits the web client is generated by the server/servlet.

But suppose you have a Java client application talking to the Java Server application; The server has a certificate associated with it so that the client can validate and verify if server is trusted. Now client also has a certificate (client cert) so that the server can verify if this is a trusted client; Once this mutual authentication is done, instead of presenting a username/password dialog to the user, the users certificate (user cert) can be passed to the server.

Question is whether there is any advantage/use in this case in having a (client cert); Or will the user certificate alone will suffice to trust the client as well ??

I know this is an obvious question/ but cant a rouge client application be created ?? So will the client cert protect against this scenario.

If some attacker gets to alter in some way the client application, it could use the valid user certification to access the server.

The server should verify the client app, not for server sake (we assume the server checks if client can do this or that operation, but for ensuring the client is not being phished by a bogus client). Then the server can proclaim that all operations made by client-1 we're made through some verified client-app (agent) so they were really intended by the user.

helios 2010-08-24 12:26:44

I assume you are telling that we should have both the client certificate as well as user certifcate; But can the server be sure that the client is not compromised .. kindly see my comments to the posts below - Thanks

alexcpn 2010-08-25 03:52:07

Yes I was telling that. And it's a good point, maybe the server can't know if the client app is compromised. I don't know what comments are you referring... I guess the comments on @rancidfishbreath.

helios 2010-08-25 06:56:51

The comments I was referring to was the ones to rancidfishbreath answer

alexcpn 2010-08-25 08:16:36

The client application's certificate (and it's private key) can be easily ripped off the application and rogue application can be created. The ways to counteract this are (a) use user's certificate and let the user provide it when needed and (b) use a USB cryptotoken to store the client certificate and it's private key. Cryptotokens don't let the private keys out so the attacker can't copy it (though he can use the token with his application, if he has physical access to the token).

Eugene Mayevski 'EldoS Corp 2010-08-24 13:00:01

Do you really need a certificate/private key to create a rouge application. Thearatically you could edit the client binary to add some malicious intstructions ?

alexcpn 2010-08-25 03:50:04

You would need to identify possible threats then. Are you trying to identify your client application on the server (ensure that it's your client that's calling the server) or you are trying to ensure that your application is not altered (again, for what purpose) or ... ? Depending on possible dangers the solutions are different.

Eugene Mayevski 'EldoS Corp 2010-08-25 05:21:37

yes our requirement is to secure at multiple layers; I assume that the use of a client certificate is to ensure the identity of the client; However from a quick though on the subject I assume the term identity for a software application is meaningful only in conjunction with data integrity.However I believe it can be argued that even without a check of data integrity there is some value in client authentication;

alexcpn 2010-08-25 08:15:22

+1 A:

Any time you have a client server application the server needs to assume the client is compromised. When an authentication occurs (username/password, certificate, etc... it doesn't matter) the server should grant the user certain permissions to use the functionality of the server. Whenever a request is made to the server the server needs to check whether the authenticated user has the permission to perform that action.

Trusting the client to only make authorized requests opens yourself up to attacks. If you check permissions on the server and scrub inputs then you don't have to worry about whether the user is using a trusted client because even an untrusted client won't be able to do more than the trusted client could with the same authentication credentials.

These principles apply regardless of wether you are using a web client or a stand alone client. Even in a web app I can write a new client and POST data, use RESTful services, or generally talk to the web server and completely bypass the web ui you present to me.

rancidfishbreath 2010-08-24 14:56:16

"even an untrusted client cant do more than a trusted client could with the same authentication credentials" I assume there is no mechanism currently for server to tell whether the client application is compromised;Assume that the untrusted client gets sensitive data from the server via a trusted user session. Since the method signature is same and parameters are clean the server will send the requested data;There is nothing preventing the rouge application to misuse this data.One thing I can think of is having a integrity checker tool in the client side m/c to see if the app is compromised ??

alexcpn 2010-08-25 03:47:46

Did some searching in the net and found that this is a common attack - Excrept from -- http://www.ucl.ac.uk/cert/nix_intrusion.pdfThe most simple and classic example of this is to replace /bin/login.1. Obtain a copy of the source code to /bin/login for the version of Unix 2. Edit the source code to /bin/login to include a "secret" password that will always let you login as root if you enter the "backdoor" password. This backdoor will also not create an entry in the system log files.3. Compile the source code......

alexcpn 2010-08-25 04:09:39

The point is that you can trust a user based on credentials they provide but you can't trust a client application unless you are in a closed environment (really locked down corporate environment). The problem with an integrity checker on the client side is that a compromised application would fake the integrity check. No matter how complicated the integrity check, given enough time, a person could circumvent it.

rancidfishbreath 2010-08-25 14:32:27

ansaurus

tags:

views:

answers:

Difference between client (java standalone client)application authentication and user authentication

related questions