This question already has answers here:
Handling passwords used for auth in source code
(7 answers)
Closed 7 years ago.
I've been working on a Java project for a while now, and before I make it available for public download, I'd like to add in a feature which requires me to connect to a MySQL database. My question is simple: How would I go about hiding the password to the database if the code is open-source?
Store the database connection settings separate from your code.
You can put the password in some sort of configuration file like an ini file. During the setup/installation stage, get the password from the user and populate it in the configuration file either by code, or allow them to do it manually.
As far as I know, there is no correct answer. You can try really hard to obfuscate or hide it, but if the password or a method of calculating it is in your JAR, a persistent and skilled user will find it.
There is a much better answer than I could give here:
How can I protect MySQL username and password from decompiling?
Related
This question already has an answer here:
Where to store keysytore password?
(1 answer)
Closed 4 years ago.
So, I am planning on making a bit of java code to encrypt and decrypt strings I throw at it. The issue is trying to save the encryption key: It is clearly visible in the Java code and I haven’t found a way around putting it into code. I have also checked several threads here, but I haven’t found the answer to my specific question.
tl;dr
I want to know how to securely store a password in Java code.
tl;dr I want to know how to securely store a password in Java code.
TL;DR - There isn't a way to securely store a password in Java code.
Any password that is embedded in your code in a usable form can be reverse engineered with a modest amount of effort and skill.
The solution depends on the problem you are trying to solve:
If you are trying to hide and use the secret (e.g. password, key, whatever), AND the user you are trying to hide the secret from controls the execution platform then there isn't a solution.
If you (or trusted admins) control the platform1, AND it is properly secured, then there are a few approaches, of varying degrees of security. These range from Store the secret in a file that the user can't access through to using an HSM (Hardware Security Module) to hold the secret.
Refactor the application so that the secret ... and the things protected by the secret are physically separated from the part of the software that the untrusted user runs; e.g. do the "special stuff" on a server.
Give each user their own personal secret (key, password, etc) ... that can be revoked.
1 - Given that "root escalation" flaws are fairly common, you would be well advised to not allow untrusted users to get access to the platform at all. However, I doubt that this is an option for what you are trying to do.
This question already has answers here:
What is the best way to save user settings in java application?
(3 answers)
Closed 6 years ago.
I'm currently creating a password safe type of application and I'm stuck at the login. Currently, the user can create an account and select the place where the data will be saved (via object serialization) using JFileChooser. This all works fine. The problem is that when the user closes the application and tries to login (without creating a new account) the application doesn't know where the login data is saved and thus can't check if the login credentials are valid. Besides making the user show the application where the save data is every time they log in, how can I fix this?
You have 3 basic options:
Keep the password file in a relative location to the .jar, so it always knows where to find it.
Pass variables to the application via the command line.
Have the application look up an environment variable.
This question already has answers here:
Handling passwords used for auth in source code
(7 answers)
Closed 7 years ago.
I have a question about passwords in source code. E.g. if you would like to connect to a FTP server you have to write the password in the source code in plain text.
Is this secure? Or is it possible to decompile the JAR file or in Android APK File to get these data in plain text? Is there a secure method to store the data?
The most secure way to do this, would be to have a "Middleman server" running on the same machine as the ftp.
The app contacts the server and says "Give me the files".
The server then logs on to the ftp and sends the files back to the app.
The app never knows the password, username or anything to the ftp. Only the ip address and how to get files from the server.
The server could then have some sort of protection to only take certain requests, or only from the app etc.
Java De-compiler can be easily found on Internet.
In case of apk, you can
Extract the APK on computer
generate .jar file using tools like dex2jar convertor
get source code back using java decompiler.
But i have also find some app which can't be decompiled to source code in this way, and i don't know how they have achieved this.
If you have to contain the password in the source code, it's more secure to obfuscate it in C and your Java code simply get it from JNI. Otherwise, follow the suggestion by René Jensen.
This question already has answers here:
SQLite with encryption/password protection
(9 answers)
Closed 9 years ago.
My desktop Java app uses several read-only SQLite databases, which I would prefer people not be able to open up and look at. Normally, this might be accomplished through encryption, but I'm currently using the sqlite4java library, which does not support encryption and doesn't easily allow other SQLite encryption libraries (e.g. SEE) to be used.
What I'm trying to do is make it as difficult as possible for a "casual hacker" to just find one of these database files and open them up. For instance, someone threw out the idea of sticking them in a password-protected ZIP file, then using a library like the ones suggested here to decrypt it on the fly as either an InputStream or a temporary file.
Would this be something that is worth doing?
EDIT: I realize that this isn't going to be perfectly secure, and a hacker dedicated enough might be able to still find a key and decrypt it (this seems like a vulnerability with any such programs).
"What I'm trying to do is make it as difficult as possible."
You are probably just making it as difficult as possible for yourself.
Regular users don't open application binaries. People that open application binaries have tools to find your encryption key.
If you want to engage in security through obscurity, just name the database file "commons-io-3.2.1.jar" instead of "mydb.sqlite3". No trouble for you, still throws off the "casual hacker".
Instead of password protecting your SQLite DB, you can choose not to ship it with the application APK, rather download the content on first run, so that you don't have to encrypt and decrypt and your APK is lighter.
Also remember, your DB can still be hacked by intense hacker.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
SQLite with encryption/password protection
My problem is that I am on a struts2 web application and I am creating a sqlite database file dynamically. I need to protect that file (when users download that sqlite file it needs a password to open it, like a password-protected PDF). Is there any other way to complete this task?
There is an encryption library (sqlite-crypt) available in C, but if you want to do it in Java, I would simply encrypt the file like any other file and supply a decryption tool with password for the user. See this example of file encryption/decryption in Java.
The best solution is to install SqlCipher or something similar, but that means that you must build and install a C extension to your Java environment.
If you decrypt the SQLite database on starting your app and then encrypt it on ending then it's "exposed" while you're actually using it (and if the app is terminated abnormally). With SqlCipher the data is always encrypted, even in the middle of an operation. The other alternative is to encrypt/decrypt individual "blobs" stored in the DB, but then you can't search on them, etc.
You can use Zip4j (http://www.lingala.net/zip4j/) to create a password protected zip file.