FIDO: Add credential selection #2463
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@TheMartinizer |
…l selection fragment
…lector list, to stop Gradle from failing on Github
TheMartinizer
force-pushed
the
credential_selection
branch
from
4414652 to
6b379ef
Compare
|
All right, I rebased the credential_selection branch onto the current microG master and pushed it again! Thanks to you guys for looking through the other pull requests, and I'm glad they were useful! :-) |
|
Certainly, it is a very good contribution. |
ale5000-git
changed the title
|
Woah, will this totally add support for microG to manage/store/use Passkeys? It'd be really great for this to work without being signed into a Google account. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It was near impossible to start working on credential selection without touching code that had already been touched in my previous pull requests, so this pull request contains all the code of pull requests #2194 and #2199, and builds on top of that. Sorry I couldn't find a better way to do this.
If there are several available credentials when trying to sign in to a web page and the allowList is empty, the user is now brought to a page that displays a list of available credentials. The credential chosen from the list is used to log in to the page. If the credentials are taken from the Screen Lock credential store, each credential in the list also has a button to delete the credential (I didn't find another, better place to put this functionality).
Each time a user tries to sign in or register a new key using the ScreenLock mechanism, the key store is cleaned up by deleting invalidated keys. Keys can become invalidated for instance if the user adds new fingerprints to their biometric reader. User info (including display name and icon) is tied to each credential key using an SqLite database in ScreenLockCredentialStore.kt. Each time the database is accessed, it is pruned by removing entries that refer to keys that no longer exist, for instance if they were deleted or invalidated.
Since Android keys require biometric authentication to be unlocked, and we don't know which credential to unlock until the user has selected it, the AuthenticatorActivity no longer receives the credentials themselves, but instead an asynchronous function to get the credential. In case the credential is already available (such as for credentials from an NFC or Bluetooth key), this function just returns the credential directly. In the case of Screen lock credentials, this function prompts the user for biometric authentication and uses this to unlock the key from the keystore, and then returns the credential.
I have tested this with NFC and Screenlock credentials on my own phone. I don't have access to a Bluetooth key, so this is still untested.
At the moment, the list of available credentials from the Screenlock method is shown before the user has supplied any biometric authentication. If you think this is a security risk, I could change it so the user has to provide authentication before being shown the list, but in that case I think the user would still have to give biometric again later to unlock the chosen credential.