Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

iOS built-in authenticator and auto-fill of authenticator code #190

Closed
polymorpher opened this issue Nov 10, 2021 · 2 comments
Closed

iOS built-in authenticator and auto-fill of authenticator code #190

polymorpher opened this issue Nov 10, 2021 · 2 comments
Labels
enhancement New feature or request frontend infra Frontend infrastructure stuff (state management, etc.) ui

Comments

@polymorpher
Copy link
Owner

polymorpher commented Nov 10, 2021

iOS 15 and macOS Monterrey now support built-in authenticator, secured by Apple's FaceID and various other technologies. We will make 1wallet fully support these new features for wallet setup and all operations. This means the user may authenticate themselves using FaceID, biometric sensor, or standard password (of their device), after they setup the authenticator-code using iOS / macOS built-in authenticator.

The built-in authenticator will be automatically fill in the code wherever applicable. The seeds will be stored in the user's devices securely under their (Apple) keychain. If they sync their iCloud keychain, these seeds will be automatically and securely backed up to iCloud (encrypted).

Note that this does not prevent the user to setup the authenticator code on their Google Authenticator at the same time. It does not disrupt any existing mechanism.

Since the built-in authenticator does not expose seed, this implies we will add a new mechanism for restoring wallet, so that users solely rely on Apple built-in authenticator may still restore the wallet, and users using other authenticators won't need to go through the ordeal of exporting QR code from Google Authenticator.

The planned mechanism is similar to an initial design proposed in the Wiki for consecutive OTP: after the user correctly provides six successive authenticator codes, we will let the user set up a new authenticator code (via either iOS built-in authenticator or Google Authenticator). See #191. The new authenticator code and the old code will both be accepted by the wallet.

@polymorpher
Copy link
Owner Author

Note, in practice, I noticed the user has to have an account (at minimum, a password) saved for the website to trigger the prompt in the OS to save the OTP seed (i.e. "verification code setup" in Apple's language) for a specific domain, instead of the (system) prompt that asks the users to choose a domain (a.k.a "website" in Apple's language). This means we should ask the user to optionally choose a username/password before checking whether they want to use built-in authenticator. The optional username/password can be used to backup the local state (and partial proofs) of the users' wallets.

References:

https://developer.apple.com/videos/play/wwdc2021/10106/

https://developer.apple.com/documentation/security/password_autofill/enabling_password_autofill_on_an_html_input_element

https://developer.apple.com/documentation/authenticationservices/securing_logins_with_icloud_keychain_verification_codes


@polymorpher polymorpher added enhancement New feature or request frontend infra Frontend infrastructure stuff (state management, etc.) ui labels Dec 9, 2021
@polymorpher
Copy link
Owner Author

Fixed in #306

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request frontend infra Frontend infrastructure stuff (state management, etc.) ui
Projects
None yet
Development

No branches or pull requests

1 participant