keepassium
commented
5 months ago Your description/terminology differs a bit from the standard terminology of KeePass ecosystem, so there is still quite some space for misunderstanding left. For instance: there is no metadata; the master key is used for encrypting the database file as a whole; without the master key, there is only an encrypted binary blob of a file.
But we can pretty much stop at the premise:
Imagine this scenario: some background process could be cloning my cell phone.
What exactly you mean by "cloning my cell phone"?
If there is a background process that copies device files to a cloud — which process is otherwise known as iCloud Backup — this is not an issue. Database files are always encrypted and completely useless without the master key.
If you mean a background iOS process that makes a memory (RAM) dump of the device — well, the game is over. If you expect a malicious iOS process capable of running in background for long time, breaking out of its sandbox, and accessing physical memory of another process — this is a multi-combo of three major vulnerabilities. For threat actors of this level, you would need completely different tools (air-gapped devices, one-time pads, underground bunkers, etc)
What is the benefit of separate password for each field, as compared to a passcode for the app + database password?