I have a file which I'll call A.txt which I use it within java application. This file is shipped together with application, and I want to have a way to verify (within the application) that it is indeed my file, and not one which was for forged.
I have two ideas, but both are susceptible to some attacks:
I ship signature, A.txt and public key as a plain text with the application but if the attacker simply signs his own file, replaces the signature, A.txt and public key the verification will pass.
I hard code the public key into java app - apart from decompiling, if I send A.txt to person A and B.txt to person B and they exchange their txts they will both verify successfully, and I'd rather have person A verify just A.txt successfully.
How can I do this without any possibilities of being attacked? Or how can I implement my ways so that they are safe?
Hiding an encryption key within code can be very dangerous. Reinard had a good idea about the web service that can encrypt and decrypt the file.
Another option might be to hide the key inside the registry or somewhere in a hidden directory. You can also try building your own algorithm that can build up the decryption key.
But what about decompiling? This has always been a major pain for most developers. How do you properly hide secrets within code? You can try using application packagers or scramblers that can slow down the decompiling process. You can also get a java obfuscator like ProGaurd make your code harder to reverse engineer.
I really hope this helps.
Related
When you compile a .java file into a .class file, if you had a line like
String s = "This is a String"
If you open up the .class file in a text editor, you will see
This is a String
Somewhere in the file amidst the gobblety gook.
Which is fine and dandy for most stuff, but not when dealing with sensitive information like API keys.
Of course, one alternative is to read the API key in from another file, but that just makes it EASIER to find the key, as now the person can just open "key.txt" when they open the .jar file.
So how do you encrypt a string literal in your .class file?
When you send code to a 3rd party, you loose all control over it. Even if you where to embed the API key as an encrypted string, an attacker could still try, and potentially succeed in breaking it, which would make all your encryption/decryption efforts in vain.
The best solution, in my opinion, would be to not provide any sensitive information within the application, but rather provide it with an ID of some sort. Any sensitive values which it needs would be then pulled through the use of a secure connection.
If you use a key to access a 3rd party API there is no way to protect that key from the end-user IF you ship it with your code / application or you want your application to be able to access the 3rd party API without a middleman.
The end-user could just read all data send from your app to the end-point and know the API key. Regardless of any measures you took to encrypt it you will need to send it atleast once decrypted to the 3rd party.
The safe way to do this is to require your user to log in to a service provided by you, send a request to YOUR service and then YOUR service (which is presumably not located on the machine of your end-user) sends a request to the API with the key. So the end-user never knows of the key.
If you store the information in the class file, the decryption key should come from outside of the class. You can crypt the data, but if you have all the information within the class file, you are lost.
You should store API keys in config files. You have a different API keys for development and for the live, right?
Other possible solution is to use KeyStore, which allows you to store sensitive information in publicly accessible format. Only the holder of the secret key can decrypt the sensitive data.
Even if you keep that information encrypted in your class, a hacker can find the mechanism to decrypt that from your code only. So IMHO it's better to keep that encrypted information in some other file, and read that file. Also, restrict the access to that file using OS security mechanisms.
I recently found that the databases of Android apps are totally exposed. That said, my configuration is exposed, I save there passwords.
So, now my doubt resumes on java code.
String value = "example";
This could be an example where I store a password to pass by reference to webservice.
People, with some kind of software (like this example Is there a way to get the source code from an APK file?) could be able to get all the code? (I tried to follow the steps without success)
I read about http://developer.android.com/tools/help/proguard.html, how do I know that it's already implemented in my project?
When you create an Android project, a proguard.cfg file is
automatically generated in the root directory of the project.
I checked my root directory and I don't have that file.
Thank you guys.
Obfuscation does not guarantee that your code won't be de-compiled. people who get your apk will still be able to review the code (although the flow of the app will be significantly more difficult to understand). Function names, variables and class names are changed but the code is still viewable.
password and other sensitive information should be kept in Android's keychain , where it's protected. never save passwords in a configuration file (preferences file).
You can look into encrypting your local database with sqlcipher. Proguard obfuscates code but will not hide your passwords if you have them hardcoded anywhere, it is not a tool to be used for security[reference]. Also all of your network traffic is vulnerable unless you use some sort of TLS.
As you describe your app now it is trivial to get the passwords in your app.
You can use char[ ] instead of string data type for storing sensitive values like password. This will make it difficult to recover if someone takes memory dump as value is not present string literal pool if used char[] data type.
I'm writing a small Android app and I need to hide some variable values. I have a API key I got from the content provider who is providing me content to show in my app that I need to retrieve data from them. Because it is being used in an encryption algorithm, it is of vital importance the code isn't leaked.
I need to save the API key in my code and be sure it isn't retrievable by the bad people in the world. What I do now, is save them in my code as a variable:
private static final String API_KEY="mysupersecreatapikey";
After the app is compiled to an APK file, this is, in my opinion not retrievable anymore. Am I doing it in the right way now, or is there a better solution?
Thx in advance,
Daryl
You could store the API key in a file located in storage. You can encrypt the API key when you write it to the file and then you can decrypt it when you are reading it (upon program execution)
If you put the API key into the client in any form that can be used by the client it will be possible to get to it somehow. Maybe by unwrapping the APK and decompiling the code, maybe by traffic sniffing. That private static final variable for example can likely be extracted by a decompiler (if it's bytecode).
If you want to make really sure that none of your users can get to the API key then your app shouldn't be using it directly. Instead have it connect to a web service you set up that serves session IDs for example. That web service that runs on a server that you have control over (quite a few options) would then be the only piece of software that knows the API key.
But depending on the use case this might be a complete overkill solution to this problem.
Hi I have a game made in Java and Slick2d and I have a folder that contains all of my resources (images, sounds, etc) and I was wondering how to encrypt them so people can't edit them? I tried MD5 but I'm not really sure how it works and I'm not worried about people breaking into the code because I have spliced the jar into an exe file. Also if I need to know how to decrypt the files so that they can be used in the code please explain that too.
There is no way to protect the images/resources, all you can do is make it slightly harder. If you deliver your images/resources to the client then they can always decrypt them, after all the client has to display them unencrypted at some point in time.
Btw.: MD5 is a hash-algorithm, it is used to check if data is undamaged.
MD5 is a hash function which is irreversible and two input may produce the same output.
in case the content of the files is not 'secret' you can use MD5 for a verification process, this should be quite easy.
Create a hashtabe (or just a table) with the hashes of all the resources your application uses
Once the applet lanched create an hash for each of the files and compare it with your table, if its not the same, someone has changed the content of your jar file.
I'd recommend to keep the hash table within the code so it will be harder to modify
If you are using your resources, you have to decrypt them then the client can use them, because they are being used in the game.
I am developing a Java Desktop Application. This app needs a configuration to be started. For this, I want to supply a defaultConfig.properties or defaultConfig.xml file with the application so that If user doesn't select any configuration, then the application will start with the help of defaultConfig file.
But I am afraid of my application crash if the user accidentally edit the defaultConfig file. So Is there any mechanism through which I can check before the start of the application that whether the config file has changed or not.
How other applications (out in the market) deal with this type of situation in which their application depends on a configuration file?
If the user edited the config file accidentally or intentionally, then the application won't run in future unless he re-installs the application.
I agree with David in that using a MD5 hash is a good and simple way to accomplish what you want.
Basically you would use the MD5 hashing code provided by the JDK (or somewhere else) to generate a hash-code based on the default data in Config.xml, and save that hash-code to a file (or hardcode it into the function that does the checking). Then each time your application starts load the hash-code that you saved to the file, and then load the Config.xml file and again generate a hash-code from it, compare the saved hash-code to the one generated from the loaded config file, if they are the same then the data has not changed, if they are different, then the data has been modified.
However as others are suggesting if the file should not be editable by the user then you should consider storing the configuration in a manner that the user can not easily edit. The easiest thing I can think of would be to wrap the Output Stream that you are using to write the Config.xml file in a GZIP Output Stream. Not only will this make it difficult for the user to edit the configuration file, but it will also cause the Config.xml file to take up less space.
I am not at all sure that this is a good approach but if you want to go ahead with this you can compute a hash of the configuration file (say md5) and recompute and compare every time the app starts.
Come to think of it, if the user is forbidden to edit a file why expose it? Stick it in a jar file for example, far away from the user's eyes.
If the default configuration is not supposed to be edited, perhaps you don't really want to store it in a file in the first place? Could you not store the default values of the configuration in the code directly?
Remove write permissions for the file. This way the user gets a warning before trying to change the file.
Add a hash or checksum and verify this before loading file
For added security, you can replace the simple hash with a cryptographic signature.
From I have found online so far there seems to be different approaches code wise. none appear to be a 100 hundred percent fix, ex:
The DirectoryWatcher implements
AbstractResourceWatcher to monitor a
specified directory.
Code found here twit88.com develop-a-java-file-watcher
one problem encountered was If I copy
a large file from a remote network
source to the local directory being
monitored, that file will still show
up in the directory listing, but
before the network copy has completed.
If I try to do almost anything non
trivial to the file at that moment
like move it to another directory or
open it for writing, an exception will
be thrown because really the file is
not yet completely there and the OS
still has a write lock on it.
found on the same site, further below.
How the program works It accepts a ResourceListener class, which is FileListener. If a change is detected in the program a onAdd, onChange, or onDelete event will be thrown and passing the file to.
will keep searching for more solutions.