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?
9
  • Reading security.stackexchange.com/questions/41939/…, 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 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. Apr 16 at 19:21
  • 1
    What information is required to sign into the app?
    – belkarx
    Apr 17 at 6:15
  • 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 at 22:19
  • 2
    That's semantics ;)
    – vidarlo
    Apr 18 at 18:02

2 Answers 2

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).

5
  • 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 an ssh key encrypted with a passphrase as true 2fa.
    – nobody
    Apr 19 at 23:25
  • @nobody oooo! Great point! Apr 20 at 0: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 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. Apr 20 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 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.

7
  • 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 at 0: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 at 18:10
  • @Simon thanks for the clarification
    – belkarx
    Apr 18 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 at 7:09
  • 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 at 0:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.