0

In the country I live in, most authentication for online banking or authorities (such as tax) is based on an app. It has two operation modes:

  1. Enter personal number on website (the personal number is not secret). Enter PIN code in the app on connected phone.

  2. Use phone scan QR code displayed by website. Enter PIN code in the app.

The app required initial activation using the legacy system (such as a TAN generator), i.e., it is somehow paired with the account. Once the app is installed it is always directly accessible when the phone is unlocked.

While naively one could argue that 1.) is 2FA since it requires having the phone and knowing the PIN, I feel this argument is invalid if we consider malware on the phone?

Operation mode 2.) seems intuitively safer (since it requires scanning a QR code, i.e., physical proximity), but nevertheless I have an odd feeling about it that I cannot pin down. Other common 2FA implementation seems to generally require enter information displayed on the phone on the website, or entering a password on the website rather than in the app?

Questions:

  • How safe are these operation modes? Does it count as two-factor authentication?
  • Is there anything I can do personally to mitigate some of the risks?
Mike Ounsworth
  • 58,107
  • 21
  • 154
  • 209
Simon
  • 163
  • 6
  • Reading https://security.stackexchange.com/questions/41939/two-step-vs-two-factor-authentication-is-there-a-difference, I think what I refer to as 2FA is mostly two-step authentication. So what I am asking is probably: Can this even be considered 2-step authentication (let alone 2-factor)? – Simon Apr 16 '22 at 12:11
  • Scanning a QR code is more about verifying your SIM card or phone number than it is MFA in a more traditional sense. It meets the technical definition, but the goal is to reduce risk to the bank, not to you, and doesn't really make *you* more secure. – Todd A. Jacobs Apr 16 '22 at 19:21
  • 1
    What information is required to sign into the app? – belkarx Apr 17 '22 at 06:15
  • @belkarx No sign-in is required. If the phone is unlocked then the app can be started. A PIN code needs to be entered to confirm a transaction (such as login). – Simon Apr 17 '22 at 19:00
  • @Simon Does the PIN change every time you scan the QR code (is it functioning as an one-time-password, or as a permanent password) – belkarx Apr 17 '22 at 19:27
  • 2
    Do you have to authenticate to the app the first time you use it? If so, it can store a cryptographic secret on the phone, so the authentication is code + secret. – vidarlo Apr 17 '22 at 22:19
  • @belkarx Same PIN every time, i.e., a permanent password. – Simon Apr 18 '22 at 17:57
  • @vidarlo Yes there is some initial setup, i.e., you are probably right that it stores a cryptographic secret. But does this matter if the code is also entered *on the phone*, i.e., any attacker on the phone has access to both? – Simon Apr 18 '22 at 17:59
  • 2
    That's semantics ;) – vidarlo Apr 18 '22 at 18:02

2 Answers2

1

Assumption 1: entering your non-secret ID number, or QR code is the website's login page; ie there is no traditional username / password.

Assumption 2: you must have pre-registered your phone with the website; ie you need to have your phone, not any phone.

In that case, I think this counts as multi-factor:

  • Factor 1: Something you have: your phone.
  • Factor 2: Something you know: your PIN.

I agree that it's bizarre to have both factors on the mobile (rather than the username / password on the website and the 2nd factor on the mobile). The one issue that comes to mind is that, depending how they've done it, it could be hard to know if you are authorizing your browser session or an attacker's browser session. The QR code method might be better in this regard (if the QR codes are unique per session).

Mike Ounsworth
  • 58,107
  • 21
  • 154
  • 209
  • It's possible that the PIN is used only for local authentication on the app, in which case, is it really true 2fa? For comparison, many [don't consider](https://security.stackexchange.com/a/220386/235964) an ssh key encrypted with a passphrase as true 2fa. – nobody Apr 19 '22 at 23:25
  • @nobody oooo! Great point! – Mike Ounsworth Apr 20 '22 at 00:40
  • @MikeOunsworth But doesn't the act of *entering the PIN on the phone* "merge" the two factors into one? I agree that originally this looks like two factors, but since we enter the PIN *on the phone* anyone who "has the phone" (in a virtual sense, i.e., can remotely execute code) can do anything they like? – Simon Apr 20 '22 at 15:16
  • @Simon ... maybe? Depends how it's implemented. For example, if the PIN is unlocking the device's keyring (for example the same way that a fingerprint does) then no amount of physical access to the phone will unlock the keyring if you don't also have the corresponding PIN / finger. Which sounds a lot like two factors to me. – Mike Ounsworth Apr 20 '22 at 18:46
  • @MikeOunsworth Interesting point you are making! So we can likely consider it two factors against *physical* (access) attacks, but maybe not against *virtual* (malware) attacks? – Simon Apr 22 '22 at 17:53
0

Revision

The intended purpose of 2FA is to ensure that if one form of authentication is compromised, the other will stand in the way of breaking in. By this scheme, if the physical device of the phone is compromised, then the PIN will protect data from being stolen, and vice versa, making it 2FA.

Also, I'm still unsure how entering the personal number on the website and then using the app would even be technically useful? Seems unnecessary, and if it's on initial setup, QR code seems like a more reasonable bet for tying a personal number to the app. Either way this is a weird way to do things.

belkarx
  • 1,288
  • 3
  • 18
  • 1
    *"risk of compromise to personal devices applies in genuine 2FA as well"* - Yes, but in genuine 2FA, the attacker generally has to compromise 2 devices. In case the second factor is something like a YubiKey, it might not be possible to easily compromise it. Of course, if the client device is compromised, the attacker can still 'ride' the user's active session, but that's not as bad as unfettered access. – nobody Apr 18 '22 at 00:41
  • The "Aside" and "TL;DR" are a bit contradictory, regarding to whether this are one or two factors? To clarify: One cannot use the app on an *arbitrary* phone, it must be the phone/app that was specifically activated when setting up the app-based athentication, via the legacy system (which was based on a card+TAN reader). – Simon Apr 18 '22 at 18:10
  • @Simon thanks for the clarification – belkarx Apr 18 '22 at 22:46
  • @Simon That's important information that should be edited into the question. The question of how many factors this is largely hinges on whether the app itself is a factor (a thing you have, in this case), or whether the same app can be used on an arbitrary device / requires only a memorized secret (a thing you know, same as the PIN). It sounds like it is in fact 2FA, but the key information is that the app had to be activated using an older system that also required something you have. – CBHacking Apr 19 '22 at 07:09
  • @CBHacking Good point, I edited this into the question. I am not sure I understand the comment regarding this being 2FA? Yes technically, but if some malware installes a keylogger on the phone they should be able to authenticate arbitrary transactions without having to, e.g., steal the phone? – Simon Apr 19 '22 at 18:40
  • 1
    @Simon A keylogger alone wouldn't do it - they'd need to be able to access the app's secrets / use the app directly, too - but this is a universal weakness of 2FA that goes through a single client. If the client is untrustworthy (e.g. because it or its platform is compromised), _and you use it anyhow_, an attacker can always get in (though they won't be able to do so repeatedly if their access to the client is lost). The reason this is 2FA is that neither of "stole the unlocked phone with the app on it" nor "shoulder-surfed the PIN" is sufficient to get in; you need both. – CBHacking Apr 20 '22 at 00:24
  • If malware can run a keylogger, isn't it reasonable to assume that it can also run the app and replay the logged PIN? – Simon Apr 20 '22 at 15:07