1

My ideal bank would offer online banking from a browser with user/pwd and WebAuthn, for example with a NFC or USB key. No OTP or SMS or apps on the smartphone or physical devices required. (It goes without saying, no recovery questions or stuff like that.) This would only require to keep one device safe from attackers, i.e. the computer running the browser. Moreover one could use the same key with many other online services.

There seems to be no bank in the world as of 2019/10/10 doing this. Is this an issue with legacy/proprietary technology, or lack of convenience/ease of use by customers, or what? In other words, what prevents them from doing this already?

Anders
  • 64,406
  • 24
  • 178
  • 215
jj_p
  • 369
  • 1
  • 9
  • How would I log in on with my phone? How would I log on with devices that do not have USB or NFC? I still have to keep that physical token secure and if stolen, it has no protection from unauthorised use. What you suggest isn't done because most users will not be able to use it. – schroeder Oct 11 '19 at 06:57
  • Because banks are bound by regulations. They can't and don't want to jump onto each new technological trend, just like how you don't use any fancy new crypto algorithm 2 weeks after it was published. –  Oct 11 '19 at 06:59

1 Answers1

5

Username and password alone or together with WebAuthn1 only offer an authentication of the user.

Modern authentication methods used by the banks like PhotoTAN instead authenticate each transaction separately: not only it gets checked that the user is present but the transaction information are displayed on an independent system (app on mobile phone or extra hardware) so that the user can verify these before authenticating the transaction. Even proper SMS based methods show the transaction details together with the created TAN in the message.

This kind of independent verification of the transaction details and transaction-dependent verification is needed since in the past trojans or man in the browser changed the transactions on the fly, i.e. the user was seeing the correct transaction in the browser or mobile app and authorized it while in the back the submitted transaction information where changed in favor of the attacker.

In other words: username+password and WebAuthn1 only authenticate the user. This is not sufficient and an additional transaction-dependent authentication is needed.

1 As mention in a comment WebAuthn does in theory support authentication specific for a transaction. This still requires an extra device or app though since it is "intended for display on a trusted device on the authenticator". Thus just WebAuthn without such additional trusted device is not sufficient.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • 2
    Not correct: WebAuthn supports transaction validation through extensions (https://www.w3.org/TR/webauthn/#sctn-simple-txauth-extension and https://www.w3.org/TR/webauthn/#sctn-generic-txauth-extension) – Tangui Oct 11 '19 at 10:33
  • 1
    @Tangui: correct, but *"A Relying Party can specify a prompt string, intended for display on a trusted device on the authenticator."* - thus, again some extra device or app is needed. That's the main point - it should be an independent verification. – Steffen Ullrich Oct 11 '19 at 11:39
  • @Tangui Does 'trusted device'/extension necessarily mean something other than the browser I'm already authenticated with? – jj_p Oct 11 '19 at 15:41
  • 1
    @jj_p: the main point is not to use the same channel for verification as was used to initiate the action - because this channel might be compromised. The attacker might otherwise be able to use the compromised channel to fake the verification, i.e. display the intended transaction details intended by the user instead of the actual (compromised) transaction details. – Steffen Ullrich Oct 11 '19 at 15:44
  • However, they seem to consider smartphone apps safe enough to handle both authentications of user and transactions, right? – jj_p Oct 16 '19 at 17:16
  • @jj_p: I consider compromising both the smartphone AND the computer much harder then just hacking the computer alone. And note that are often also single-purpose readers which don't require a smartphone and can thus not be compromised (at least without having physical access). – Steffen Ullrich Oct 16 '19 at 18:51
  • What I meant is that many banks seem to be happy to rely on smartphone alone, but not on computer alone. – jj_p Oct 17 '19 at 07:29
  • @jj_p: your question is specifically about not using an *additional* app on the smartphone but having *only* the computer. Please stay within the scope of your own question. – Steffen Ullrich Oct 17 '19 at 07:41
  • Your answer entails that browser can be manipulated by e.g. mtm, but in reality banks seem to be happy with their app as the *only* device, so my remark. Are you implying that app alone is more secure than browser alone? – jj_p Oct 17 '19 at 11:23
  • @jj_p: Generally the separation between apps on the smartphones is much better than on a desktop computer which greatly limits the impact some malicious app might do. I consider a smartphone therefore better protected than a computer but smartphone+computer is still better. I personally would not use a single device for this. – Steffen Ullrich Oct 17 '19 at 12:24
  • That's what I wanted you to admit, and it seems that's also the rationale behind most or all banks' thought. But take your average Android smartphone, lagging behind 2-3 months in security updates, and compare it with a fully patched Arch Linux machine: do you really think the former is safer? – jj_p Oct 17 '19 at 21:42
  • @jj_p: For the typical user the smartphone is user. The typical user does not user Arch Linux. The typical user is what the banks care about and need to care about first because almost all of their users are typical users. Arch Linux is also not the target for common attackers since the investment is too high compared to the return. This is mainly because there are too few users on this platform compared to Windows and not because Arch Linux is much safer by design. – Steffen Ullrich Oct 18 '19 at 04:49