Distributing API keys after user verification

Question

I'm building my first app and part of it includes access to a database and a connection to a server. What I have set up is the user inputs their credentials to the app and they get sent to the server. The server checks whether or not those credentials are correct. If they are, the server sends the encrypted API key to the app and the app uses the database API on its own. The key is not saved, only used while the app is running.

What I would imagine is more secure, although far slower and more painful to design, is requiring the app to send queries and commands to the server (who holds the API connection) and the server relays the results to the client (app).

Am I going about this correctly? If not, should I be using the latter strategy, or some other strategy?

I don't see why you need an API key at all. If you have a server then the user gets authenticated and can access the server's APIs through some kind of session key. The database and anything that else you're building should not be exposed to the Internet. If you're talking about a third-party API then it depends... — Artjom B., Oct 17 '20 at 23:13
It's a third-party database, hence the concern about distributing the API key. This isn't a major project so I don't expect top-notch security, but I feel as if this problem is a fundamental that I should know. — Dominic Tarro, Oct 18 '20 at 21:09

score 2 · Accepted Answer · answered Oct 19 '20 at 12:13

Third-Party API Access

...the server sends the encrypted API key to the app and the app uses the database API on its own. The key is not saved, only used while the app is running.

What I would imagine is more secure, although far slower and more painful to design, is requiring the app to send queries and commands to the server (who holds the API connection) and the server relays the results to the client (app).

Yes. it's by far more secure to not access the database API directly because that's a third-party service and you don't have any control of it, therefore you cannot apply defence measures to ensure your database API key is not being abused, but you can if the queries go through a backend you can control.

Am I going about this correctly?

No. In my opinion, a mobile app should never access third-party services directly, because an attacker can use an instrumentation framework to hook at runtime to code of your mobile app that uses the API key to access the database and extract it to later use in its own automated attacks. A popular instrumentation framework to achieve this is Frida:

Inject your own scripts into black box processes. Hook any function, spy on crypto APIs or trace private application code, no source code needed. Edit, hit save, and instantly see the results. All without compilation steps or program restarts.

Can you imagine how easily an attacker can extract all the data in your database without you realizing or manipulated the data on it?

Reverse Proxy

If not, should I be using the latter strategy, or some other strategy?

You should use a backend or a reverse proxy that you have total control of to access third-party services, and you can read more about this in my article Using a Reverse Proxy to Protect Third-Party APIs:

In this article you will start by learning what Third Party APIs are, and why you shouldn’t access them directly from within your mobile app. Next you will learn what a Reverse Proxy is, followed by when and why you should use it to protect the access to the Third Party APIs used in your mobile app.

Now you may say that you just shifted the API key issue to the Reverse proxy, and you are correct, but as I explained in the article you are now in control of mitigating the risk of what is using the database, thus you can apply as many defences as you see fit and/or you can afford.

Protecting the Reverse Proxy

For example, you can use UBA - User Behavior Analytics:

User behavior analytics (UBA) as defined by Gartner is a cybersecurity process about detection of insider threats, targeted attacks, and financial fraud. UBA solutions look at patterns of human behavior, and then apply algorithms and statistical analysis to detect meaningful anomalies from those patterns—anomalies that indicate potential threats. Instead of tracking devices or security events, UBA tracks a system's users. Big data platforms like Apache Hadoop are increasing UBA functionality by allowing them to analyze petabytes worth of data to detect insider threats and advanced persistent threats.

UBA works based on a negative identification model, by other words, they try their best to differentiate the bad from the good by identifying what is bad, not what is good, thus they are prone to false positives, despite the advanced technology used by some of them, like machine learning and artificial intelligence.

So you may find yourself more often than not in having to relax how you block the access to the API server in order to not affect the good users. This also means that this requires constant monitoring to validate that the false positives are not blocking your legit users and that at the same time they are properly keeping at bay the unauthorized ones.

Regarding APIs serving mobile apps, a positive identification model can be used by implementing a Mobile App Attestation solution that attests the integrity of your mobile app and device it is running on before any request is made to the API server, and I recommend you to read this answer I gave to the question How to secure an API REST for mobile app?, to understand more about this concept.

Do You Want To Go The Extra Mile?

In any response to a security question I always like to reference the excellent work from the OWASP foundation.

For APIS

OWASP API Security Top 10

The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.

For Mobile Apps

OWASP Mobile Security Project - Top 10 risks

The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.

OWASP - Mobile Security Testing Guide:

The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.

Your mentioned risk regarding hooking the mobile app might be alleviated if the API key for the third-party DB API is created on a per user basis and the authorization is enforced in the DB itself. That also means that the server app needs to update the authorizations in the DB, but that is perfectly doable. The server might even go so far as to only hold authorization logic in the DB. — Artjom B., Oct 19 '20 at 19:55
Access to databases data should always be done in a user/role based way, but in my opinion never directly from the mobile app or web app, that is just asking for trouble, like a data breach ;) — Exadra37, Oct 20 '20 at 09:47

score 1 · Answer 2 · answered Oct 19 '20 at 12:02

If they are, the server sends the encrypted API key to the app and the app uses the database API on its own. The key is not saved, only used while the app is running.

It's considered as not secure practice to give any client the directly access to the data/database layer. You cannot prevent the client to execute unauthorized operation or enforce consistency of the business data. Sending queries and commands is just extending the issue.

What I would imagine is more secure, although far slower and more painful to design, is requiring the app to send queries and commands to the serve

The common approach is using APIs. It means expose necessary operations as granular services. You can expose services, which validate the user authentication and ensure proper authorization and data integrity and consistency. APIs will as well decouple the client application from the database layer.