0

I've been thinking about this quite a while and it's bugging my head off, lets say we have a website a mobile app and a database.

Usually when we develop our websites we pretend to store our database credentials in a configuration file and connect the website directly to the database without using a multi-tier architecture, but when it comes to a mobile application such Android or iOS this applications can be engineer reversed meaning that there's a risk of exposing your database credentials.

So I started thinking about this multi-tier architecture and kind of thinking about how Facebook and other social network do their job, they usually make an API and use a lot of HTTP Requests.

Usually social networks APIs have a app_id and a secret_key, this secret key would be used to increase the safety of the application but I'm thinking about how could I store these keys inside my application since I would go back to the begining of my discussion, if I was to use Java I could use the Java Preference Class but that isn't safe either has I saw in this question, plus I would need to make sure my HTTP Requests are CSRF safe.

So, how could I store these keys inside my app? What's the best way to do it, since hard-codding it's out of the question.

Community
  • 1
  • 1
RebeloX
  • 176
  • 1
  • 4
  • 14

1 Answers1

1

You should always require users to log in - never store credentials or private keys in an app you'll be distributing. At the very least, don't store them unless they're specific to the user who has chosen to store them after being validated.

The basic idea is that the user should have to be authenticated in some manner, and how you do that is really too broad to cover in a SO answer. The basic structure should be:

  1. User asks to authenticate at your service and is presented with a challenge
  2. User responds to that challenge (by giving a password or an authentication token from a trusted identity provider).
  3. Service has credentials to access the database, and only allows authenticated users to do so.

There are entire services out there built around providing this kind of thing, particularly for mobile apps.

You might store the users own credentials on the device, and if so it should be encrypted (but you're right, a malicious app could potentially pick them up).

Bottom line: never distribute hard coded access to a database directly.

Dan Field
  • 20,885
  • 5
  • 55
  • 71
  • Yes that was what I thought but the problem here is that I would need credentials to ensure that he cans indeed connect to the a multi-tier architecture, meaning that I would need to store that app_id and secret_key somewhere inside the app, this is covered within the Facebook API as well but they don't explain how to safely store those keys inside the app. – RebeloX Mar 24 '16 at 15:34
  • You need more than just an application id/key, you also need user credentials. Think about it - for the Facebook app to connect, it also needs to know your username and password, which are user entered. – Dan Field Mar 24 '16 at 16:24
  • That makes sense, so you could store those application id/key but the username and the password would come from the user input, am I correct? – RebeloX Mar 24 '16 at 19:09
  • Yes. And if those are stored, it's because the user chose to. – Dan Field Mar 24 '16 at 19:45
  • What about if a user is about to register, would I still store the application id/key inside the app? I mean would I hardcode it? – RebeloX Mar 27 '16 at 18:51