Hi all,
Just want to get some thoughts around how you might deal with this issue.
I have a piece of Java code, which when it executes binds to MS SQL and executes a SELECT. Then I do a bunch of "stuff" with the results.
Currently I have the MS SQL server host/port/db name/user/password all stored in a Properties file.
My problem is, the password is in clear text in the Properties file, and the customer doesn't like this.
So trying to think of options to encrypt or obfuscate the password string.
1) Just hardcode the pwd, therefore it is in compiled code – this is a no go, for a number of reasons.
2) Code up some simple code for "decrypting" the string, and have the key in code. Customer doesnt like this.
3) Store a cert in the JKS, and use that. Though off memory I think you need a pwd to access the JKS, so then how do you handle that... seems like Id be chasing my tail a bit.
Not sure what to do at this point.
Hoping some of you guys out there have had to deal with something similar and can point me in the right direction.
Ultimately it doesnt need to be the greatest solution in the world :)
Thanks as always!
I'm assuming this properties file is on their web server?
If that's the case I don't see the problem. Yes it's not ideal for it to be in plain text, but if their web server gets compromised it's game over anyway.
I'm assuming this properties file is on their web server?
Correct.
If that's the case I don't see the problem. Yes it's not ideal for it to be in plain text, but if their web server gets compromised it's game over anyway.
This is exactly what I told the customer, however they are being quite insistent :(
Where is the 'properties file' stored? Is this in the client or in the application server?
e: question answered above.
Next question: which application server are you using?
Where is the 'properties file' stored? Is this in the client or in the application server?
App server.
So I agree, if someone is already on the server then getting this read only clear text password is the least of their concerns.
However they have a security policy that states there should be no clear text passwords anywhere, and they are sticking to it to the letter.
So, just store the password in Base64 and say "look, i has encrypted it". Then make damn sure the permissions on the file are locked down.
While you're at it, you could simply compile in a one time pad, then you can tell them they have perfect encryption!
Does the client have an actual policy regarding what they want done? Not just something they don't want done. Are there any other projects abiding by that same policy?
Do they have a system administrator that they trust?
well you could encrypt it. but the problem with two way encryption is that the key needs to be stored somewhere.
I had a situation where i had to do this one. I stored part of the key in the database and the other part in the code. not idea, but at least the password is encrypted and you need to compromise both database and codebase to get the key.
Can you not just use a trusted connection? It does away with storing the password so no need to mess around with encryption.
if they do manage to get to the .php files no matter how hard you encrypt it they can easily read your code and get out mysql access permissions. Storing the password in a separate database might work provided you hve some self destruct function on the stored password if it checks your server and finds its been compromised or not functioning properly, such as sending PHP files rather than parsing them into HTML.
You also can limit what access you grant such as select, and update only.
or create a unique MySQL login for every user. That way the login for mysql in generated from a password the user enters say to get into the java application rather than stored internally. You just need a master password that has access to create new users and grant them access in mysql
if they do manage to get to the .php files no matter how hard you encrypt it they can easily read your code and get out mysql access permissions.
It's a Java sub-forum, no PHP involved. :)
It's a Java sub-forum, no PHP involved. :)
yeah so i posted a java solution as well two birds with one stone.
yeah so i posted a java solution as well two birds with one stone.
You rarely ever define db passwords on a user-per-user basis in JEE so your solution doesn't really apply.
Instead, database resources typically end up using a generic accounts ACLs controlled by security frameworks. Auditing is typically done within the database or by other means.
You rarely ever define db passwords on a user-per-user basis in JEE so your solution doesn't really apply.
In that case encrypt the same mysql password differently for each user. if they use a password that matches their encryptioned key it can be decrypted properly to get the mysql password.
The key-gen might need to be stored separately.