First of all, using MD5 to hash passwords is a bad idea. You should decide whether or not to hash and, if the answer is "yes", do so in the appropriate manner (i.e. using a hash algorithm for this purpose, which employs a salt and a working factor).
In general, the password hash is based on the following scenario: "I have a database, serving an application that can be accessed over the internet; if someone gets a copy of this database - via SQL Injection, or through a backup found in the trash, or whatever - I don’t want that person to be able to immediately see what the users' passwords are, and so log in as if it were them".
According to the above description, ask yourself:
My app can be accessed remotely?
If the answer is nay, there’s not much point in hashing passwords - keep them in plain text anyway. Because who has the physical possession of the device does not need the password to access - and even modify - your Sqlite database.
Is there any scenario where someone unauthorized can get a read (and read only) copy of my database?
I have difficulty imagining such a scenario. Maybe you lent your phone to someone malicious, and this person found a vulnerability in your app and used it to get a copy of the bank? Without the first item of "remote access" this scenario seems to me a bit exaggerated... See if you can think of any other.
If such a scenario exists, then the ideal is to hash it properly (see linked question at the beginning of this answer). In this case, the user should not be given the option to recover his password, but to reset it.
Password hash is not a panacea: it serves very specific purposes - 1) Protect the password itself (i.e. your system has already been hacked, it’s gone! But you don’t want the attacker to take advantage of it to invade others systems where the user reused the password); 2) Prevent a reading vulnerability from scaling to a full write/access vulnerability.
If this answer has not solved your doubts, please detail better which is yours threat model (Threat model) - describe what this password looks like, what it protects and how important it protects, and what the consequences of it being "leaked"; cite the scenarios where you expect a hashed password would be better than a simply stored password, or other possibilities of misuse of your app that come to mind. Etc..
P.S. A last point, about "recover password/access by email": on your mobile phone you can access your email? Without needing any password? Because the person who is in possession of it and is "barred" from accessing your application because of a password, can not simply ask to reset the password by email and then read, on the device itself, the reply of this email?
Thank you, you gave me doubts I didn’t even know I had :D
– Thallyson Dias
On devices with root access you can easily access the sqlite banks and read or modify anything in them...
– Jader A. Wagner
@Jader As a matter of fact! If the threat scenario is this, nothing will help to protect the bank, so a plain text password is enough (i.e. hashing is a waste of time). The same goes for cases where the bank is inaccessible to the user via file explorer, accessible only to the application (I do not know well of Android, but remember that there is this mode, or something like). To reiterate, hashing is only for scenarios in which it is anticipated that an attacker can read - but not modify - the contents of the bank. (or when the password is used for something else too)
– mgibsonbr
It’s an app that hides images and videos... He sets up a gallery, there to access the application and see the gallery of images and videos, need the password. I know this part of the application with internet access (which is not my case), but with an unencrypted password, one can open the bank with an explorer or even Sqlite app and view/edit the password easily. Considering that my app can hide even content of great importance (such as intimate videos), to happen would result in an unfortunate 1 star in the rate of my application
– felipe.rce
I also know there are ways to "decrypt", but at least I would be protecting against laymen or users who do not know how to "decrypt". One more security
– felipe.rce
@mgibsonbr I edited the reply by adding my comment. And Jader, there are already applications that give access to the database (view) without requiring root.
– felipe.rce
+1 Great warning. MD5 is not recommended for passwords, today is used to check file integrity.
– g.carvalho97
@g.carvalho97 So do you have an example of another type of encryption or other solution for my case? The text that mgibsonbr linked is very large, I have not yet read completely because I am at work
– felipe.rce
@Felipe.rce See my response to a brief summary of the commonly used encryption. Still, I recommend reading the article that mgibsonbr posted, is a great read.
– g.carvalho97
@Felipe.rce You need to have clear in your head the distinction between hashing and cipher - the first is unidirectional (you can’t do the inverse function), the second is bidirectional (an encryption operation, another to decipher). And in the same way that it makes no sense to lock a door and leave the key hanging on the lock, if you want to "hide" files you need the password - or equivalent - that opens them is not stored in the application itself. Whoever gets a copy of the bank does not need to crack the hash - just look at the files themselves! (if these are in original format)
– mgibsonbr
If they nay are in original format - i.e. if they are encrypted - then the encryption key cannot be stored in the application, in no format. She has to be derivative password, stored only in memory, and quickly "forgotten" (leaving no permanent records). For this reason, the requirements of "allow user to recover/reset password" and "use password to protect files" are irreconcilable. You need to set a threshold from which you throw the towel: "I will try to stop casual attackers, but whoever has access to X has access to everything".
– mgibsonbr
@mgibsonbr in fact what I’m giving importance is just trying to make it difficult for someone to open the bank and read the password, taking out the parts of breaks, Brute Force, etc. I don’t know much about cryptography, I’m still researching
– felipe.rce
I’m not looking for advanced features and great security, until because I don’t have as much knowledge about. For now I only need to "camouflage" the password, so I ended up using MD5...
– felipe.rce
Of course, if it’s to add a little extra security, that would be great, but if it’s a lot more complicated to add that security, for me it’s not good for now... I am still studying
– felipe.rce
Blz, it is not my intention to discourage you from going ahead with your project, but simply to "put your cards on the table" so that you make conscious decisions. You want to stop casual attackers, but I ask: someone who opens and reads your comic can still be considered a casual attacker? If you consider "yes", and want to prevent it from discovering the password just by taking a look (even if it can look at all the data the password protects), then: 1) use one of the suggested hashing algorithms (Bcrypt is good, but if it is difficult to find a good implementation, PBKDF2 can be more accessible). And...
– mgibsonbr
– mgibsonbr
@mgibsonbr if I could accept two answers, I accepted yours, they were important to clarify my ideas, I was able to solve the problem, I do not know if it is a gambiarra, but for now it is the solution I found (and tested), take a look at my answer.
– felipe.rce