1

I currently have a hardcoded password and username in my program. These credentials are used to access files from a remote server. How can I help prevent someone from going through the source code and figuring out the username and password? (I currently use Proguard for obscuring the code, but I am new to it) Are there alternatives to hard coding the Strings in the application?

I have tried searching around but almost all questions address the problem of storing a user's password and name. I am having a difficult time coming across actually storing the master password for the server the user's credentials are accessed from.

Daiwik Daarun
  • 3,804
  • 7
  • 33
  • 60
  • i'd suggest encrypting it and store it in the app and when it connects the server decrypt it and then checks, you could even add a salt to it, or you could keep the password dynamic always changing depending on some factors like date, ip, time... etc and also encrypting it, i suggest you do more research on android app security, can't help you with any ready solutions as i do not know any. – bakriawad Jan 27 '15 at 20:41
  • Anything in your APK is unsafe. And there is no way to change that. Anyone can easily look at your source code and get any hardcoded constants or resources contained in your APK. The trick is to just forget about all that and stop trying to make your APK more secure. Code your APK like it were open source, it cannot contain any sensitive information you don't want anybody else to have. There are methods of authentication which do not require you to store server credentials in your app, for example [**OAuth**](http://en.wikipedia.org/wiki/OAuth). – Xaver Kapeller Jan 27 '15 at 20:42
  • @bakriawad That does not work. You cannot keep anything secret or safe in your APK. No matter what you do. Any potential attacker could just look at the source code of your app and just replicate the process the app uses to decrypt/encrypt the password. Anybody with enough knowhow to decompile your APK and look for the password can figure all that out in a heartbeat. – Xaver Kapeller Jan 27 '15 at 20:43
  • possible duplicate of [How to securely store credentials (password) in Android application?](http://stackoverflow.com/questions/10990821/how-to-securely-store-credentials-password-in-android-application) – Simon Jan 27 '15 at 20:46
  • @XaverKapeller i think he can store them in a file rather than the source code, the app just reads the encrypted data and sends it as it is.. but for a key to remain static for long is bad.. so it still is not very safe yet more secure than giving it away in the source – bakriawad Jan 27 '15 at 20:51
  • @bakriawad What do you mean when you say storing them in a file? How would the password get to that file? If you use the traditional approach with username/password then you always have to contain the password in your APK. The solution as I already mentioned is to use a method of authentication which does not require the client to have any credentials. See my previous comment. And what's the point of encrypting the password when you don't need to decrypt it to use it as a password? – Xaver Kapeller Jan 27 '15 at 20:55
  • @XaverKapeller i read it and i did learn something new, but i always try to find a solution to a problem.. he wants to connect to a remote location with a username and password, in source it is open, but if encrypt those beforehand and include the encrypted file within the apk file, if that cannot be done then the program just downloads the encrypted file upon first connection.. i do realize it is poor security as some programs can force break it, but it is one way of putting the credentials safely in the APK, upon verification the program just reads then sends the data ignorantly. – bakriawad Jan 27 '15 at 21:07
  • using my method is risky, but the question has gotten a good answer from the top comments so mine is just a little extra thought – bakriawad Jan 27 '15 at 21:09
  • @bakriawad He is asking how to do it securely or what else he can do to make it secure. So OAuth would be the correct solution to his problem. And downloading the credentials on the first start is again completely pointless, because that download needs to be secure too. Otherwise anyone could just download the credentials. So you would again need credentials to download the actual credentials. And as you probably realise that would completely defeat the purpose of downloading the credentials in the first place. OAuth or something similar is the way to go. – Xaver Kapeller Jan 28 '15 at 08:19

1 Answers1

-1

Use Hashing to avoid store credentials in plain text.
Use SharedPreferences to store hashed credentials in local memory.

Read more:
How to securely store credentials (password) in Android application?

Community
  • 1
  • 1
klimat
  • 24,711
  • 7
  • 63
  • 70
  • 1
    That does not work. You cannot keep anything secret or safe in your APK. No matter what you do. Any potential attacker could just look at the source code of your app and just replicate the process the app uses to decrypt/encrypt the password. Anybody with enough knowhow to decompile your APK and look for the password can figure all that out in a heartbeat. – Xaver Kapeller Jan 27 '15 at 20:45
  • @XaverKapeller I didn't say anything about that solution will work for whole universe. I say only about keeping hashed password is a way better than keeping plain text password, because if someone will decompile the source code it will be not enough to get credentials. – klimat Jan 28 '15 at 08:08
  • 1
    How is it not enough to get the credentials? Firstly hashing is a oneway process. The password can never be recovered from the hash without brute force. So if you hash the password in your app, the app could never again recover the password to use it to login. And if you send the hashed password to the server then hashing it in the first place would be pointless. I think you are referring to encrypting/decrypting the password when storing it, but that has not point what so ever. Because anyone can just decompile the app and replicate the process used to decrypt it. – Xaver Kapeller Jan 28 '15 at 08:12
  • 1
    Whatever you do to try and keep things safe in the APK will be pointless. Because everything in the APK is unsafe by design. If you really want to keep something safe you have to store it on a server. And you have to use a method of authentication like OAuth which does not require the client to have any credentials. Because as soon as you introduce credentials into the equation you would have to hardcode them somewhere in some form in your APK, which as I explained above cannot be done securely. – Xaver Kapeller Jan 28 '15 at 08:15
  • At best you can make it more difficult for an attacker, but if he has a reason to decompile your app in the first place then nothing can stop him from finding any resource or value stored in the APK. Trying to make something secure which cannot be secure by design is pointless and just a waste of time. – Xaver Kapeller Jan 28 '15 at 08:16
  • It's **obvious** if someone have **all knowledge** about the process he can reverse it and get any input information that was put to the process. My answer was about put already hashed password to apk to make it a bit harder to read after decompilation. Decompilation is short process, you can do it in 5 minutes, brute force is not, espacially when you have strong password. – klimat Jan 28 '15 at 08:19
  • You seemed to have missed the point I was trying to make. Explain to me: How would the app make use of the hashed password? If you send the hashed password to the server, then there is no point of hashing it in the first place. And as I already tried to explain, you cannot recover the password from the hash, so how would the app get the password from the hash? – Xaver Kapeller Jan 28 '15 at 08:21
  • I assume creadentials for server are static. App has stored them in SharedPreferences. When we need to connect to server we send hashed credentials to the server. Server checks that hashed credentials are valid, if so, we are authenticated successful. What I have missed? – klimat Jan 28 '15 at 08:32
  • That any attacker could just recover the hashed password from the app and use it. Just because you hash something doesn't magically make it more secure. – Xaver Kapeller Jan 28 '15 at 08:34
  • 2
    Hashing is primarily used on the server, so the server does not need to store the passwords of all users in plain text. So in the case of a breach on the server the attacker would just have the hashes which are useless since they cannot be used to login. When logging in the server receives the password from the user, hashes it and compares it to the hash on record. If they match then the correct password was used. This is essentially a trick to allow the server to confirm if a password is correct or incorrect without actually knowing what the password is. – Xaver Kapeller Jan 28 '15 at 08:38
  • @Xaver Kapeller could you explain using Oauth to store these credentials more deeply? – klimat Jan 28 '15 at 08:42
  • The difference between OAuth and the classical approach with credentials is just that the client does not require any credentials to login to the server. I know this kind of seems counter intuitive, but it is actually very smart. In the classical approach the client supplies credentials to the server and the server checks if they are correct. In that case the server is basically just a dump terminal which checks if the credentials match those on record. So anyone who has the credentials can just use them to access the server. – Xaver Kapeller Jan 28 '15 at 09:08
  • With OAuth the whole concept of credentials is thrown out the window (since there is now way to use credentials securely) and the server checks if clients are allowed to access it based on other factors. So instead of having a process where anyone can just use the credentials to access the server, the server has full control of who can access it. This can take many forms, but for example Google Cloud Messaging uses a combination of many different factors like the apps SHA1 certificate fingerprint (which is almost impossible to fake) to make sure that – Xaver Kapeller Jan 28 '15 at 09:08
  • the client who wants to access the server is actually allowed to do so. Once it has been determined that the client is valid the client gets an access token from the server which is a very long string of characters and which can be used by the client to access the server. This access token is only usable for a limited time (depending on how sensitive the data is) and then a new access token has to be requested. – Xaver Kapeller Jan 28 '15 at 09:09
  • @XaverKapeller from wiki: *" OAuth provides client applications a 'secure delegated access' to server resources on behalf of a resource owner. It specifies a process for resource owners to authorize third-party access to their server resources without sharing their credentials"*. Where is 'third-party' in our case? – klimat Jan 28 '15 at 09:38