[discuss] UX - Unlock with face id

[Kharchevskyi]

Use face id to "unlock" app Also we can try to save pass phrase in keychain and use face id to unlock keychain to be possible to enter pass phrase

442

[tomholub]

Yes! this will be very helpful.

[tomholub]

This issue should be evaluated as you say. With the option to "keep pass phrase in memory", it is too inconvenient to keep re-typing the pass phrase into the app. It would be great if the pass phrase was saved in KeyChain and could be retrieved with FaceID.

[tomholub]

Current design of the app:

• there is a Realm database, which is encrypted as a whole using a key from KeyChain (unlocks transparently as long as user device is unlocked).
• the Realm database contains user OpenPGP keys, which are encrypted using user-selected pass phrase that has to have some minimum entropy. (a pass phrase like joe halloween brings pudding)
• there can be more than one key, and they could possibly each have different pass phrases (but usually they are the same for all keys)
• the pass phrase can be either stored alongside the key in Realm database permanently, or it can be only remembered in volatile memory (RAM) for a maximum of 4 hours
• choice of stored or memory pass phrase is decided during setup, either by user choosing a checkbox, or by client configuration for enterprise deployments
• if I have pass phrase in RAM, I have to keep typing it every 4 hours or every time I kill the app if I want to open encrypted message, which is annoying

For this issue:

• I suggest there could be a third option, where the pass phrase could be auto-generated and stored in KeyChain, protected by FaceID. This option would only be supported on phones that support FaceID.
  • In the first version, whenever pass phrase(s) is(are) needed, they'd get retrieved from the KeyChain directly.
  • In the future, we can add a 1 hour caching mechanism with the in-memory storage we already use, described above.

(I don't know exactly what possibilities we have when combining FaceID and keychain for our purposes - the above is just one idea)

[tomholub]

From Murat:

To use faceid , one must associate his credentials to faceid, so we should add option to associate any new credential with faceid.

for latest devices , apple lets just the owner of the phone to use faceid ( we don't get a hash, instead it just returns success or fail ) .

This means, if someone borrows my phone to read an email, the phone author will later be able to access to that message using faceid , if not implemented as above . I will today download the project and try to integrate it .

[tomholub]

To use faceid , one must associate his credentials to faceid, so we should add option to associate any new credential with faceid.

What does credential here refer to? What does any new credential mean - can there be more than one credential?

for latest devices , apple lets just the owner of the phone to use faceid ( we don't get a hash, instead it just returns success or fail ) .

So we run a faceid and we get a true/false and that's all? Then the app itself needs to load the pass phrase from KeyChain or something?

Can't it be made more secure to store a secret in the KeyChain that is actually protected by the FaceID, enforced by the OS instead of application code?

This means, if someone borrows my phone to read an email, the phone author will later be able to access to that message using faceid , if not implemented as above

I couldn't follow this - who is the phone author in this example?

[murataka]

I want to explain this as if there was a security level which can be set by the user, say 5 very secure to 1 , secure to the common external attacks (say, some hacker groups trying to hack anything..) .

Faceid is something not very secure , because,

• it allows someone look like the phone owner to unlock it , say twin to be able to unlock.
• When we use the existing api ,

  context.evaluatePolicy(.deviceOwnerAuthenticationWithBiometrics, localizedReason: reason) {
              success, authenticationError in

  success is a boolean value , and there's no other information ( Id of the phone owner ?) , just passed or failed.

In this situation , assume that , I'm an android user who is using flowcrypt, and unluckily, my phone is broken down ( or not enough battery etc. ). Then , I will ask my coworker to read my email from his phone , he will sign-out , give me his phone , I will enter my pass phrase, read-send my emails , and sign-out. After that , the phone owner to unlock the pass phrase either stored alongside the key in Realm database permanently will be able to accessed by the phone owner. As an android user , I had no idea about that because my app does not have that option on my phone ..

So , faceid has some vulnerabilities itself, to the phone owner , or if not implemented correctly, can be used as a tool to attack someone else ( me the android owner). So I think , this should be marked as security level 1 .

If owner wants to use faceid , then whenever a new pass phrase is added , an option must exist with cautions to not associate if you are not the owner of that device ( phone ) . Also a notification mail allowing to remove the association of the faceid and pass phrase would be sent.

If we are storing Information on serverside ,that is stored and associated to the faceid and also associated to the pass phrase , then faceid would be more secure . In this scenario, the android owner never associated his faceid to any of his passphrases before, so if he enters pass phrases to an iphone, app would ask to associate that whit his ID - passphrase or not to. It would be better to add an option to associate auto (taking the android owner into account), or add a button option , according to the security level selected .

[tomholub]

Ok, that makes sense. I suppose we cannot tie a certain face to certain value? Like, "joe" FaceID can only unlock pass phrase A and "bill" FaceID can only unlock whatever other pass phrase they entered with id B. What you say sounds like, as long as they add their face to it, then that's it.

But I wouldn't worry about this particular scenario too much. For one, such use of coworker devices is a gross violation of many security protocols for the kind of customer we are deploying to. Most likely, their mobile device management system does not allow them to sign in with a second email account on their company-managed phone. So we should not worry about this particular scenario.

The only thing that I'm disappointed is that the faceid returns a boolean value, and that we cannot use any OS guarantee to actually protect a piece of data with the FaceID. We have to do this in application code.

Basically:

if(user passed face id == true) {
  // get pass phrase from keychain
}

[tomholub]

Therefore I suppose we could do a compromise, at least for enterprise deployments:

1) user still has to come up with a pass phrase during setup 2) pass phrase is remembered indefinitely (no expiration, unlike now 4 hours expiration) but only in RAM (as now). 3) At least once each hour of use, the user has to use FaceID to access the pass phrase that is in memory. 4) if the app gets restarted or killed and forgets the pass phrase, it needs to be re-entered

[tomholub]

So the current options are:

• store temporarily
• store permanently

The new options would be, when device supports FaceID or fingerprint (and has FaceID or fingerprint set up):

• store temporarily, protected with FaceID
• store permanently, protected with FaceID

The new option when device does not support it or doesn't have it set up:

• store temporarily
• store permanently

Does that sounds like an improvement? (I'll be checking with customer too)

[murataka]

For now , when I close and reopen the app, or reboot the device , I can access my emails.

I think ,It would be better to add the security level option , instead of adding choices to every feature, as an improvement.

[tomholub]

I see what you mean - you'd prefer a scale for the user to choose. Good idea - user friendly. We could do that in the future, consistently across platforms. I'd prefer for to have consistency between platforms for now even if it means less than ideal design, and then update it on all platforms to improve it.

For our current (enterprise) customer deployment that we care about on iOS, this will not be user configurable anyway (their settings are driven by client configuration managed centrally, no user choices during setup). And consumer release (where this ui would be useful) is still 6 month away.

Regardless, while developing this, we'll also allow it on the non-enterprise setup screen, and the easiest way to do that for now is, I suppose, to add a slider that could be disabled if not supported.

o   store pass phrase permanently
o   store pass phrase temporarily
[....#]  additionally protect with FaceID

That makes the app logic very simple to start with, and remains looking consistent with Android.

[murataka]

As faceid login also handles touchid login , we shall refer it as "biometric login" after now .

When the user sends app to background ( maybe to switch apps ), should we require to login again ( with biometric login) ?

This may be disturbing , for example when trying to copy-paste something from mail content to an other app. If we don't this will let someone else to access the mails if the screen was not locked, and app was not closed but was sent to background.

[murataka]

For the current implementation ( https://github.com/FlowCrypt/flowcrypt-ios/tree/feature/faceid ),

The implemented flow is a bit different , and not reflecting above conversation.

We can make it to reflect it after solving some possible issues with current implementation ( before getting more complex). Also it just handles the google login for now.

The flow is :

user clicks biometric login if user was signed-in , renew the session ( google (or other last login provider ) will expand the session timeout). And show the mails ( for last opened session ).

else do nothing ( keep sign-in screen open )

Do not sign out ( clear stored session ) if the app is closed, or timeout.

When the app is opened , app does not open the mail list , instead shows the sign-in screen to let use biometric login , even if there is an active session.

User also may login with other account, even if already was logged in but not logged in using biometric login.

[tomholub]

When the user sends app to background ( maybe to switch apps ), should we require to login again ( with biometric login) ?

no need, it may be annoying