I have some .java files containing some password variables, and these variables have values:

String password = "xyz";

Now after run, when I open the .class file, it contains those passwords. How can I store my password somewhere safe? I don't want to use DB for storing.

  • 1
    Why do you need the password in the application at all, i.e. what is it used for? If you need it in clear in order to authenticate against some resource the most you could do is to obfuscate it so that it is not too obvious to find when looking at the .class file. – Steffen Ullrich Dec 13 '16 at 7:26
  • 1
    Related question #1, Related question #2. – Anders Dec 13 '16 at 7:53

You cannot.

If the application has to know the password, there is no way to store it safely, unless you ask a user at run time for a master password. Because if the app can get it, an attacker could do the same either directly if it is stored in clear text or with reverse engeneering if it has been obfuscated.

The real question to ask is why an application should know a password? If is is interactive, it should ask it (or a master password used to decode an encrypted vault) to a user, and if it is not (a service or daemon), you should either rely on machine identification on a local controlled network, or accept that any person that has enough privileges to see the application files can know the password, and protect (including physical protection) the machine and account running the app.


I'm not a java developer, naturally I work with C# but i know storing passwords in plain text is not a safe way to store them.

As far as I know; you can decompile java, in which case you will be able to read the passwords without a problem. If you are running an open source project with source code in a repository somewhere; storing this password in plain text is going to be a much bigger problem than storing it in the database.

Personally I feel like any password should be encrypted using a strong up-to-date algorithm which you do not create yourself but use a trusted and reliable library to do this for you.

Just general looking around it appears that using char[] is far better than using a string because strings are immutable.

As a reference I have come across an article which explains some best practises for storing passwords:


char[] vs string storing passwords:


I have no personal experience in Java development as mentioned; but i'd be very concerned seeing passwords stored in plain text.

  • 2
    Any software can be decompiled, regardless of technology. Maybe not in a way which restores the original sourcecode, but enough to find any magic constants. Encryption isn't a solution either, because when the software wants to decrypt the data, it needs an algorithm and decryption key which must also be stored somewhere in the application. – Philipp Dec 13 '16 at 9:11
  • 1
    You are missunderstanding the string versus char[] issue. That is about how to store the password in RAM, not on disk. If you have the password in the source code you do not have to go through the trouble of reading it from RAM - you just read it from the source. So using char[] solves nothing. – Anders Dec 13 '16 at 9:31
  • @Philipp this is where my java experience is lacking I'm afraid. I know as much as the application being bundled into an executable But I would trust Owasp in the correct way to encrypt passwords: owasp.org/index.php/Hashing_Java – Gary Hammett Dec 13 '16 at 12:24
  • 1
    @Anders Yes exactly, it is about how the password is stored in ram. The topic is about storing from within the application, so a memory dump will in turn show the password which is a security risk. As with a char[] array it can be wiped from memory which makes it more secure: codingeek.com/java/strings/… – Gary Hammett Dec 13 '16 at 12:25
  • The question is "How do I prevent people from reading the password from the source code?" and your answer is "Do this to prevent people from reading it from RAM." That is not an answer to the question. – Anders Dec 13 '16 at 13:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.