search

Kunzisoft / KeePassDX

Lightweight vault and password manager for Android, KeePassDX allows editing encrypted data in a single file in KeePass format and fill in the forms in a secure way.
https://www.keepassdx.com/
GNU General Public License v3.0
4.51k stars 267 forks source link

Add device unlock prior to Android 11 #811

Closed J-Jamet closed 3 years ago

J-Jamet commented 3 years ago

Linked to https://github.com/Kunzisoft/KeePassDX/issues/779

lockwise uses deprecated methods for Android versions below 29, implementing these old methods requires a lot of work. https://developer.android.com/reference/android/app/KeyguardManager#createConfirmDeviceCredentialIntent(java.lang.CharSequence,%20java.lang.CharSequence)

Will not be implemented unless funded or a pull request is created.

J-Jamet commented 3 years ago

https://github.com/mozilla-lockwise/lockwise-android/blob/master/docs/architecture/sec-apis.md#using-keyguardmanager

echeoquehaii commented 3 years ago

Hi @J-Jamet !

First of all thanks for looking into the issue so fast!

If the Lockwise implementation is not feasible what about taking into account using keepass2android's approach? They have a so-called "QuickUnlock" feature, which allows to unlock the database using only the last characters of the actual password (the user can decide how many). Also, I think to remember another app which was using a specific pin code, not the device credentials, but one created just within the app to unlock the database. I don't know how complicated it would one of these two options be to implement (I will try to find out which was the app using the custom PIN feature).

By the way what exactly do you mean by subsidized? Unfortunately I have no coding skills so I cannot help with development, but of course I will donate. It's just that my contribution can only be small right now, I imagine it could not cover all development costs of such feature.

J-Jamet commented 3 years ago

It's not that it's not feasible, but it just requires a lot of work.

If the Lockwise implementation is not feasible what about taking into account using keepass2android's approach? They have a so-called "QuickUnlock" feature, which allows to unlock the database using only the last characters of the actual password (the user can decide how many).

I will not implement the method of KeePass2Android because it is completely different, will require even more work and does not satisfy me at all in terms of security (with this method, the database still remains open as I explain in this thread).

Also, I think to remember another app which was using a specific pin code, not the device credentials, but one created just within the app to unlock the database.

Similar, it will require in addition to the previous work to create our own views and UI.

Otherwise, the deprecated method implementation is the right way for old devices, although I suspect that the biometric API will use these methods internally later to make things easier. (It's a guess but I hope it will as this API seems to be redone.)

By the way what exactly do you mean by subsidized? Unfortunately I have no coding skills so I cannot help with development, but of course I will donate. It's just that my contribution can only be small right now, in respect to what I think you would need to cover development costs.

On open source projects, I don't count my time but I spend a lot of my days / months on it, which is a pleasure above all! But when it is a feature which is clearly marked as deprecated by Google (therefore which will no longer be used in the future), and I don't need it, so I am not motivated to do it. Actually, redoing the same functionality differently for each version of Android, it's tiring and not fun at all. If I had to make an estimate on this feature, I would say 4 days of development time to rethink the architecture and the design, properly refactor the classes and the code, do the development, and test. It is very nice to want to give, and it is thanks to the donors like you that I am working on this project but compared to professional projects, it's complicated for me to make a living from them. (To compare, this kind of work is normally paid 500 € / day). So I'm clearly doing it for fun and for my needs above all else.

Maybe the library will be updated with methods that encapsulate the old methods. Otherwise I'll see when I have the time / motivation, especially since I have to manage the new standardized features of KeePass (new encryption algorithms, etc ...) so I have to prioritize things.

J-Jamet commented 3 years ago

Well in real life, I'm going to implement it anyway, it will take just the time or if I'm motivated on a good day. It's just to make people understand that it doesn't just happen from nothing and that there are constraints. I receive a lot of messages by email or from the play store from users giving orders to create such a feature (that's not your case @carallo obviously) ... And that clearly turns me off, I want to make people understand that it is out of passion for free software and that I owe nothing to anyone ! ;).

echeoquehaii commented 3 years ago

It's not that it's not feasible, but it just requires a lot of work.

Yes sorry, it's what I meant, feasible for this situation, in a humanly manner time and effort.

On open source projects, I don't count my time but I spend a lot of my days / months on it, which is a pleasure above all! But when it is a feature which is clearly marked as deprecated by Google (therefore which will no longer be used in the future), and I don't need it, so I am not motivated to do it. Actually, redoing the same functionality differently for each version of Android, it's tiring and not fun at all.

If I had to make an estimate on this feature, I would say 4 days of development time to rethink the architecture and the design, properly refactor the classes and the code, do the development, and test. It is very nice to want to give, and it is thanks to the donors like you that I am working on this project but compared to professional projects, it's complicated for me to make a living from them. (To compare, this kind of work is normally paid 500 € / day). So I'm clearly doing it for fun and for my needs above all else.

Well in real life, I'm going to implement it anyway, it will take just the time or if I'm motivated on a good day. It's just to make people understand that it doesn't just happen from nothing and that there are constraints. I receive a lot of messages by email or from the play store from users giving orders to create such a feature (that's not your case @carallo obviously) ... And that clearly turns me off, I want to make people understand that it is out of passion for free software and that I owe nothing to anyone ! ;).

About all of this, I totally get that. I am no develper (unfortunately, just a med school student) but I really am into Open Source software and philosophy and I know how such software is developed, most of the times. I'd say that sometimes, like in KeepassDX's case, the problem is that such projects are so good that people thinks it's being developed by a software company or similar, while often is just a hobby of someone working on it in its spare time. Maybe that's why people expects so many things from you! :) That's why I usually try not to bother developers much with MY issues, but I also think that if it's done in a respectful and constructive way it actually represents the essence of Open Source.

In the end, I completely understand that this feature is not a priority to you and, if one day it will be implemented I'd be so happy (being a user of an old FP2). I've tried all possible apps but no one is as good as this, not even BitWarden, which is commercial. But if it won't, no worries at all. I am already thankful that you've taken your time to even just consider this.

I just hope one day I'll be able to donate a fair amount to all projects I'd like to, not just tips as now.

echeoquehaii commented 3 years ago

Sorry for the OT, to get back on the issue, I have a last question.

As a kind of workaround to this, for us users of old android versions, how unsafe is it to use a weak password BUT along a strong Key file?

J-Jamet commented 3 years ago

It's hard to say, it all depends on the ingenuity of the attacker. If for example your key file is easily recoverable (and he knows that it is the key file), he can brute-force the password. The brute-force will also depend on the technique used, the number of turns for the KDF, etc... In the majority of cases, it is not the encryption of the file that is lacking, but the ability of the attacker to recover the password and files by other means. The best is still to have a strong password and a strong key file.

shadow00 commented 3 years ago

Just a suggestion: perhaps you could take a look at how Signal does this? They support unlocking the app using the system's Screen Lock and/or fingerprint to unlock the app, and it works at least as far back as Android 7.0 (I know this because I have a device running it - not sure about previous versions). No idea of what you might find, but maybe it could help?

J-Jamet commented 3 years ago

In fact, I was pretty motivated to spend the last 2 days (and part of the night) on this problem refactoring the code. I can use it from Android Lollipop but there are some big bugs to fix.

J-Jamet commented 3 years ago

The basic problem is that the methods aren't used in the same way and I have to review the item load cycle and check for each different version of Android which is very long. I am doing encapsulation classes to harmonize things. Android development is really tough for this, and it's really annoying to have deprecated methods every two Android versions. :zany_face:

J-Jamet commented 3 years ago

Well, it's way too complicated with Lollipop, I have to create a Keystore manually, visual methods don't work, it's horrible, so it will be minimum M for the moment.

J-Jamet commented 3 years ago

I'm moving forward little by little, it works relatively correctly but there are problems when changing orientation. I think one of the solutions will be to encapsulate all of the advanced unlock encryption engine in a fragment. Because the big current problem, (and I see why it has been deprecated), is that the return value of the device unlock activity cannot be easily recovered after a change of orientation because the context is lost, so the cipher is no longer initialized for decryption. This is why in the new methods, the biometricPrompt incorporates the cipher. Here I am forced to redo a substitution architecture just to be able to correctly recover the return request.

J-Jamet commented 3 years ago

There are still some bugs to fix but it basically works. Associated branch: ~https://github.com/Kunzisoft/KeePassDX/tree/feature/Device_Unlock~ Edit: Merged

echeoquehaii commented 3 years ago

Wow! I've been away a couple of days and this is already merged, unbelievable! I thought this would take much more time. I hope you have taken your time to sleep @J-Jamet . I look forward to try this and I don't know what to add, just thank you so so so much!!!

J-Jamet commented 3 years ago

In fact if, I am tired, but like that it is done. ;)