Wouldn't you encrypt the password? How exactly does this program run? Is it an applet or a JFrame that the user has?
For the update you could have a servlet that reads the password from the xml DD. I think it's the servlet context you would have to set onn that though.
server_crash
Postaholic
2,111 posts since Jun 2004
Reputation Points: 113
Solved Threads: 20
what are you trying to achieve?
Is the password entered by the users and the program checks it (with the users getting a new password mailed every week)?
If so the solution is simple: save the password in the form of an MD5 hash and compare the MD5 hash of the password the user enters with the hashed password you stored.
That way the application never knows the password at all (as it will get the hash from the generator, also removing the risk of a man in the middle attack fetching the unencrypted password during transmission).
No language is completely safe from decompilation, and network attacks can catch your passwords being transmitted also independently from the language used.
You can add further safeguards in your Java environment like custom classloaders that use an encrypted table of hash codes (or more likely serial version IDs) of your classes and compare those with the ones calculated from the actual classfiles to check whether there has been tampering, classfile encryption, etc. etc. but of course nothing is ever completely safe from the dedicated cracker.
What you always (in any environment) need to ask yourself is how much effort/money is the worth of your data security and how to best spend it.
Often the conclusion will be that there's no real need to go further than a stern license and removing debugging information from the compiled code.
In a high security environment you'll often find that the best way to work is to not have the end user have access to your software (or at least the secure bits) at all.
You'll be acting like an application service provider, with your customer through some interface contacting the software which is running on your own machines at a secure location you control and getting back only the results.
That way the application (and your firewalls) can prevent anyone from calling the application who is not at a known customer site. Add password security and only people at that site with the required credentials can call the application.
And only people at your site have access to the compiled binaries, so noone can decompile anything who you don't have explicit knowledge of.
jwenting
duckman
8,392 posts since Nov 2004
Reputation Points: 1,662
Solved Threads: 337
If you use a one-way encryption algorithm like MD5 there's precious little chance of it being decrypted (as the algorithm doesn't support it).
I know someone in China is doing work towards decrypting MD5 but it's so far not a threat (at most their method will give you an idea where to look for the password, some hints towards its composition).
jwenting
duckman
8,392 posts since Nov 2004
Reputation Points: 1,662
Solved Threads: 337