Ask / Submit
3

fingerprint reader unlimited retries when display is off

asked 2019-07-21 03:49:09 +0300

Fuzzillogic gravatar image

updated 2019-07-25 19:58:23 +0300

On the Sony XA2 in SFOS 3.1.0.11, when using the fingerprint reader to unlock the device, you can use a registered finger to activate the device (i.e. turn on the screen), and then tap the fingerprint reader again to actually unlock it. When the display is on, either by fingerprint reader or power button, you have 5 tries to use a registered print to unlock the device. After that, you can't use the fingerprint reader and have to enter the security code. This is a good security practice.

When the display is off and tap the reader with an unregistered finger, the display will remain off. Only a registered finger will activate the display. However, you get unlimited retries while the display is off! The limit of 5 unrecognized scans does not apply. This weakens the security of the device.

[edit] When the limit of 5 retries is reached and you have to unlock the device by security code, you can still wake the device when using a registered finger, but not when using an unregistered finger. Thus, even when security locked, you can have unlimited retries to find a registered finger.

edit retag flag offensive close delete

Comments

It is never a good idea to use the fingerprint to unlock. Where is the problem to enter an unlock code?

4carlos ( 2019-07-21 07:36:39 +0300 )edit

@4carlos, that's personal preference. I'm aware of the risks, but I prefer the ease of access. Either way, it has nothing to do with this issue.

Fuzzillogic ( 2019-07-21 11:48:04 +0300 )edit
1

I don't understand the problem. You still cannot unlock the phone with your registered finger once the 5 tries has passed. Let me put it differently: What is the difference between using the power button or a registered finger to wake the display? Either way, the phone is still locked. Having false-positive registers when the display is off could happen easily (And thus more than 5 times) with the phone in a pocket for instance.

Nova ( 2019-07-26 10:39:12 +0300 )edit

@Nova by that logic there isn't any need for a maximum number of retries at all. However, the fingerprint reader can give false positives, as in, an unregistered print passes a registered print.

Fuzzillogic ( 2019-07-26 18:29:36 +0300 )edit

@Fuzzillogic :

What threat model are you thinking about ?

Somebody trying to bruteforce the fingerprints by repeatedly 3D-printing fingerprints until they find a match/false positive, (which won't open the phone anyway because it's going to be way more than 5 attempts) and then they return the phone, hoping that the target won't notice the absence and will unlock the phone with PIN (which will reset the prints counter), at which point the attacker must re-steal the phone and unlock it with the false positive to finally gain access?

(Or am I missing a more obvious less contrived threat?)

Because if you're fearing an attacker that is motivated enough to jump through all these hoops, you're a major target and thus should shouldn't rely on flimsy security like PINs and fingerprints, but should better use encryption and long random passwords (and physical key if possible).

DrYak ( 2019-07-27 11:23:33 +0300 )edit

1 Answer

Sort by » oldest newest most voted
2

answered 2019-07-29 11:21:54 +0300

spiiroin gravatar image

Some background info / rationale for how it is ...

Unlocking device happens in context of unlock UI - which has been designed with lock code entry in mind (i.e. it is active only when interaction with user is possible) -> implicitly requires that display is on before unlocking can happen.

Waking up device happens and must happen under mce control, and is governed by various policies involving proximity sensor, call state, alarms, etc.

So the first decision that needed to be made was either to make unlock ui & mce to share a lot of state data - which takes design and development time and adds complexity which then makes mishaps/errors in security critical area more likely, or handle "fingerprint wake up" as something completely separate from "fingerprint unlock" -> the latter was chosen (well, it was also the only option that was feasible development time wise).

Now then, when handling such separate "fingerprint wake up" one must consider things like:

  • Whether/when it can be activated -> Activation policy is handled in device specific configuration files depending on scanner behavior in suspend, power consumption, (proximity) sensor reliability, etc. (#1)

  • Whether it should act on any fingerprint or only on registered ones: Allowing anything resembling a finger to wake up the device would both make pocket calls etc more likely and actually be more complex (and possibly more power hungry too) to implement than using only registered fingers ...

  • Limiting wake up attempts similarly to unlocking has some issues too: Due to separation of wake up vs unlock the counters would need be separate too i.e. we could end up in situation where one is active while the other one has gotten disabled - how would one indicate such situations to the user, especially when no visual clues can be used for wake up part (display is off after all) -> wake up attempts are not limited - at least for now.

Also noteworthy: Unlocking with fingerprint is possible also from "Sneak peek" aka "glance ui" aka "lpm". Which means that in devices that have a fingerprint scanner and which do support lpm -> Taking phone out of pocket / stte will wakeup the display -> Placing the finger on scanner will unlock the phone -> Single press unlock is possible. Unfortunately, due to problems with proximity sensor, lpm is more or less defunct in some devices such as XA2.

note#1: Users can tweak these values with mcetool, execute mcetool fingerprint-wakeup to list relevant options.

edit flag offensive delete publish link more

Comments

Thanks for the info! It explains the need for the double scan to unlock on the XA2. Still, I'd prefer to see that unregistered attempts to wake the device also tally up to the limit. Until then # mcetool --set-fingerprint-wakeup-mode=never should prevent that loop-hole: first you have to wake the device by other means (i.e. power button), then you can use fingerprint reader to unlock.

Fuzzillogic ( 2019-07-29 19:55:08 +0300 )edit
Login/Signup to Answer

Question tools

Follow
6 followers

Stats

Asked: 2019-07-21 03:49:09 +0300

Seen: 321 times

Last updated: Jul 29