[Suggestion] security measures against social engineering attacks

New-Turquoise-Guanaco-3063363029

Security and usability can often get in the way of one another. I really like to use bunq because of the usability, the ease of multiple accounts, cards, budgets, manual/automatic approval of direct debits etc.

I also believe that the bunq app in itself is secure, however the great usability comes at a price of vulnerability especially regarding social engineering attacks. I would like to suggest several measures that would help harden the bunq experience against social engineering. We all know we should never click on links in emails or text messages (or wait, did I just get an email from bunq with a link to a survey today?!?) but we all have moments where we fall for such an attack.

Below is a list of suggestions, I believe some were already part of bunq once, but removed because of usability. So for all means, make them optional, like the logout-timer.

Never send bunq emails with links, use the app for survey invites (not configurable this one..)
Allow the user to set a timer for new devices, so you can’t transfer money from a new device for x hours
Allow the user to set a timer for limit changes, maybe even a different timer for different amounts
For shared accounts; set a limit above which both account owners need to approve. (Would be very strong combined with 2+3, timer OR both owners).
Introduce an extra factor for: limit changes, new cards, changing of savings to bank account. A text message with a code to enter on itself is not safe, but as an extra step to take it makes social engineering harder. Bonus points: allow TOTP instead of sms.

As said above let users choose whether they want to use these extra measures or not, just ensure that disabling any of the measures takes the measure into account (if you have a 4 hour timer, you have to wait 4 hours when disabling it)

Joeri-Silver-Lynx

Jelle

Your suggestions involving a configurable Time-Lock make sense.

You also mention TOTP-codes. Unfortunately those are not phishing-resistant, meaning users can still be tricked in typing those numbers on an incorrect website or share them. Perhaps it could be a fall-back recovery MFA method with a Time-Lock.

I would prefer to use a device-bound Passkey [1] for those operations in point 5. It will be phishing-resistant.

Social engineering attacks will try to set-up a second Passkey on a new device. If the user has 1 device with a device-bound passkey, the set-up must demand proximity of the new device. This will make it harder if not impossible to abuse remotely.
(Phone 1 accomplishes cross-device passkey authentication on device 2 with QR+bluetooth in proximity only.) [2]

If the fall-back method would be TOTP + Time-Lock, attackers would move to trick the user in sharing the TOTP. The time-lock will delay them, but they could call/text back after the time-lock has expired to continue the social engineering.

We need a method where there are no secrets to share (or that can be phished) or something that alerts the user or the system of the scam.

An offline, secret-based method like TOTP might delay, but it is not a perfect fit.
A device-bound Passkey is phishing-resistant; you cannot use it on the wrong website or share it, but whatever fallback method the system offers becomes the weakest link.

What about trusted IP? What if the fall-back method required the user's second device to be connected to a trusted network (home / work WiFi)? Attackers would have to trick the user into setting up a proxy app or get onto their (Guest) WiFi, which unfortunately is not undoable. We can combine elements now though.

The combi recipe could be:

Privileged operations: Require device-bound Passkey authentication + Time-Delay/Lock if applicable.
L---> Fall-back A: Syncable-Passkey auth + Time-Lock (+ Syncable Passkey auth again)
L---> Fall-back B: TOTP + Trusted Internet Connection both devices + Time-Lock
L---> Fall-back C: video-authentication MITM-resistant* + Time-Lock

* To prevent attackers attempting to trick a user in saying those video-auth numbers in a regular video-call while they forward that feed to bunq site trying to get in, the origin of the video feed's frames could be challenged & verified by bunq.

So even if the user is tricked, bunq can verify the frames' signatures (or file's) with the origin key and claim: this video was not made inside the user's bunq app which has it's own unique key pair.
Any video taken elsewhere, will not have correct digital signatures. [4] This means the video-authentication method must sign every frame when taking the video-auth video. (This doesn't require additional user interaction.)

This should mitigate social engineering attacks with relaying video of existing bunq users with activated bunq apps. For new users there is no money yet so no risk and for phone-was-lost/reset-users the re-onboarding procedure will be the new weakest link.

Re-onboarding procedure (device-bound Passkey & known video-auth-key-pair lost):

Require syncable passkey auth + Time-Lock + Trusted Internet Connection
Alt: Video-authentication + Time-Lock + Trusted Internet Connection
Alt: Video-authentication + Time-Lock + iDIN
Alt: Video-authentication + Time-Lock + Trusted Family member.
Alt: Video-authentication + E-mail code + TOTP + Time-Lock
This list is difficult to make. Re-onboarding options 1-5 could be shared via social engineering. The hope remains that extra communication during the delay of the Time-Lock will warn the user. Signing video frames is not useful in this context because the key pair will be new and untrusted. Only option 1 is phishing-resistant and though it would require many steps to share a syncable Passkey, a user could be tricked to share it (which is why device-bound are better for privileged operations; not shareable). The Trusted Internet Connection IP would then be the last line of defence.

Perhaps during set-up weeks of account, bunq should offer the user the choice what they want their recovery method to be in case they loose their primary authenticator. (In this case an activated bunq app on phone or device-bound Passkey.) The more elaborate they set-up their account, the shorter the Time-Delays could be.

(The protection of the device-bound Passkeys for phones are biometrics of the phone; ideally the fallback PIN should not be available without another local Time-Lock. Whatever software protects the passkey may impose additional protections.)

[1]: https://passkeys.dev/docs/reference/terms/#device-bound-passkey , [3]
[2]: FIDO2, WebauthN, https://passkeys.dev/docs/reference/terms/#cross-device-authentication-cda
[3]: Example of device-bound Passkey on Phone in the wild: https://rebrand.ly/dbpk-3cd2ba and https://rebrand.ly/dbpk-cada1a
[4]: Perhaps useful: https://contentcredentials.org/ https://contentauthenticity.org/

(Ref: https://together.bunq.com/d/57992-suggestion-passkey-support/10 )

KeesDecrauwvanAalsburg

I totally agree. But i want to have the option of these functions and not forced. It's the money of me and my partner and want to use it as we like, that's why we bank by Bunq (the bank of the free)

Iskandar

Agree. I'd definitely like to have an optional TOTP for certain actions, such as changing limits or transferring certain amounts of money to accounts outside my bunq environment.

On top of that. I wish bung would have a decent customer service with actual humans to speak to. Can't imagine the frustration when someone sweeps your bank accounts and you can't find a single person at bunq to speak to.

thijsoost

Joeri I'm a big supporter of Passkeys! Unfortunately, they're still unknown to a lot of people. I've got two physical Yubikeys and my password manager (Dashlane) also supports Passkeys. I believe Passkeys are available on Both Android and iOS since 2022, so not that long. I hope more and more services will support Passkeys so users also get familiar with them!

TSG

Great ideas. What I don't really understand is why bunq does not offer more choices and options so users can tailor their accounts to their specific needs. For example, they could design certain freedom/risk profiles, allowing users to decide whether they want to have time locks on specific account changes. When you select a maximum freedom profile, this also means you are fully responsible for falling for any kind of phishing attempt. Additionally, they could make various extra security measures optionally available, such as the use of hardware keys like Yubikeys for MFA. On this forum, I see people arguing whether certain measures are necessary or not; just give freedom to users to make their own choices! Furthermore, obviously, emergency support needs to be strongly improved (a no-brainer). Perhaps even a voice or video call option can be securely integrated into the app.