This project has moved. For the latest updates, please go here.

Security of QuickUnlock?

Apr 6, 2016 at 4:56 AM
What are the security features built into QuickUnlock? I.e. how does it work?

The homepage says "First: it allows you to use a really strong password, this increases safety in case someone gets your database file. Second: If you loose your phone and someone tries to open the password database, the attacker has exactly one chance to make use of QuickUnlock."

But, if an attacker has your phone, can they somehow get at the data QuickUnlock protects for an offline attack? What prevents that? Does QuickUnlock somehow encrypt the master password with a portion of itself, holding it in memory? Or is Keepass2Android just storing the full master password in plaintext and discarding it if the QuickUnlock code doesn't match? Does it work in some other way? Is the database itself re-encrypted while QuickUnlock is waiting for entry, or is the full database available in system memory, just relying on the app to authenticate the attacker with a short code?
Apr 19, 2016 at 8:44 PM
I'd like to know the answer, too.
May 3, 2016 at 9:21 AM
I'm also interested in this answer, so that I know if I can use it or not.
Coordinator
May 12, 2016 at 7:07 PM
Keepass2Android relies on RAM being safe on Android. Every other app does this as far as I know, including other password managers, secure messengers etc. (Unfortunately Android does not provide mechanisms for RAM encryption as Windows does.) When the database is opened, its contents are in RAM. If someone could read the RAM, it has your database contents (and your master password). This is the same for the QuickUnlock state.
Encrypting anything with the QuickUnlock code would be useless, it's not a strong password. If someone could get to the RAM contents (even if encrypted with the QuickUnlock code), it would be simple to try all combinations of 3 (or even a few more) characters.
What could an attacker do? As stated above, it would have to be capable of reading an app's RAM contents. Android has a strict Sandbox system which makes it very unlikely that there could be a software attack to circumvent this. Hardware attacks (freeze the phone, disassemble it, read the RAM) may be possible but are extremely sophisticated. If you believe your enemies can do that, they can probably do much more. It's probably unsafe then to have secure data in memory ever.
May 18, 2016 at 4:13 AM
PhilippC wrote:
Keepass2Android relies on RAM being safe on Android. Every other app does this as far as I know, including other password managers, secure messengers etc. (Unfortunately Android does not provide mechanisms for RAM encryption as Windows does.) When the database is opened, its contents are in RAM. If someone could read the RAM, it has your database contents (and your master password). This is the same for the QuickUnlock state.
I think you're saying the database is kept unencrypted, but in RAM only. The password, or a portion of the password, must also be kept in RAM, in order to check the last few characters. I think you're also saying it is not written to a file at any time. This is good; it is not trivial to get at RAM. It may still be possible to get at RAM if an attacker can use some sort of privilege escalation exploit, possibly in an app they download and install themselves, or if you've rooted your phone. Either way it's mostly an issue if you install from 3rd-party stores or if the attacker physically has your phone.
Encrypting anything with the QuickUnlock code would be useless, it's not a strong password. If someone could get to the RAM contents (even if encrypted with the QuickUnlock code), it would be simple to try all combinations of 3 (or even a few more) characters.
Agree, there's not much use to encrypting the RAM with something as simple to bypass as the last few characters of the passphrase.
What could an attacker do? As stated above, it would have to be capable of reading an app's RAM contents. Android has a strict Sandbox system which makes it very unlikely that there could be a software attack to circumvent this. Hardware attacks (freeze the phone, disassemble it, read the RAM) may be possible but are extremely sophisticated. If you believe your enemies can do that, they can probably do much more. It's probably unsafe then to have secure data in memory ever.
I think I'm confident it's safe to use, as long as I can remember to close the database fully when I'm done to minimize the chances of someone finding or stealing my phone and causing trouble. If I can remember to close the app, my password and unencrypted database should be gone by the time anyone picks up my phone.

But I wish I didn't need to remember to close it myself. I think it would be good to have a timeout feature, in addition to the existing quick unlock timeout, that would close the database entirely instead of just blocking access through application controls. I have not seen such a feature, nor a feature request in the codeplex issues page, shall I add one? Or, is this something that won't be considered? Is codeplex even the right place for feature requests? It looks like there is a lot of cruft in the current issues database here.