how can I store API credentials like authentication key, google map API key securely, currently I have stored that credentials in strings.xml.KeygenratorSpec requires minimum API level of 23 is there any way to store securely any help will be more helpful I am stuck since 2 days but no idea.
Short answer: you can't do it.
Longer answer: You can use obfuscation in order to make it difficult to find the API credentials, but still, someone with enough time and a few skills will find it and break it. Using KeyGenerator will also not help. I am assuming that you were planning to encrypt/decrypt the API credentials. You will still need a key to be stored in or retrieved by your application. So, the same problem still remains, someone will just have to find one more string before being able to access your credentials.
Obfuscation is probably your best chance. Of course it's not bullet proof, but if it's complicated enough it might delay or demotivate someone who is trying to break your application. You can use proguard to obfuscate your application code (if you don't want to pay for something more advanced), however it will not obfuscate strings. You will have to use other techniques for that. You can find plenty of examples online, and you can use your own layers of obfuscation as well. I don't think that you will find any good recommendations or standards in order to do it. Of course, no matter how hard you try, it will still be a matter of time for someone to revert.
EDIT:
This is a good tutorial for configuring proguard: http://wiebe-elsinga.com/blog/obfuscating-for-android-with-proguard/ (be careful what you include because otherwise you might get crashes when you generate an apk)
Regarding string obfuscation, you can use something similar to this: https://github.com/efraespada/AndroidStringObfuscator however you will still need some password, so decryption will be possible. Using an existing string as a password (one that you are already using in your app) might confuse someone if you combine it with code obfuscation. Hiding parts of the string in various files/resources and combining them when you want to create the string will probably add more confusion. However if you make it too complicated it might be easy to spot. For example if your strings.xml contains only 1 encrypted string (unreadable), there is a good chance that this is the string that you are trying to protect. Following this will lead to this information. So, in my opinion, there are no best/good practices. You can get a few ideas by looking online, but I would suggest you judge for yourself where is the best (less obvious) way to hide it, and this depends on your code and application structure. But anyway, this will only trick inexperienced/lazy attackers and automated tools.
Another thing that I do often is to not allow certain parts of the code to run if debugging is enabled, or when the apk file is not signed by myself. These countermeasures are not bullet proof either, but might demotivate a lazy attacker. Here is a good guide on how to do this and other things: https://www.airpair.com/android/posts/adding-tampering-detection-to-your-android-app
Related
I'm building a basic webapp that takes in a user input and returns an encrypted password.
Problem is, currently the SecretKey I am using is stored in the src for the Java class. To me, it seems this is risky practice so I'm trying to find a way to safely store my SecretKey.
Doing some research, I found the Java KeyStore class but I'm not entirely sure if this is what I need. Also, if this is what I need, can you guys point me in the direction of how to implement it, and more importantly, how it works?
Thanks
Edit: From doing a lot of thinking/reading it seems like there really isn't a great solution and really a solution isn't needed so long as your main server is secure, which mine will be, so it's not an issue.
Thank you for all the replies! :)
Passwords should be stored using one way hash functions that way your system avoids this problem. See https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
If you are talking about your encryption key, then there is no secure way to store that key safely in JavaScript. I guess the storage you are talking about its the browsers local storage, which is nothing more then a persistent cookie on browser side.
Everybody that uses the chrome WebInspector or Firefox Firebug can easly read this store for any page he is visiting. Furthermore, you would have to save it in this store by JavaScript and as everybody can read your source code in the browser, its even more obvious.
The only possibilty to do such things safely is Server-Sided, like with PHP for example. If you though want the feeling of interactive behaviour, you can use AJAX on clientside to interact with the backend.
EDIT:
Ah, I think I got you wrong as you are talking about Java in Backend? If yes I think there is no Problem when u have the key hardcoded in your compiled sources??? If you want to store it somewhere else and are afraid someone uses it, you could salt and hash it in your application before you use it for key generation (of course the salt is hardcoded then)?
I have android application that has hard coded (static string constants) credentials (user/pass) for sending emails via SMTP.
The problem is that .dex file in .apk can be easily reverse-engineered and everybody can see my password.
Is there a way how to secure these credentials, while i will still be able to use them in my classes?
We can use "jni module" to keep 'Sensitive Hardcoded Strings' in the app. when we try to reverse engineer APK file we get lib folder and .so files in respective process-folders. which can not decrypt.
You can save your string obfuscated by AES.
In Licensing Verification Library you can find AESObfuscator. In LVL it is used to obfuscate cached license info that is read instead of asking Android Market to find out application is licensed or not. LVL can be downloaded as component of SDK.
I guess you can try a code obfuscator, but really that won't make your password 100% secure and I don't know how well it goes along with the android compiler. Why not use a secured web authentication , like that of Google?
Hashing is not possible since it is not two way.
Any encryption such as AES, DES, blowfish, etch is not a viable solution as you have to include the decryption part within your app and that can be decompiled with a combination of apktool, dex2jar and JD (java decompiler) which is a very powerful combo while decompiling any apk.
Even code obfuscators don't do anything except make life a little more difficult for the decompiling guy, who'll eventually get it anyways.
The only way which I think would work to an extent would be to host the credentials on a server which only your application can access via a web-service call through a separate authentication of some kind - similar to FB's hash key thing. If it works for them, it should work for us.
I was looking into a similar problem and came across this useful thread:
http://www.dreamincode.net/forums/topic/208159-protect-plain-string-from-decompilers/
I'm not too familiar with Android development, but the same ideas should apply.
doing these would be useful:
1- you can encrypt them and obfuscate the encrypting algorithm. any encryption along with obfuscation (progaurd in Adnroid) is useful.
2- you better to hardcode your strings as byte array in your code. many reverse engineering applications can get a list of your hardcoded strings and guess what they are. but when they are in form of byte array they are not readable. but again Proguard is necessary. (it only hides from RAM string constant searching and they are still searchable from .class file)
3- using C++ code to host your constant is not a bad idea if you encrypt them before hardcoding and decrypt them using C++ code.
there is also a great article here :
https://rammic.github.io/2015/07/28/hiding-secrets-in-android-apps/
If you do not have the means to do a web authorization you will need to include the third party decryption with you application.
This is what you could try
1) Write a standalone program only to create a password hash one time. (This program should not be a part of your app). Make a note of the hash that was generated.
http://www.mindrot.org/projects/jBCrypt/
// Hash a password for the first time.
String hashed = BCrypt.hashpw(password, BCrypt.gensalt(12));
2) Store this password hash as a String constant in you APK.
3) Then every time you need to check the password, compare with the hashed password, using bcrypt.
// Check that an unencrypted password matches one that has
// previously been hashed
if (BCrypt.checkpw(candidate, hashed))
System.out.println("It matches");
else
System.out.println("It does not match");
jBCrypt is a single java file and it can be directly included in your application. It is considered one of the strongest encryption algorithms for passwords.
Even through the decryption algorithm is present in you APK, trying to break this is very time consuming details of which can be read in the article below.
Read this article for details and security of bcrypt.
http://codahale.com/how-to-safely-store-a-password/
Again, use this only if you do not have the means to do web based authentication.
Use some kind of trivial encryption or cipher that only you (and your code) understand. Reverse the string, store it as array of integers where you need to take the mod of 217 or something silly to find the real password.
One way you can 100% secure you hard-coded string.
Firstly don't use pro-guard use allatori
Link: http://www.allatori.com/
And secondly don't take you hard coded string in any variable just use that string like this:
if(var=="abc"){}
"abc" is exampled hard coded string.
Allatori fully obfuscate all string that are used in code like above.
Hope it will help for you.
We have recently installed a Google Search Appliance in order to power our internal search (via the Java API), and all seems to be well, however I have a question regarding 'automatic' site-map generation that I'm hoping you guys may know the answer to.
We are aware of the GSA's ability to auto-generate site maps for each of its collections, however this process is rather manual, and considering that we have around 10 regional sites that need to be updated as often as possible, its not ideal to have to log into the admin interface on a regular basis in order to export them to the site root where search engines can find them.
Unfortunately there doesn't seem to be any API support for this, at least none that I can find, so I was wondering if anyone had any ideas for a solution/workaround or, if all else fails, the best alternative.
At present I'm thinking that if we can get the full index back from the API in the form of a list, then we can write an XML file out using that the old fashioned way using a chronjob or similar, however this seems like a bit of a clumsy solution - any better ideas.
You could try the GSA Admin Toolkit, or simply write some code yourself which just logs in on the administration page and then uses that session to invoke the sitemap export URL (which is basically what the Admin Toolkit does).
I'm thinking about making a simple web application to practice custom tags, EL, ...
Now I'm thinking about how to make a simple front page.
I want to have a front page where I'll show a short description of a post and then the user can click it to see the full article.
Further down the line I'd like to attach a poster to it, and even further down the line I'd like to allow people to leave a comment.
Now I see two ways to do this:
a) put it all into a database
b) put the short description and the article into a .tag file and put the comments and users into the database.
Now I'm wondering which way would you go, or would you go for something entirely else?
The first way is probably the easiest but it does require access to the database "often".
The second way is a bit more "sloppy", especially depending on my implementation but it does have the advantage of accessing the database less often.
And any recommendations on keeping the data actual?
I could either load everything each time somebody accesses the news page, or I could put it in the application scope and put the articles into a bean and use a listener.
And do you use hibernate/jdbc/... for a database connection?
I'm getting the feeling that the actual programming will be the easiest part.
Any directions (or book recommendations for that matter) are welcome.
I've read head first servlets & jsp, and while it does a wonderful job of explaining how to develop the application I find it a bit lacking in the when/how to connect with the database and how to optimize it.
Sorry for the long post that possibly doesn't really fall under the scope of this site.
As far as I can see, you are thinking too much about performance. You should not. It is of a little concern in the start. Go what feels right. Tackle performance when its actually lacking.
I would suggest you
You should use some pooling mechanism for database connection. Its very important and make the process very efficient. Take a look at DBCP or C3P0 or something.
to go store your data into the database, even the short description, in some appropriate table.
Moreover, don't load everything when somebody accesses the page, it might go futile and it will take a lot more time and the user gets frustrated.
you can cache data later when you feel its a good idea. Hibernate provide caching real easy, you might try to incorporate Hibernate, as you mentioned it yourself.
you can use AJAX calls wherever appropriate to get rapid request/response.
These are few things I like to mention.
What techniques could I use to make my "jar" file Reverse Engineer proof?
You can't make it reverse engineer proof. If the java runtime can read the instructions, so can the user.
There are obfuscators which make the disassembled code less readable/understandable to make reverse engineering it harder, but you can't make it impossible.
Don't release it.
There is no such thing as hacker proof. Sorry.
EDIT FOR COMMENT:
The unfortunate truth is that no matter what barricade you put in the way, if the honestly want in, they'll get in. Simply because if they're persistent enough they'll be looking at your code from an Assembly level. Not a thing on earth you can do about it.
What you can look at doing is Obfuscating code, packing the jar and merging all externals packages into a single to make life harder. However no matter how high the hurdle, my comment in the previous paragraph still applies.
I think this is more about hardening the access path to the jar, more than anything else.
Try to determine what user context
will actually be executing the code
that will access the .jar. Lock
down access to the jar to read-only
access from only that user. How you do this
will depend on if you're using the jar from
a web app or a desktop .exe, and it will also
depend on the operating system you're running
under.
If possible -- sign the jar and
validate the signature from the
executable code. This will at least
tell you if the .jar has been
tampered with. You can then have
some logic to stop the executing application
from using the .jar (and log and display an error).
See jarsigner docs for more information.
I have seen one case where a company wrote a custom classloader, that could decrypt an encrypted jar file. The classloader itself used compiled JNI code, so that the decryption key and algorithm were fairly deeply obfuscated in the binary libary.
You are looking for an "obfuscator" (if you want to ship jars) . Many exist:
http://java-source.net/open-source/obfuscators
You should be aware that many obfuscation techniques removes information you may want to keep for troubleshooting purposes - think of the value of a stack trace from an irreproducible situation - or actual debugging sessions. Regardless of what you do, your quality testing should be done on the jars-to-be-shipped since the obfuscator may introduce subtle bugs.
If you really want to hide things, consider compiling to an native binary with gcj.
Definitely avoid placing any sensitive data in the code. For example:
passwords
database connection strings
One option would be to encrypt these (using industry-standard encryption routines; avoid rolling your own) and place them in an external configuration file or database.
As others have stated, any algorithms in deployed code can be reverse-engineered.
Sensitive algorithms could be placed in a web service or other server-side code if desired.