3 ms·

Yep, my bank forces me to use an Android/iOS only app. As far as I'm aware, there's not a single bank in my country that supports open 2FA standards, like FIDO2

Yep, my bank forces me to use an Android/iOS only app. As far as I'm aware, there's not a single bank in my country that supports open 2FA standards, like FIDO2. Infuriating, and it's only going to get worse. And then the EU complains about Google/Apple's monopoly power - I wonder why...

hadrien01 4y ago
There's a single one in my country (Boursorama). Even more infuriating, banks are now forcing clients to use their apps to add beneficiaries without an artificial delay or to make an instant SEPA transfer.
thesimon 4y ago
> FIDO2 Lacks the reference to a transaction. An attacker could send unlimited transactions for 15 seconds after you approved yours.
- raxxorraxor 4y ago
  The layer below does not have to protect against replay attacks. In fact solely relying on such a protection would be a security issue itself. The user could just generate the TAN here and sign the transaction.
- ryukafalz 4y ago
  An attacker who has compromised the bank’s servers could, sure. But at that point don’t you have bigger problems?
  - thesimon 4y ago
    Well, the PSD2 opens the banking to third parties (basically OAuth, just for banks). So an approved payment initiation services (PIS) can do transactions on your behalf. But you still want to have control over which transfers they actually send, so you want to make sure the confirmation code only works for a certain transaction.
    - Nextgrid 4y ago
      I believe this would have to be implemented by the payment initiation service provider - as far as the bank is concerned, once you authorize the PIS provider the have full access and can initiate any transfers they want.
  - trasz 4y ago
    Compromising bank servers is less harmful than compromising individual customers, because it's the bank (or perhaps the insurance) that's bearing the consequences, not its customers.
- grnmamba 4y ago
  You can include the transaction ID in the clientDataHash calculation, which will be signed by the authenticator. This protects against that attack. https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-20210615.html#authenticatorGetAssertion https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-cl...
- jasonjayr 4y ago
  1 transaction every ($interval * 1.5) seconds ought to be enough for most non-commercial banking users? Even if you could tie the token to a non-separable 'bundle' of transactions for larger transactions (Payroll for all staff?) Banking IT seems to have their heads in the clouds of regulations, and risk aversion to even proven modern secure solutions.

hadrien01 4y ago

There's a single one in my country (Boursorama). Even more infuriating, banks are now forcing clients to use their apps to add beneficiaries without an artificial delay or to make an instant SEPA transfer.

thesimon 4y ago

> FIDO2 Lacks the reference to a transaction. An attacker could send unlimited transactions for 15 seconds after you approved yours.

raxxorraxor 4y ago
The layer below does not have to protect against replay attacks. In fact solely relying on such a protection would be a security issue itself. The user could just generate the TAN here and sign the transaction.
ryukafalz 4y ago
An attacker who has compromised the bank’s servers could, sure. But at that point don’t you have bigger problems?
- thesimon 4y ago
  Well, the PSD2 opens the banking to third parties (basically OAuth, just for banks). So an approved payment initiation services (PIS) can do transactions on your behalf. But you still want to have control over which transfers they actually send, so you want to make sure the confirmation code only works for a certain transaction.
  - Nextgrid 4y ago
    I believe this would have to be implemented by the payment initiation service provider - as far as the bank is concerned, once you authorize the PIS provider the have full access and can initiate any transfers they want.
- trasz 4y ago
  Compromising bank servers is less harmful than compromising individual customers, because it's the bank (or perhaps the insurance) that's bearing the consequences, not its customers.
grnmamba 4y ago
You can include the transaction ID in the clientDataHash calculation, which will be signed by the authenticator. This protects against that attack. https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-20210615.html#authenticatorGetAssertion https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-cl...
jasonjayr 4y ago
1 transaction every ($interval * 1.5) seconds ought to be enough for most non-commercial banking users? Even if you could tie the token to a non-separable 'bundle' of transactions for larger transactions (Payroll for all staff?) Banking IT seems to have their heads in the clouds of regulations, and risk aversion to even proven modern secure solutions.