Java - How to store password used in application? [duplicate] - java

This question already has answers here:
Handling passwords used for auth in source code
(7 answers)
Closed 7 years ago.
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?

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

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.

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.

Related

store api credential securely

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

How to store sensitive data into java code for android development

I am willing to use java email api for my android app. I got it from this link. But as mentioned here in the link, to use this api, I need to give my own email id and password in GmailSender as Plain Text. For this reason I am tensed about my password. If anyone decompile the apk file then he can easily get my email id and password.
But I don't know how to store these sensitive data into my code safely.
How can I do this?
Note: I am not willing to use any third party library to encrypt thses data
It is nearly impossible to completely protect your app from reversal engineering, especially without any third party library.
BUT instead you can create another e-mail, with a different password, and configure it to resend any email received to your official e-mail.
This way if anyone actually manage to reverse the code and get the password, they will only have access to this secondary and unimportant e-mail account. This should solve the problem.
More info about actually protecting the code here:
How to avoid reverse engineering of an APK file?
How to make apk Secure. Protecting from Decompile
You should obfuscate your password string before keeping it in your source code. You can:
Do it manually, It can be take a time.
Or use some automatic tools. If you don't want to use any third party library to encrypt these data, Bg+ Anti Decompiler/Obfuscator is a good choice for you. It works on java source code (not Java byte-code) so you will control everything

Secure solutions to encrypt / decrypt passwords in property files [duplicate]

This question already has answers here:
Encrypt password in configuration files [closed]
(10 answers)
Closed 4 years ago.
I'm looking for a way to store encrypted text in a properties' file, and then decrypt it on the fly, something that allows something like:
Store password in encrypted form in properties' file
When Spring reads that property from a placeholder, it automatically decrypts it and loads the plain text value
After searching the web, all I found was Jasypt. I gave it a test run, and it does what I need, but it seems abandoned? (Last commit activity was 2 years ago).
So far, I've replaced Spring's PropertyPlaceholderConfigurer to detect encrypted values and to decrypt them before loading, and managed to get it working.
However, since it's security, I'm somewhat worried that rolling my own solution isn't the best way to do this. Are there any coding particulars I should be aware of when hosting my own encryption/decryption capabilities (even though I'm using Java's built-in functions underneath)? Or is it safer to go with a possibly abandoned, but well known project than to roll my own?
Thank you.
EDIT: edited to stay on-topic.
I can vouch for using Jasypt. It does what it's supposed to do, and multiple dev teams that I work with still use it in their applications.

Protect string constant against reverse-engineering

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.

How Can I Access Rails' Session In My Java App

I have two web apps in one domain. One is written by ruby another is by java. And my rails app is using db session. So there have a "sessions" table in my database. What I want to do is reading the session info from this table in java.
Here is my problem: Rails' sessions table is encrypted. So I can not read it directly from JDBC.
I don't want to write a decrypt code to convert it. Because it's not a good idea to split one logic both in java and rails. So I hope to find a way to cancel the encrypt session data behavior in rails. Does anyone know how to wirte it in rails config file?
Thanks!
The encryption scheme isn't going to change in the Rails code, so it's not a horrible thing to implement the decryption in Java. If you want to take this route, refer to this question. However, if you really want to prevent encryption, it's not well documented, but in config/environment.rb it would probably suffice to make sure that the hash in config.action_controller.session does not contain an entry with the key :secret. Make sure you secure your database with other means though!

Categories