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

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?

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.

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.

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

It's been a while since I last tried it but yes, they do.

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.

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.

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.

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?

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.