Allowing a fingerprint scan in place of the quickpass?

[Dave]

What would you (Daniel and others) think of an option to allow the use of a fingerprint scan in place of the quickpass?

It would be entirely too risky to allow a fingerprint scan in place of the master password. But, a fingerprint scan seems no less secure than the quickpass. And, just as the number of characters in the quickpass is configurable, the number of fingerprint scan's to allow could be as well, but limit it to, maybe 3. it is not entirely uncommon for the first scan to fail when used to login to the phone or to authenticate to log in to an app.

Thoughts?

 

[Vela Nanashi]

Or any of the other biometric methods the user has available, though make it an option in that case so the user can choose to enable it or not. If that is possible at least.

 

[PHolder]

Well, my understanding of the QuickPass is that you keep access to the master secret encrypted with the QuickPass. (which is secured from brute force by a lengthy number of rounds of encryption.) It's unclear what you would protect and how with the fingerprint reader. I don't know the API for the biometrics... but if you can't say "here is a token, protect it with your life unless you get a biometric match" then it requires the client to keep the "token" in RAM and only use it when it hears of a match from the API. Even if the token is a second level of redirection, it's still got to be in the clear, which makes it significantly less secure than even the QuickPass. (IMHO)

 

[Steve]

Jeff’s SQRL client for iOS allows the use of the fingerprint after once entering the full password. So it’s very nice! I’d imagine that Daniel could do the same thing depending upon available hardware support.

 

[kalaspuffar]

Hi gang.

Well I was actually thinking about this since the last Google IO. They introduced a new API for the keymanager that could store cryptographic data with a system key so it could not be decrypted without unlocking the device with the means available from the system.

So I put it up as one of the things to look into. The issue on GitHub is #175 if you want to add extra resources or thoughts I need going forward.
https://github.com/kalaspuffar/secure-quick-reliable-login/issues/175

Giving feedback here is also fine but it might be removed in the upcoming forum wipe.

 

[warwagon]

I wonder if Steve might be able to spare these sub-forums as they contain constructive information and not just a bunch of test posts. Curious if he can choose which forums to wipe or if it's a global all or nothing wipe.

 

[Steve]

Yes. I will NOT wipe anything from here. This is Daniel's place. He's free to wipe anything he wants to, of course. But I think I ought to leave the forums being managed by their project leaders alone.

 

[shanedk]

A lot of banking apps etc. have started to use this. From what I've seen, it's very secure.

You could give people three alternatives:

1) Master password/QuickPass (the default)
2) Master password/fingerprint (the fingerprint would be "forgotten" based on the same settings as the QuickPass)
2) Fingerprint only (of course, the master password is still needed for import/export)

 

[PHolder]

Who do you trust? The OS vendor to not give up your private info if commanded, or your brain I will stick with my own memory even if it means a little more work for me.

 

[warwagon]

Who do you trust? The OS vendor to not give up your private info if commanded, or your brain I will stick with my own memory even if it means a little more work for me.

but unlike a username password combination, before that fingerprint would even be useful he would have to import your identity into his machine, correct? Can malware snatch your identity off your phone? Even if that was the case having your fingerprint data would be more worthless than snagging your password.

 

[PHolder]

No.. the fingerprint is useless to everyone, in general... unless you can supply it, on demand, to a reader.

The OS has to have something to "lock up"... a token, say. That token COULD be your (channeling @Steve) "super-secret SQRL key". If they get that (by any means) you're 100% completely hosed... on EVERY site you have ever used your SQRL identity.

So then you make the token the password to decrypt the SQRL secret key. That's just another level of indirection.

The issue is that there is no magic... there is no way to not have to enter the password that doesn't make it possible for malware or the powers that be to collect it if they get access to the OS secret store.

 

[AlanD]

As I see it, the problem is what do you trust. At the moment, your SQRL super-secret key is protected by the SQRL application and your password. In order to access the SQRL super-secret you have to supply the correct password. In Steve's client, he checks the supplied password and only decrypts the super-secret if the password is right.

But, as this password is being used as a decryption key, the client could take any password input and use it to try to decrypt the super-secret. supplying ANY password could result in an alleged super-secret value being disclosed, but without the correct password, the decrypted super-secret is in fact rubbish. (Garbage in, garbage out) However, the only way that a hacker can tell that it is rubbish is when it fails to log him on to a website. That would slow down any brute-force attempts by a large factor.

Unless you are going to write your own fingerprint handling into the SQRL client, you are going to rely on that provided by Apple/Android. I suspect that the API will take the scanned fingerprint and just return "Valid" or "Not Valid". Putting a bit of code in the middle to intercept these calls and always return "Valid" is much easier than forging a fingerprint.

Call me old-fashioned, my phone is capable of fingerprint scanning, and my bank supports it, but you won't find me using it. I far prefer a password which is stored only in my brain.

 

[shanedk]

supplying ANY password could result in an alleged super-secret value being disclosed, but without the correct password, the decrypted super-secret is in fact rubbish.

That isn't how it works. The IMK is encrypted using AES256-GCM, which is authenticated encryption. If you get anything other than the correct super-secret value, the authentication will fail (which is what you want).

Try it: deliberately type in a wrong password. It'll go ahead and tell you you got it wrong; it won't act like everything's fine until you try to log in.

I suspect that the API will take the scanned fingerprint and just return "Valid" or "Not Valid".

You suspect incorrectly. The API can be used to generate asymmetric or secret keys unique to that app.

 

[shanedk]

Is there any update on this feature?

 

[kalaspuffar]

Hi @shanedk

You are freaky!

I just booted up an in the process of setting a phone with Android Pie and what I understand the API needs update to Pie in order for the fingerprint scan to be useful.

Haven't looked at it yet, still installing apps

Best regards
Daniel