JDBC Inherently Insecure?

Question

I a currently writing a program for a university assignment, and we are required to use the JDBC to connect to a MySQL database.

Considering that the database password must be exposed to the program in some form or another, in order for it to access the database, surely you might as well hand the password to a hacker in the first place?

Am I right, or am I missing something?

Are you talking about a web app or a thick-client app? The issues are very different between the two. — Kirk Woll, Jun 08 '12 at 01:00
In the scenario given, staff would be using the program, but there's no reason a hacker or a mischievous staff couldn't get it. (I'm meant to authenticate users from a table in the database, but with the database password, all data can be collected and rainbowed/birthdayed etc.) — user1277170, Jun 08 '12 at 01:02
right, I realized the risks are different depending on appplication type, so I changed my comment to what you see above asking you to clarify. — Kirk Woll, Jun 08 '12 at 01:03
This really depends on the design of the application. Is each application user assigned a MySQL user? — cheeken, Jun 08 '12 at 01:05
It's a desktop application that will handle the bulk of the operations, which would make it a thick-client. — user1277170, Jun 08 '12 at 01:05
@cheeken That's the only way I can think of securing it. But for the purposes of the university, I only have my user account, so I can't make new ones for security purposes. — user1277170, Jun 08 '12 at 01:07
Must JDBC be used _within the client_ to connect to the database? In this scenario, typically you would have a web service that uses JDBC to connect to the database, and your client would interface with your web service. Your web service can use an authentication scheme of its own to enforce security. — cheeken, Jun 08 '12 at 01:11
That is where strong password policies come in: you can rainbow all you want, if a password has letters, digits, special characters, and a healthy mixture of upper and lower case letters, guessing is not going to help much. — Sergey Kalinichenko, Jun 08 '12 at 01:11
@cheeken I guess that resolves the issue of the usefulness of JDBC, but according to the university brief, a single application must have a GUI and a database connection. It just seems to me like the university is teaching us how to program security holes. — user1277170, Jun 08 '12 at 01:24
@dasblinkenlight Well, collecting passwords is just the start. Anything the program could do, the hacker could mimic (e.g. the creation of a new account.) — user1277170, Jun 08 '12 at 01:26
I think you should do (1) a multi-tiered application (the password is not stored in any code the user can reverse compile and there is no network connection between the user and database); **or** (2) a database client application which requires the user to input the password (the password can not be gotten from reverse compiling the code) — emory, Jun 08 '12 at 01:29
@emory Under normal circumstances, I wouldn't disagree with you, but the university seems to imply a single application. See my response to cheeken above. — user1277170, Jun 08 '12 at 01:31
@user1277170 I actually don't see how your university brief conflicts with suggestion #2. I regularly use a database program based on JDBC. It required me to initially setup a database connection (and then it stored my credentials - which is a usability plus but also a security weakness). If you want to be high security, your application could require users to input credentials b4 each database connection. It is not perfect. A hacker could, for example, install a key logger. You are tunneling the connection over SSH right? — emory, Jun 08 '12 at 01:41
@emory There is a single password for the database; there are multiple users that will use the program. Anyone who gets the program, would be able to get the database password, regardless of the programs' accounts. — user1277170, Jun 08 '12 at 01:47
This question is similar to this: http://stackoverflow.com/questions/55643/how-do-i-keep-a-mysql-database-secure — Renato, Jun 08 '12 at 02:18

score 1 · Answer 1 · answered Jun 08 '12 at 02:13

If you're concerned about the security of your JDBC connections, encrypt them. http://dev.mysql.com/doc/refman/5.0/en/connector-j-reference-using-ssl.html

You'll pay a performance penalty, but this is the alternative to plain text. According to the MySQL documentation:

The performance penalty for enabling SSL is an increase in query processing time between 35% and 50%, depending on the size of the query, and the amount of data it returns.

This option is available with most SQL and noSQL databases.

score 0 · Answer 2 · answered Jun 08 '12 at 02:11

The password must be exposed to the application, that's for sure, otherwise how is your application connect to the DB?

But this is not a big security flaw. The machine where the application runs is what must be secure at all costs. This is the main thing! If a hacker or even a naive user has access to the machine where the application runs, they could wreck havoc in your systems even without knowing much at all if they have enough privileges. Once a person has access to your application's source code AND to the machine it's running on, there's just no way in the world you can make it secure, unless maybe if you have a very good user account management system.

You can externalize the password to a text file and store it hashed, maybe even with a salt, which is basically the best/most used way I know of... but this just makes the life of someone who has access to your machine slightly harder... having access to the source code they can still break into your database if they are smart, or if they are not, they can simply delete or corrupt it.

So there's nothing wrong with JDBC... if you disagree, please convince the millions of users of JDBC otherwise. Security is not something you build on a single technology. It involves protecting ALL of your systems and adding layer after layer of protection at each different node, but beware that each layer of protection compromises more and more usability and flexibility (this is the reason people don't just add 1000 layers of passwords on top of an application/database, it's just impractical and mostly unnecessary, even).

if you store the *hashed* password, how are you going to get it back in order to send it as part of the database connection authentication? — Greg Kopff, Jun 08 '12 at 02:25
@Greg Kopff The DBMS I use allows you to create a file with plain text password, then when you start up the SQL server, it will hash the password in the file and save it like **--hash--(followed by the hash)**.... obviously, the DBMS must have privileges to change the file and the file must not be in the source code. — Renato, Jun 08 '12 at 04:01
This procedure is for CouchDB: http://guide.couchdb.org/draft/security.html#hashing but a similar procedure can be used with SQL databases, I imagine. — Renato, Jun 08 '12 at 04:22

score 0 · Answer 3 · edited May 23 '17 at 12:21

JDBC is the standart API that Java applications use to connect to a Database System. It’s vey mature , solid and widely used among the Java Community.

Although, some applications make improper use of the API by exposing –for example- database connection credentials in the source code.

In How can I protect MySQL username and password from decompiling? there’s a nice explanation of this design problema and some suggestion to solving it: Like storing database credentials in files external of the application and adopting a multi-tiered architecture.

JDBC Inherently Insecure?

3 Answers3