What option do we have in Xamarin Forms to store api key, password etc. instead of hardcoding

dugguduggu USMember ✭✭
edited March 15 in Xamarin.Forms


Many times we use 3rd party APIs within our app which require secret data to be passed such as API key, token, owner credentials etc. and I don't want to hardcode those as strings within the source code as it can be easily reverse-engineered.

Is there any out-of-the-box option or plugin with Xamarin.Forms to store or obfuscate such data in source code? What are the best practices around this common problem specially in mobile world?

Best Answer


  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    Encrypted string in SQLite db deployed with the app.
    That way you can download new through your own service when they need to renew (annually?)

  • dugguduggu USMember ✭✭

    @ClintStLaurent said:
    Encrypted string in SQLite db deployed with the app.
    That way you can download new through your own service when they need to renew (annually?)

    Hi @ClintStLaurent

    Thanks for your prompt response as you always do.

    Reg. the option you suggested, if I store the encrypted data in SQLite db, I would also need a decryption logic in my app which is definitely part of my source code. And if someone can reverse engineered it, it can easily be identified as I'm deploying the DB also with the app. I think this option is good for POC projects but not the best practice for Production ready secure apps. Please correct me if I'm wrong.

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭
    edited March 15

    Then don't store it in the app at all. At launch it has to get it from your service on line at run time.
    But there are network sniffers.

    In the end... Nothing is bullet proof. Even industries with teams of 100 people in the anti-hacking department still get hacked.

    You have to decide at some point what is an acceptable risk/reward/threat/work balance. People tend to not bother spending $5,000 in labor and another $5,000 in equipment to hack a $1.99 app for its 3rd party API keys that also have to match the .apk name using them - because there's little point to it.

    Of course not all API have to also match the program name using them. But all the ones we use do. Otherwise a developer could pay to use it in one app and then use it in 20.

    So unless you're worried the hacker is going to spoof your app right down to the com.company.product.name of the APK it may not be as big of a threat as you're worried about.

    I'd be more concerned about customer data than license keys.

    Thanks for your prompt response as you always do.

    Have to do something at work to stay awake. :smiley:

  • dugguduggu USMember ✭✭

    Ok. Now I see your point and it makes sense until we store just API keys, access tokens etc. in the DB securely.

    What about few APIs which require owner credentials to be set or passed? One example of such API is Github API where I would like to create issues under repository using its API and this requires me to pass owner credentials while calling the API.

    With this DB encryption option, I could keep my credentials encrypted in DB but I believe this is not the safe option. As a workaround, it would be better if I create a secondary user for the repository and use its credentials in the app rather than my original.

  • dugguduggu USMember ✭✭

    Totally agreed!

    What I learnt - The best way to protect secrets is to never reveal them in the code in the first place. Compartmentalizing sensitive information on your own backend server/service should always be our first choice.

    I personally found the same practice suggested by guidelines in the mobile world:


    I'm from web background and we often do this on server side and sometimes even protect *.config files (containing sensitive information) using machine.config. But was curious about how to achieve the same with mobile tech. (probably one way is to use Android's Keystore API but that is for dynamically collected information I guess).

    Anyways, Thanks @ClintStLaurent <3 for sharing your experience and detailed insights. This helps me to close this topic and accept your answer in the case of APIs requiring owner's credentials.

Sign In or Register to comment.