aspose file tools*
The moose likes JDBC and the fly likes Is there some trick to prevent decompilers from seeing my password? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Databases » JDBC
Bookmark "Is there some trick to prevent decompilers from seeing my password?" Watch "Is there some trick to prevent decompilers from seeing my password?" New topic
Author

Is there some trick to prevent decompilers from seeing my password?

apchar boiir
Greenhorn

Joined: Sep 07, 2004
Posts: 18
I have an applet that remotely accesses a password protected MySQL database. It both reads from & writes to the database.
Java decompilers are easy to find. Anyone could decompile my applet, look for
DriverManager.getConnection(..., "userName", "password");
and they'd have the password. Anyone feeling malicious could wreak bloody havoc on my database. But I just can't see anyway around it and most books don't even talk about security.
What can be done to protect that password?
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18907
    
    8

And anybody could sniff the connection between you and the database to see the password being passed unencrypted across the network. Yes, there's a way to avoid this, but calling it a "trick" is a bit unkind.

The way to avoid it is to not have your applet talk to the database. Your applet should talk to a server application which talks to the database on behalf of it. The password would be located in the server application, then. It wouldn't be exposed in your applet's source code and it wouldn't be passed across the network. And besides that, the server with the database on it could then be inside your firewall instead of being exposed to the internet.

This isn't a weird and radical solution, this is actually a standard way to access databases across the internet.
apchar boiir
Greenhorn

Joined: Sep 07, 2004
Posts: 18
So the server application would examine & validate the data before writing it to the database? Makes sense.
Is there a buzzword for this sort of thing that I can look up & learn more?
What should I look for in a webhost to make sure they'd allow me to run such applications? I'd think most would be leery of anything alien running on their servers.
Jan Cumps
Bartender

Joined: Dec 20, 2006
Posts: 2510
    
  10

They will also be leery to let you connect to the database from an applet, no?
Have you tested if they actualy allow this?


OCUP UML fundamental and ITIL foundation
youtube channel
apchar boiir
Greenhorn

Joined: Sep 07, 2004
Posts: 18
It's been a while since I last tried it but yes, they do.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18907
    
    8

apchar boiir wrote:So the server application would examine & validate the data before writing it to the database? Makes sense.
Is there a buzzword for this sort of thing that I can look up & learn more?

"Web application"
What should I look for in a webhost to make sure they'd allow me to run such applications? I'd think most would be leery of anything alien running on their servers.


No, their servers are there for people to run applications on. At least, the ones who support applications of the type you decide to write. In other words, don't ask them if they support X until you have decided what "X" is going to be.
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4659
    
    5

I'm a bit surprised that no one gave the trivial and easiest answer: don't store your password in the code. Period.

If you store the password in code that a bad guy(tm) has access to, then they can get access to your password. This is true for source code, byte code, object code, etc.

If you are serious about security, you can't have direct JDBC access from code running on the client, because you can't trust the client computer. To handle this properly, you have the user login, and you return a session nonce (in a cookie, or whatever). Your client side code then passes back the session nonce to the server-side, and the server-side validates it and calls JDBC.

Jan Cumps
Bartender

Joined: Dec 20, 2006
Posts: 2510
    
  10

Pat Farrell wrote:I'm a bit surprised that no one gave the trivial and easiest answer: don't store your password in the code. Period.

...


We left the goal open so that you could kick in the ball, Pat.
apchar boiir
Greenhorn

Joined: Sep 07, 2004
Posts: 18
Pat Farrell wrote:I'm a bit surprised that no one gave the trivial and easiest answer: don't store your password in the code. Period.

If you store the password in code that a bad guy(tm) has access to, then they can get access to your password. This is true for source code, byte code, object code, etc.

If you are serious about security, you can't have direct JDBC access from code running on the client, because you can't trust the client computer. To handle this properly, you have the user login, and you return a session nonce (in a cookie, or whatever). Your client side code then passes back the session nonce to the server-side, and the server-side validates it and calls JDBC.



So is this what a servlet would do?
Should I look for a webhost that supports tomcat if this is the plan?
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4659
    
    5

apchar boiir wrote:So is this what a servlet would do? Should I look for a webhost that supports tomcat if this is the plan?

That is one approach. The key is to provide a service on the Internet that provides the results, rather than providing the software itself.

Which implementation approach is best is an engineering trade-off. You could write a servlet and host it on a service using Tomcat or Glassfish or JBoss, etc.
 
 
subject: Is there some trick to prevent decompilers from seeing my password?