Hoing some java codie here can help. We have some java apps which access a database. Currently, the apps have to pass a user ID (name + password) to the database when they access it. A small number of "data owner" users also have access to this account, other users access the data via the apps.

Problem is, this ID is stored in a plain text config file. So the app developer and root can both access the account details and hence the data.

Data owners are not happy and want the password to be held in encrypted form so that only the app/data owner account can access it. Maybe there are other ways to achieve the required level of privacy.

I can't believe that this is unsolved. How does the java community usualy resolve this one?

(If you are wondering why a non-programmer needs to ask about this on a public forum, just think Dilbert.)

"Klinger, do you know how many zoots were killed to make that one suit?" — BJ Hunnicutt, 4077 M*A*S*H

nordle wrote:OK I know this doesn't help, but that won't stop me saying it, the passwords should be stored and controlled by the RDMS, not a text file.

"can't believe that this is unsolved"

But surely no one would implement user management in this way. If you need both root and user to access the same data, then access control with the rdbms should be setup using roles / groups.

I can testify that people can and have, but I'm not sure if it deserves to be called user management.

I recall being taught that security and authentication should be handled in the DBMS, but I have never been fortunate enough to see it in practice. It is a shame that even with today's well organised Model-View-Controller applications that the model logic still doesn't reside in the the database (for the most part). I think that most application developers turn their noses up at the RDBMS way doing things as soon as the see the grotesqueness of SQL - who can blame them.

At the very least it seems that the database which Guy is talking about should have at least two roles, even if they only have one user each. One for general users and one for administrative users.

Woa! Sorry, I thought I'd explained all that. Data access control *is* via user IDs managed by the database. But it's complicated.
The problem is, the user interface is via a series of web applications, which connect to various databases. Rather than maintain lots of user IDs in each database, the idea is to hold them in one - call it the login database. Then, the web applications query the various databases on behalf of the user, using their own "application user" ID in the other databases. Thus, most of the databases only have two user accounts: the dba and the applications account.
The problem is - the application has to log in to each database as the app user, before it can access the data. Thus, like any other user, the app needs to know its own name and password - so as to match the ones stored in the database.
The problem is, how do we tell the apps what their user ID is?
We do *not* want root to be able to find out (at least, he'd have to be a mega-serious hacker). Currently this info is held in the app's config file which is plain text and so accessible to root. Dang!
Cold fusion is able to encrypt passwords held in this fashion, so root cannot fiddle with it. And once the data admin changes the CF password, neither can the developers.
What we need is the same thing in a java environment instead of cf.

"Klinger, do you know how many zoots were killed to make that one suit?" — BJ Hunnicutt, 4077 M*A*S*H

What you need (I guess) is a method to encrypt passwords. When the password is originally stored in the config file, java encrypts it first. Now, when the user tries to log into the db, the app gets the password, encrypts it and compares it to what is in the text file. If this matches then the original unencrypted version is used.

Mind you, for security you would need a good encryption routinne. But have a look at the javax.crypto packages.

Tony

In the beginning was nothing, which exploded! (Lords and Ladies, Terry Pratchett)

The problem is that there is no user in person. The app is the 'user'. It has to provide the database with username and password before it can access the data. The problem is, how can the password be permanently held in such a way that the app can fetch it and pass it (decrypted) on to the DB, but sysadmins cannot access it.

"Klinger, do you know how many zoots were killed to make that one suit?" — BJ Hunnicutt, 4077 M*A*S*H

If the app is initially given a password, but then a hashed version is set as the actual password, anyone who reads the text file would then have to hash the plaintext. Doable, but it requires extra effort.

Could users of the app require a password to run it? Keep the text file encrypted so that it requires a valid user password to allow decryption. Then you could use the original approach. With a valid password, the app will decrypt the textfile on loading to get the true db password. Ultimately, root can get at anything, so I don't see how you can protect a plaintext file. Even compiling it and making the app decompile is simple to beat.

Tony

In the beginning was nothing, which exploded! (Lords and Ladies, Terry Pratchett)

That hash idea is the kind of thing that migth work. I was kind of hoping that I could say to my colleagues, "go to this official-looking site, downloat that nice stuff and invoke <whatever> from your app." But I can't find any of this.

There are no live users of the app. It has scheduled runs.

Yes there is not much that root can't get at eventually (except maybe the content of the database - if it wasn't for this app). Making it hard for root would at least be better than what we have now.[/i]

"Klinger, do you know how many zoots were killed to make that one suit?" — BJ Hunnicutt, 4077 M*A*S*H