PIN code and Android app data security. How to implement correctly?

Question

Android

Good afternoon. I'm sorting out with the secure storage of information in my Android application, and I came across an interesting point: can a PIN code for entering the application (self-made) be considered sufficient protection?
Suppose an attacker has physical access to the device (well, he stole it, why not? why not an attack scenario?). In the simplest case, if the developer has not thought about the security of data storage, you can either simply open the application and get access to all the information interesting to the attacker, or merge the DB file (sqlite, for example) and extract all the data by opening it. this leads to the following conclusions:
1. Protection is required to enter the application (PIN code or password)
2. All data must be stored in encrypted form.
The idea is simple - the user has a certain, given by him, master key, which encrypts all information (DB). The key is large and long, and so that the user does not have to enter it every time they enter the application, we enter a new entity - a PIN code to enter the application (4-digit code). The master key itself is stored on the same device in encrypted form, and the key is a PIN code (more precisely, a derivative of it. For example, an MD5 hash). In this case, everything looks very safe, right? But if you think about it, simulate the situation. then everything becomes much sadder.
Let's say an attacker stole the victim's device and leaked the encrypted application database. Further, an attacker can use a banal brute force (10 ^ 4 combinations - a trifle) to go through all possible PIN code options until he finds the right one. To do this, you need to know the algorithm of the application, which is not a significant problem. One of the rules of information security says: you can not consider a secure system, all the protection of which lies in the secret of the protection mechanism (paraphrased in his own words for the appropriate case). It is not difficult to learn the method of protection. Further, if the database decryption procedure produces even complete rubbish, it is enough for an attacker to open a copy of the database with a known PIN code (put the application on his device, set the PIN, fill in the data, open the database) and find the data storage structure,
1. All "protected" and "private" user information
2. A known correct PIN to enter the application.
And I don't know which is worse. Let's assume that the application for the bank-client is protected in this way. In this case, knowing the PIN for entering the application and having physical access to the device, it is not difficult for an attacker to transfer all the user's funds to himself (PIN is known, SMS will come to this very device).
This leads to the conclusion: if all protection is based on a PIN code (vulnerable to brute force) and it is possible to brute force, then protection is worthless. But at the same time, all banking applications use this (or similar) protection mechanism.
Hence the question:
1. Is it really so bad and you can not trust such applications?
2. Is it possible to develop a normal, hack-resistant system using a PIN code to enter (not a graphic key and a fingerprint, but a short and easily sorted code)? If so, how?
Z.Y. I am sure that I do not know something important, and this makes it difficult to understand the issue.
UPD:
In general, the problem seems to be unsolvable. Because there is a "black box" - our application installed on the device. To get all the data, you need to know only a four-digit pin, and it is brute-forced at once. It is believed that having a device on hand, an attacker can pick out any data from there. And hence the question - is the last statement true? Maybe there is some kind of super secure Android storage? Stored locally on the device and hard enough to hack? If the application will have access there - write the key there, and the problem is solved. But what is this mysterious place?
UPD2:
So I found this article. Everything is clear enough. The conclusion is simple - you need to store the keys in the KeyStore, but this is not a salvation if the device is rooted. You need to check if the device is rooted and warn the user. BUT! As far as I understand, it is possible to root the device without losing data , which means that an attacker can root the device, saving all the data, and picking KeyStore. Trouble.
But if you don’t go into the problem of rooting, then the solution is as follows: the PIN code is used to enter the application, and the application pulls the key generated when the application was first launched from the KeyStore and decrypts the database with it. At the same time, it does not save the decrypted data in an insecure place (this is often used to increase the speed of the application, a kind of data caching), because this data can be pulled out without problems.
Now it is clear why many banking applications do not run on rooted devices. But this does not solve the problem of rooting without data loss. Those. let's say that an attacker stole my non-rooted device, rooted it, pulled the key for the bank-client application from the KeyStore, and pulled out my data. At the same time, to check the correctness of the PIN, it is necessary to store its hash somewhere (encrypted, salted - so what? And the encryption salt and password are in the KeyStore already accessible to the attacker). Thus, by brute force, you can select a PIN to enter the application, enter the application and transfer all funds. Remove all banking applications, or what?))

Answer 1

Look towards Firebase authorization.

Answer 2

It is not that simple. Most often, if you see an encrypted database, then this is SQLCipher . The key to encrypt the base will be unique for each device, and decryption will take an indecent amount of time.
As for the pincode, you make a delay or block after a certain number of input attempts.
It turns out quite a reliable system. It is enough for the attacker to pay attention to other methods.

Answer 3

one.

SMS will be sent to this device

Block the SIM-card and the account - the problem is solved
2. Obtaining the status of the SIM-card: here
3. All important operations are confirmed via SMS or a call from the bank operator.
4. The application can erase the client token (received on first login from the server) on startup based on any number of factors. And the discovery of data - only with him!
5. Validity period of the client token is limited.
6. The application can send a request via SMS to the bank's SMS service to generate a new PIN code, which will have to come in SMS.
7. Behavioral factor: a face from the front camera (or its complete absence), launching an application from a new location, etc. -> same as in item 3.
You can screw the NFC module of the phone together with a contactless payment card)
If it is not attached to the phone, no pin code is requested.