32

I'm developing an application which read some data from a db. The connection to the db is performed through standard login/password mechanism.

The problem is: how to store the db password? If I store it as a class member, it can be easily retrieved through a decompiling operation.

I think that obfuscation doesn't solve the problem, since a string password can be found easily also in obfuscated code .

Anyone has suggestions?

Mauri
  • 630
  • 1
  • 5
  • 11
  • 3
    Is it your database, or the customer's database. If it's the customer's database, he should know its password. If it's your database, where is it located? Why would a customer application directly access the database, without going through some server where the password is stored, and where the bytecode is unavailable to clients? – JB Nizet Nov 19 '11 at 15:46
  • 1
    I usually store it hard-coded in my application as a String encrypted with Rot13. (joking). – Hovercraft Full Of Eels Nov 19 '11 at 15:48
  • If you are using Java EE, there are some standard mechanisms to deal with this... but I guess you are not. I don't think it helps security to hide the password if your application gives full access to the db. – toto2 Nov 19 '11 at 15:59
  • Related question: http://stackoverflow.com/questions/992019/java-256-bit-aes-password-based-encryption – Aaron Digulla Oct 08 '14 at 07:32
  • You can use Java Keystore API to securely store passwords in Java. Here is an article about it: https://camelcodes.net/securely-manage-passwords-in-java-applications – moolsbytheway Mar 08 '23 at 08:11

3 Answers3

26

Never hard-code passwords into your code. This was brought up recently in the Top 25 Most Dangerous Programming Mistakes

Hard-coding a secret account and password into your software is extremely convenient -- for skilled reverse engineers. If the password is the same across all your software, then every customer becomes vulnerable when that password inevitably becomes known. And because it's hard-coded, it's a huge pain to fix.

You should store configuration information, including passwords, in a separate file that the application reads when it starts. That is the only real way to prevent the password from leaking as a result of decompilation (never compile it into the binary to begin with).

See this wonderful answer for more detailed explanation : By William Brendel

Community
  • 1
  • 1
COD3BOY
  • 11,964
  • 1
  • 38
  • 56
1

For a small and simple app where you don't want to involve a lot of other security measures, this should probably be a configuration option. When you deploy your application, it could read a configuration file where the database connection properties are specified. This means that application per se doesn't know the password, but you need to gain access to the server to find the password.

Albin
  • 4,180
  • 2
  • 27
  • 19
1

Some datas should be configurable. Just now as you told, it may be a username and password or some common datas; Normally what we do is creating a property-configuration page. What I used to do is use an XML file, keep your password/username in some encrypted format. You can easily parse an XML to retrieve your password for connectivity.

This ensures the reliability that your passwords can be changed at any time. This refers not to passwords only. but any data that you use, which is to be configured from time to time.

Kris
  • 8,680
  • 4
  • 39
  • 67