kee-org / keevault2 Goto Github PK

Are there any plans to make a Windows client? You can use flutter to make a Windows client reusing the same code as your android client.

If there are hundreds of entries to filter, it can sometimes be unclear that anything is happening after text is entered, particularly on slow devices.

e.g. if (e.error is SocketException && e.error.osError is OSError && e.error.osError.errorCode == 7) might let us ultimately inform the user about the specifics of why we couldn't connect to the Kee servers and thus narrow down the list of potential solutions.

Since 99.9% of issues are going to be resolved by just trying again later, this is not a high priority task but anyone that wants to take a look can start with where this exception is thrown and caught. E.g. in the DioHelperHandleException

In remote_service.dart: _doRequest , we automatically retry a few times if the connection fails. That sorts us for 99.9% of failures but some edge cases could still be recoverable if we were to introduce some short delays to the retry attempts, depending upon what we can estimate the cause of the failure to be.

Service changes:

• Create a new DB field to store a hint up to 128 characters long
• Field contents will be encrypted using same PII encryption key as used for customer email address
• Create a new API endpoint to receive a user's request to see their hint
• API will be public but rate-limited
• API endpoint will record user's email address and hint (both encrypted) in a pendingHintEmail DB, along with timestamps and request metadata
• Changes to that DB will trigger a function to send an email to the user
• Email will contain the hint if available, general tips on trying variations of a theme and a link to start the account reset process if all else fails

App UI changes:

• Add a "send me my hint" button or link at the same places as the account reset process can be requested.
• Add an optional field to the account registration page in KV1 (and 2 if Google/Apple ever allow us to register users within the app)
• Add an optional field to the account management page in KV1 (and 2 once that is implemented for changing the password)

Given that this is a lot of work and users can workaround the absence of this feature by recording their hint somewhere else, it's not a high priority task but it would add an additional level of reassurance to the user during the initial account signup.

Android only tells us that the password is for "com.android.settings", which is such a vague identifier that we have to ignore the autofill request entirely.

We could try removing that application ID from the permanent exclusion list and adding it to a new list of vague IDs. Applications on that vague list could be autofilled by a Kee Vault user but only temporarily - they will have to search for the desired password every time rather than us remember their preference in future like we do for most apps and websites.

Is there a preferred security contact address for this project?

We only need this 2nd read for subscribed users that might be working on their Vault while a new one is being downloaded and merged in the background (or in the rare case when a free user first attaches to an existing remote account). So we could defer the read/unlock effort until really needed if we know we have no current User.

Low priority since we will first investigate if we can make changes to the sync operations so that they can be really done as a background operation while the app is not even open and thus remove this 2nd read operation for all users at the same time.

For the rare occasions where someone is trying to work out how to import a kdbx file to their Kee Vault, it would be cool if we could offer a way to push the file directly from the native file management app into the Kee Vault Import process. No doubt this is a platform-specific piece of code so won't be trivial to implement.

Will need to make sure it can be done in a safe way that doesn't cause existing unsaved changes to be lost so probably has to be some sort of cached location for the file first and then notify the user that it's ready for import when they are ready to confirm the operation and then enter the file's password.

For the time being at least, users can just use the existing Import feature to select the file so this isn't a high priority enhancement.

We currently select the root group but it would be better for the user if we selected the next possible ancestor in the group hierarchy.

Currently we need to handle this in group_tree.dart (reFilter) and filter_cubit.dart

Maybe a parcelable unique ID?

Current implementation relies on consistent JSON stringification of Android-supplied metadata so not sure if one of these issues can occasionally occur:

• App fails to return to normal mode after restore following aborted autofill save attempt
• App fails to save supplied credentials if they are the same and from the same source as the most recent request to save

We can safely store argon2 key stretching results anywhere that we store the master key for a KDBX file.

At the moment that is via the encrypted storage provided by the biometric_storage plugin.

If we can find a neat way to marshal the resulting hash between the KDBX library, KeeVaultKdfCache instance and QuickUnlocker instance we could accelerate the initial unlock speed of any database we already hold the decryption key for.

We also need to account for master key changes and wouldn't want a failure of the biometric system to break the existing cache implementation that speeds up subsequent unlock operations while the app remains in memory.