Prototype of using privacy screen and LocalAuthentication #219
Conversation
- Adds Component that: - Checks if device can use LocalAuthentication - Checks if a successful auth challenge has occurred Given that LocalAuthentication is available on the device: When the application becomes foreground after launching a privacy screen is presented. A successful LocalAuthentication dismisses the privacy screen. When the application enters the background state the privacy screen is presented. This prevents tokens from being displayed during app switching. None of the keychain items are using LocalAuthentication for encryption. This is purely UI related so the security/encryption of the keychain items have not been changed by this feature. Tokens are still readable/displayable by the app no matter what the state of the LocalAuthentication challenge is.
|
|
||
| @objc private func authChallenge() { | ||
| let context = LAContext() | ||
| context.evaluatePolicy(.deviceOwnerAuthentication, localizedReason: "LOLZ") { (reply, error) in |
There was a problem hiding this comment.
This localizedReason seems completely correct to me.
Codecov Report
@@ Coverage Diff @@
## develop #219 +/- ##
===========================================
+ Coverage 38.48% 40.47% +1.98%
===========================================
Files 40 40
Lines 1863 1895 +32
===========================================
+ Hits 717 767 +50
+ Misses 1146 1128 -18
Continue to review full report at Codecov.
|
|
@mattrubin not sure if you'll be referencing this PR at all for the local auth feature but I merged it with develop so it's in a buildable state again. |
|
Thanks, @beaucollins! |
|
Do you need any help to update/finish this MR or any other? |
|
Thanks for the offer, @BrunoMiguens! I've built out this feature more on top of Beau's work - you can see the latest at #304. The description on that PR contains a list of improvements that need to be made before the feature is ready for release. The two that are most important - and are perhaps the best place for someone to lend a hand - are:
If either of those seems like something you'd like to work on, PRs are always welcome! I am away from my computer for the next week, but have set aside some time to work on Authenticator when I return, so while I can't review any code immediately, I will have time to look at it next week. |
|
|
||
| @objc private func authChallenge() { | ||
| let context = LAContext() | ||
| context.evaluatePolicy(.deviceOwnerAuthentication, localizedReason: "LOLZ") { (reply, error) in |
There was a problem hiding this comment.
This currently only triggers the passcode-screen, although Face ID is available. Per docs it should try Face ID / Touch ID first. Did you notice this as well?
There was a problem hiding this comment.
Strange! On my phone, it triggers FaceID.
Each app that wants to use FaceID shows a permission prompt the first time it tries to authenticate with FaceID. If permission is denied, it falls back to using a password. If you check in the system Settings.app, does Authenticator have permission to use FaceID?
There was a problem hiding this comment.
It does not prompt for this permission and is not visible in the settings but I can check again!
Having this pull request merged brings this project to a new level of privacy, so thanks everyone contributing to this! 🙂
This comment has been minimized.
This comment has been minimized.
Adds Component that:
Given that LocalAuthentication is available on the device:
When the application becomes foreground after launching a privacy screen is presented. A successful
LocalAuthentication dismisses the privacy screen.
When the application enters the background state the privacy screen is presented. This prevents
tokens from being displayed during app switching.
None of the keychain items are using LocalAuthentication for encryption. This is purely UI related
so the security/encryption of the keychain items have not been changed by this feature.
Tokens are still readable/displayable by the app no matter what the state of the LocalAuthentication
challenge is.