Are you using always-on display?
Are you disabling animations via either Accessibility or Developer options?
We've found an upstream bug in the Android lockscreen implementation which may explain what you've seen.
Are you using always-on display?
Are you disabling animations via either Accessibility or Developer options?
We've found an upstream bug in the Android lockscreen implementation which may explain what you've seen.
Yes to both. I have always-on-display and animations disabled via Accessibility menu.
Turning the animations back on changed the always-on-display behaviour I described above. It now shows the fingerprint icon and 2FA PIN appears as expected.
Looks like we found the issue.
r_dac Disabling animations breaks always-on display in a strange way. The upstream biometric handling code ends up thinking the device isn't locked and the UI doesn't display properly. After a fingerprint is used, it thinks it was already unlocked and skips a bunch of the code for handling unlocking including our 2-factor authentication feature. This is a serious upstream bug we'll need to figure out how to resolve. We can implement a temporary workaround for it today.
Right on! Nice work again. It's a great feature.
I wonder, if Graphene devs hadn't implemented the 2FA PIN feature, maybe this upstream AOSP bug would have gone unnoticed for longer than it has, because the standard fingerprint option on its own was still seemingly working fine, even with the display issue on the always-on-display caused by killing animations.
This is the fix for the upstream lockscreen bug which impacted more than 2-factor fingerprint unlock but we haven't identified any actual lockscreen bypass with it:
They had code unnecessarily fetching the animation scale as a string and comparing it to "0" so it broke when they changed it from an integer to a floating point number where the string is "0.0". It's a very silly issue.
Since this is overly fragile, we added a defensive measure to protect against similar issues:
GrapheneOS The limit on failed fingerprint unlock attempts in GrapheneOS is 5...
I have now tried it several times. The password prompt appears always after the third failed attempt.
I think it's good and would also prefer one attempt to restrict the use of force to unlock the system, which is increasingly being used by state authorities even in so-called constitutional states (when use without 2-factor).
But I definitely want to understand my system very clearly. Why 3 instead of 5 for me?
asd That's the standard Android behavior. After 3 attempts, it shows the prompt. After 5, it does the initial lockout which is the permanent lockout on GrapheneOS since we only permit 5. Standard Android permits 20 in total with 30 second delays between each 5. The reason for showing the prompt after 3 is to reduce it getting locked out by accident.
GrapheneOS
OK, this is a nice feature, stopping someone from spying on my primary PIN. Thank you for that.
But, wouldn't it be better to have a whollistic two factor authentication approach. Currently you have to enter your primary PIN after phone restart or when you tapped 3 times with the wrong finger on the fingerprint scan, etc.
Wouldn't it be more secure to have a general/whollistic two factor approach, where you always have to use both factors to login/unlock etc.?
Do you plan to implement such a feature?
GrapheneOS Any idea when this might get fixed, or is it just wait and see?
or when you tapped 3 times with the wrong finger on the fingerprint scan, etc.
It prompts for it after 3 failures but you get 5 failures in total, and we can make this configurable.
You can extend the 48 hours after last successful primary unlock by doing primary unlock again.
Wouldn't it be more secure to have a general/whollistic two factor approach, where you always have to use both factors to login/unlock etc.?
No, that would regularly result in data loss. Biometrics aren't reliable enough to be used for primary unlock. The intention is also that people use a strong passphrase for primary unlock when using this feature.