1

Can someone confirm if the following solution is actually 2FA?

User has to install a special mobile app. When the mobile app is opened for the first time, the user is asked to associate the device with the account in the system.

On the web login screen, QR code is displayed. A user opens the previously installed mobile app, and scans the QR. Afterwards, the user's fingerprint is checked using the phone's biometrics.

I don't have technicals details on how it is implemented. I want to make sure if it can be considered 2FA.

schroeder
  • 123,438
  • 55
  • 284
  • 319
Alexey Mukas
  • 113
  • 4
  • This all depends on what "the special app" does. – Marc Sep 09 '20 at 11:43
  • yeah, I understand. but is it 2FA at all? – Alexey Mukas Sep 09 '20 at 11:48
  • 1
    Only if the output of scanning the QR code depends on something such as the app configured with your account. If the output is the same for anyone scanning the barcode, it just proves you saw the barcode and have the app installed. – Marc Sep 09 '20 at 11:49
  • there is no shared QR, it is shown for 60 seconds. If you refresh the login page it will be different – Alexey Mukas Sep 09 '20 at 11:52
  • 1
    It's not a question of the QR code being unique. If I try to login as you using your username and password and all the app (signed in as me) processes the QR code correctly, then it's not a second factor, it's just proving that I have the app installed. – Marc Sep 09 '20 at 11:54
  • The app has to be activated (linked with your account in the system). After that, to log in, you need to scan QR and provide a fingerprint. – Alexey Mukas Sep 09 '20 at 11:57
  • 1
    Perhaps you can clarify how this login flow works, because reading your question I am uncertain and so can't give a clear answer myself. – Conor Mancone Sep 09 '20 at 12:17
  • I added more details. Unfortunately, I cannot get any tech details. but this solution is advertised as being 2FA. – Alexey Mukas Sep 09 '20 at 12:23
  • 1
    I edited your question to make things clearer. You are focused on the QR code, but I think the relevant part here is the fingerprint ... – schroeder Sep 09 '20 at 12:25
  • It wasn't the technical details I was missing, but your description of how it actually works. Schroeder's edit helped a lot – Conor Mancone Sep 09 '20 at 14:03
  • come on, it doesn't change much the result. I do agree that now it is more technically correct. – Alexey Mukas Sep 09 '20 at 15:37

2 Answers2

3

There are several moving parts here and you, admittedly, do not have all the technical details, but it does appear to be 2FA on its face, with a caveat:

  • The app is associated with the account and the phone, making the phone a factor (but that depends on how the phone is associated with the account)
  • The login process requires a biometric scan of the fingerprint, making the finger a factor

This process is not unlike a 2FA app on a phone (Google Authenticator, LastPass Authenticator, Microsoft Authenticator, etc.) that requires biometric authentication to open and uses push notifications. In your case, the push notification appears to be done via QR code.

However, this is pretty weak, passwordless 2FA. Since all the relevant factors are contained within the phone, that makes this more of a "1.5 Factor Authentication". The phone's app is the primary factor for the account and the app has its own factor, the biometric function controlled by the phone's hardware. Chaining them like this is not true 2FA for the account. It's more like two "1FA" processes chained together on the same device. This matters because the loss of the device alone puts the whole protection scheme in jeopardy; you are relying on the security of the functions of the phone.

Could it be considered to be "effectively 2FA"? That could be argued. To be honest, I would hedge my opinion and stick with the "1.5 Factor" answer. I know that it is not a clear answer, but the line to be drawn will depend on why you need to know if this is 2FA or not.

schroeder
  • 123,438
  • 55
  • 284
  • 319
0

Authentication is multi-factor if it uses at least two of the following:

  • "something you know" (i.e. password)
  • "something you have" (i.e. smart card)
  • "something you do" (i.e. typing; so that machine learning can recognize that)
  • "something you are" (i.e. your fingerprint)
  • "somewhere you are" (i.e. geolocation)

So in your case, the QR-code is used to get the log-in link. As you can see it does not match any of the above. Once your user receives the link, he uses his fingerprint, that is "something you are". Therefore, we may conclude that it is not 2FA since it only uses one factor.

However, if your QR is refreshed regularly and is bound to unique encrypted user session then it is "something you know". Because for somebody else to know it he would need to steal users session.

schroeder
  • 123,438
  • 55
  • 284
  • 319
jhonnyjhonny
  • 11
  • 1
  • IMHO taking image + fingerprint is one factor (the "something you have") – Alexey Mukas Sep 09 '20 at 12:20
  • A QR code bound to a unique user session is not "something you know"... "the QR-code is used to get the log-in link" -- this assertion is not based on available evidence. – schroeder Sep 09 '20 at 12:28
  • You have also missed the fact that the app on the phone needs to be associated with the account, which makes the phone "something you have" and adds a factor. – schroeder Sep 09 '20 at 12:33
  • "By performing a SSL handshake my app uniquely identifies itself" -- No. Only if it *also* has a unique identifier or a client cert, and you have conveniently dismissed the main point I made, which is that the app is associated ***with the account***. That's what makes the phone an ***authentication factor*** for this account. – schroeder Sep 12 '20 at 17:13
  • So the author writes "When the mobile app is opened for the first time, the user is asked to associate the device with the account in the system. On the web login screen, QR code is displayed..." So the QR code is used in the first place to associate the phone. So guess what, the phone is not associated before accessing the QR code. Regarding SSL, you have answered the question yourself: a client got to have a cert. And the author did not mention that, so I kind of said that it could be an option to make this scheme secure. – jhonnyjhonny Sep 13 '20 at 17:53
  • "It's more like two "1FA" processes chained together on the same device. This matters because the loss of the device alone puts the whole protection scheme in jeopardy; you are relying on the security of the functions of the phone." @schroeder Can you please explain how fingerprint is stored in phones memory? Good implementation would store only its hash. – jhonnyjhonny Sep 13 '20 at 17:57
  • I never said that the fingerprint is stored in the device's memory – schroeder Sep 13 '20 at 18:48
  • Client certs are never required in TLS, so you can't assume that it is there. And I think you are reading a lot more into what the author wrote in the question than was actually said. In fact, you've read more into what I've said than I have. I don't think this discussion will be fruitful if I have to respond to your imagination and not the evidence at hand. – schroeder Sep 13 '20 at 18:50