Swallowing Biometrics all the way down.


Status
Not open for further replies.

Jeffa

Well-known member
May 20, 2018
217
113
Hi,

There has been much talk about using biometric auth as a strong preference if it is available.

It has been discussed a few time that on a mobile device with biometrics that the password will only be required once (at identity generation or import) and subsequently biometric auth should be preferred.

I don't disagree that we should use biometrics to make things as smooth as possible.

However, if we are not asking the user to provide their password at least once per "session" do we think the user will even remember their password?
 

PHolder

Well-known member
May 19, 2018
1,192
194
do we think the user will even remember their password
Signal keeps prompting me semi-randomly to enter my PIN for it's lockdown option for this very reason. Part of me is annoyed every time because I am never going to forget the PIN but on the other hand, I agree with the point of it.
 

0.NRG

Well-known member
May 19, 2018
46
11
@Jeffa Though I trust Apple's secure enclave overall, I don't by any means think it is a bad idea to periodically have the password entered again, if nothing else but for your concern of helping the user remember the password. Before reading Paul H's comment, I was thinking that maybe periodically asking for the password is the best solution. It could be random or perhaps you ask every 2 or 3 weeks. With 2FA, we have the common "remember this device for 30 days". Maybe you could mimic that for the password. This could also be an option in iOS settings where you let the user decide when the password should be re-entered. Maybe the options could be: Every 2 weeks, Every 30 days, and Never (If choosing this, don't forget your password!).
 

Steve

Administrator
Staff member
May 6, 2018
1,016
305
www.grc.com
This is an interesting issue, I think.
We have kind of been thinking of biometrics as a version of GRC's Windows client "Quick Unlock."
But I don't that that model is correct.
A biometric can either be trusted to AUTHENTICALLY identify the user, or it can't. And I think we must assume that it can.
If it can, then the password is only required by our technology once after import to enable biometric user authentication.
From that point on, unlocking the device and/or re-asserting a biometric is all that's needed.

At that point, I don't think that the user should EVER be hassled to provide their password for any operation, ever.

In the worse case, we have the RC for password recovery... and we must assume that the user has their RC for fallback.

For their own safety, in the "identity management" section of the app a user might ASK to be re-prompted every 'n' days for their own safety. But they should be able to disable that, too. Smartphone keyboards are atrocious. Let's not force its use when there's really no need.
 
  • Like
Reactions: Smaug and 0.NRG

Jeffa

Well-known member
May 20, 2018
217
113
This is an interesting issue, I think.
We have kind of been thinking of biometrics as a version of GRC's Windows client "Quick Unlock."
But I don't that that model is correct.
A biometric can either be trusted to AUTHENTICALLY identify the user, or it can't. And I think we must assume that it can.
If it can, then the password is only required by our technology once after import to enable biometric user authentication.
From that point on, unlocking the device and/or re-asserting a biometric is all that's needed.

At that point, I don't think that the user should EVER be hassled to provide their password for any operation, ever.

In the worse case, we have the RC for password recovery... and we must assume that the user has their RC for fallback.

For their own safety, in the "identity management" section of the app a user might ASK to be re-prompted every 'n' days for their own safety. But they should be able to disable that, too. Smartphone keyboards are atrocious. Let's not force its use when there's really no need.
OK Agreed.

Onto the subject of the "enclave".

There is no way to store abitrary data in the secure enclave.

The preferred option would be to us the ppk crypto features of the enclave to encrypt the users ID. Sadly this API does not really work below iOS 10.2.1 (that would rule out many devices)

TouchID and FaceID use the enclave to assert user presence.

TouchID as FaceID can be used to protect keychain items.

At the moment the app generates a key and stores it in the keychain, protected with biometrics.

I think this is an acceptable workaround to support more devices.

Thoughts?
 

0.NRG

Well-known member
May 19, 2018
46
11
@Steve I like a couple of your comments. I've struggled with this a bit. Even though there is a part of me that doesn't fully trust anything that Microsoft, Google, or even Apple does when it comes to privacy, security, etc., I trust Apple more than Microsoft and/or Google. Furthermore, I haven't seen or read anything to make me necessarily distrust the secure enclave. If it is trustworthy and can indefinitely store the SQRL password, then I agree, there is no reason to enter the password except at the beginning to enable biometric authentication.

I had forgot about the RC being able to be used to recover the password and, yes, we should assume that the user was responsible and does have a copy of their RC.

You brought up another good point, trusting these keyboards, especially 3rd party keyboards, should probably be minimized if at all possible.
 

PHolder

Well-known member
May 19, 2018
1,192
194
I am on no side in this discussion as I will not be using SQRL on an Apple device. I did want to suggest that TNO goes completely out if the SQRL credentials are stored in the Apple cloud... as they have proved/suggested in the past... just wait for the device to be synced to the cloud then the government can request a copy of the bakup/sync'ed info. If your goal is complete TNO I don't think you can use a cloud provider.... so should the client be sensitive to such issues for those people that worry about them?
 
G

Gristle

Guest
iOS 10 is nearly 3 years old now, and iOS 12 runs on devices going back to the iPhone 5s, iPad Air 1, and iPad Mini 2. These are old devices, and iOS 12 runs better than iOS 10 does on these devices. I see no reason other than laziness that a user would still be on iOS 10 in 2019. I would say go ahead and adopt the forward looking API and if people are left out, give them a way to supply that feedback. I would wager that not a single person running iOS 10 will use ever attempt to use SQRL.
 

PHolder

Well-known member
May 19, 2018
1,192
194
see no reason other than laziness that a user would still be on iOS 10 in 2019
Just FYI my iPad 4 cannot be upgraded past iOS 10... but otherwise runs fine (I assume, I haven't laid hands on it in 4+ months because I don't have a use for it now that Apple has abandoned it.)

 
G

Gristle

Guest
I have an iPhone 1 that runs iOS 1. But I have no reason to use a SQRL client on it natively. If, for some reason, you wanted to use SQRL on your iPad 4, what's wrong with using the cross-device login to solve that function? I just think it's crazy to neuter an app's user experience on account of supporting a very narrow subset of users, especially on a service that hasn't seen widespread adoption yet.
 
G

Gristle

Guest
I am on no side in this discussion as I will not be using SQRL on an Apple device. I did want to suggest that TNO goes completely out if the SQRL credentials are stored in the Apple cloud... as they have proved/suggested in the past... just wait for the device to be synced to the cloud then the government can request a copy of the bakup/sync'ed info. If your goal is complete TNO I don't think you can use a cloud provider.... so should the client be sensitive to such issues for those people that worry about them?
Without making any claims about the security model of iCloud, the user has the option of whether or not to store their credentials in iCloud and can control iCloud access on a per-app basis and a per-device basis at the OS level.

On a theoretical note, isn't it "safe" to store the rescue-code-encrypted SQRL ID in the cloud? If someone got a hold of it, they would have to brute force the rescue code, which I have understood is unfeasible, even for a nation state. Correct me if I'm wrong, because that's exactly what I'm doing. 🆒
 

PHolder

Well-known member
May 19, 2018
1,192
194
"safe" to store the rescue-code-encrypted SQRL ID
If you store the identity and the means to access it (the password decryptable by Apple from the keychain or whatever) then it's safe from a rekey or account deletions (because the rescue code is needed) but it would not be safe from usage... it could log in anywhere including creating new accounts anywhere.
 

PHolder

Well-known member
May 19, 2018
1,192
194
neuter an app's user experience on account of supporting a very narrow subset
I don't know if you're a coder or not, but the correct response to this is simple. Write the code for the lowest common denominator you wish to support, then add conditional code that checks the version and activates better features of newer [supported] platforms. This is more work of course, but this is also why we have versions in the first place.
 
G

Gristle

Guest
If you store the identity and the means to access it (the password decryptable by Apple from the keychain or whatever) then it's safe from a rekey or account deletions (because the rescue code is needed) but it would not be safe from usage... it could log in anywhere including creating new accounts anywhere.
The password I am using is stored in the local keychain, and accessed via FaceID. It is not stored in iCloud, and even if it were, the keychain is not decryptable by Apple if you set it up correctly, even if the PDF of my SQRL ID is (which is also an assumption which may not be true). So I believe this is safe. Thanks for confirming.
 

Andrew Godfrey

Well-known member
Mar 6, 2019
83
21
Seattle
OK Agreed.

Onto the subject of the "enclave".

There is no way to store abitrary data in the secure enclave.

The preferred option would be to us the ppk crypto features of the enclave to encrypt the users ID. Sadly this API does not really work below iOS 10.2.1 (that would rule out many devices)

TouchID and FaceID use the enclave to assert user presence.

TouchID as FaceID can be used to protect keychain items.

At the moment the app generates a key and stores it in the keychain, protected with biometrics.

I think this is an acceptable workaround to support more devices.

Thoughts?
I agree with PHolder that you should consider doing both, with the code picking one based on the OS version. (However it adds a complication - how to handle an OS upgrade which crosses the threshold).

I don’t know the security profile of this environment very well so I’m not sure how much of an improvement this would make to security in this case. How do you generate that key? How do you discard that key to be sure you don’t have copies of it? Same question for the decrypted ID.

But I also recognize that even if you used the ppk features, presumably they fall short of allowing the entire SQRL sequence to be performed within the secure enclave? (i.e. site URL + challenge goes in, response to the site comes out). In which case you still have secret-management challenges either way.
 

Steve

Administrator
Staff member
May 6, 2018
1,016
305
www.grc.com
TouchID as FaceID can be used to protect keychain items.
At the moment the app generates a key and stores it in the keychain, protected with biometrics.
I think this is an acceptable workaround to support more devices.
Thoughts?
Yes. I agree. Use the keychain to safely encrypt and store the user's decrypted SQRL ID so that you can obtain it for use as needed.
 

Steve

Administrator
Staff member
May 6, 2018
1,016
305
www.grc.com
I agree with PHolder that you should consider doing both, with the code picking one based on the OS version. (However it adds a complication - how to handle an OS upgrade which crosses the threshold).
Yes. The perfect solution. And it migrates gracefully forward. Once the device acquires the ability to store data in the enclave, remove it from the Keychain.
 
  • Like
Reactions: hackersarchangel
Feb 28, 2019
22
2
I like how the writer for the Android app has done it, and LastPass has taken a similar road, which is that if I opt in to biometrics, it lets me use it by default. But in the event it gets disabled for some reason either due to failure of auth or me hitting cancel, I can still enter in my password. On that note, I think asking them to enter it in once like the Android app does is a good security measure, and realistically if people are doing the right thing and making a password that they can enter once, even with some difficulty, it's better than just always allowing biometrics.
 

Jeffa

Well-known member
May 20, 2018
217
113
Yes. The perfect solution. And it migrates gracefully forward. Once the device acquires the ability to store data in the enclave, remove it from the Keychain.
To clarify, there is never an ability to store own data in the enclave.

You can ask the enclave to create a key pair and give you the public key. (Using Apple’s flavour of ppk)

It keeps the private key and will encrypt data for you and give it back, or sign things and verify sigs.

(Using Apple’s flavour of encryption

)
 
G

Gristle

Guest
I think Steve meant that if Apple ever DOES allow us in the future, then it could be stored there. I highly doubt that will ever happen, and I don't see anything wrong with using the keychain (other than that it syncs into iCloud, where it's still unclear to me whether or not apple can decrypt it if compelled to).
 
Status
Not open for further replies.