Just use the bank's PWA, you'll be fine. Or sandboxed play services in a separate GOS user.
European banks are forced by EU's Payment Services Directive 2 (PSD2) to authenticate using MFA for any payment over 50 EUR.
So what is the second factor? Your phone. Once you pair the app in your phone with your account, you can authenticate your actions using that phone, even if you are otherwise banking using the web app on your computer. Most banks also insist on using their apps, they don't allow generic second factors. Since their apps require Android with SafeNet or iOS, they pretty much enforce the Google/Apple duopoly.
For now, there are other ways -- sms, which the banks are trying to phase out.
So I imagine situation elsewhere will be very similar.
edit: with cardTAN you get a OTP/TAN 'calculator' into which you put your smartcard to generate TANs on the fly.
I use it because to me this feels more like a real second factor, when I use my mobile for banking.
And there will likely be a time when the bank simply cuts access to the cardTAN system and only allow their apps. Screw them because that means I have to use a smartphone, which I really do not want. The cardTAN system has been very good so far in preventing fraud, once the phone is the token it suddenly gets a lot more complicated and less secure.
For those wondering about 2FA with these apps, factor 1 is "something you own" namely that particular phone/sim, and factor 2 is "something you know", your PIN.
You can still use cardTAN, but the app is way more convenient, especially with QR.
https://www.onespan.com/products/transaction-signing/cronto/...
This. My bank in France, BNP, does that. Every so often, when I connect to the app on the phone, it says something similar to "in accordance with <some regulation> a strong authentication must be made every <number> of sign-ins". You're presented with only one button that says something like "ok". You press it, and you're in business.
This is after requiring me to type in my pin, which must be precisely 6 digits, and some sequences are forbidden, so you can't type 1234 or similar. It doesn't seem to interact with the secure enclave in any way.
If this number of sign-ins is reached while I'm on a PC (which is the most likely), it'll send a confirmation request on the phone, so at least it works there. When paying online, I'll also get a confirmation request on the phone app.
On my professional account, with the same bank, the situation used to be exactly the same. But a few months ago, they switched away from that to sending a confirmation code via SMS for bank transfers. Credit card payments still have the app confirmation request.
> "don't ever run the front-end and the second factor on the same device"
This is required in some cases, probably unless you apply for the physical hardware token generator which costs extra. You must apply for the 2FA-app initialization through the banking app that you are supposed to run on the same phone. In both cases, it is basically impossible to have a backup. Also, the banking app and the banking key app are supposed to have a separate PIN/ short password or a biometric login. Of course, the biometric approach has all kinds of problems in legal challenges (e.g. something you know is protected differently to something you are). Also, something you know cannot be easily obtained while you are asleep. Also, you probably don't want to use your password manager on your mobile phone - so there you are, typing a generated password to log into the key/ 2FA app for security theater. If there wasn't the banking app right next to the key app, the bank could probably just use something like FreeOTP+ or Google Authenticator without reinventing the wheel, also enabling backups in the process and skipping sending physical mail with the initial setup tokens. But that would be too straight forward and not "enterprise" security or whatever. The situation in Czechia is more or less similar. The banks tend to belong to the same banking groups so the underlying infrastructure might be similar even though Czechia still does not have the Euro/ SEPA.
Of course they do. But they need to balance security with end user experience.
And since security for a bank is about risk management they can offset this risk in other areas to compensate e.g. additional processes for activities involving larger amounts of money.
That is positively insane. So if you don't use vanilla Android or iOS, you can't use a credit card for more than 50EUR? No phone, dumb phone, too bad?
Just over a month ago, a proposal to prevent that was posted here: https://news.ycombinator.com/item?id=36875940
We distribute LOB banking apps as PWAs to our customers. In no reality would I consider incorporating this into our tech stack. We use PWAs and avoid native apps precisely to maximize compatibility across arbitrary IT policies in our various customer installs.
I don't know if our customers want to use linux, windows, android or apple. I don't WANT to know anymore. I just want to target a common API (HTML5), add some bandaids for iOS/Safari (usually after WWDC each year) and move on with life. Throwing DRM and platform constraints into the mix sounds like I might as well go back to native (I won't).
We are one of the few vendors that will actually get into a heated argument and push back against customers over FUD security crap like this. If a prospect insists that we add some draconian DRM to our product stack, I would make it very clear to leadership that I do not think we should do business with that customer on technical grounds.
If you find yourself in a situation where you need to trust the client implicitly, then you have catastrophically failed in the rest of your design.
Up until about a year ago one major core provider had been using the password 'money' for all their client accounts, many of which were domain admins since that is a 'just make it work' button and they cannot actually tell you what privs their service accounts need. When we asked the clients to press them on it, we determined via cracking that they had changed it to 'monet' as a workaround. The standards for excellence are SO LOW.
> The standards for excellence are SO LOW.
I'm 99% sure I know which vendor you are referring to.
Almost everything in fintech is a hacky mess. This is our competitive advantage. Doing the barest-acceptable thing makes us look like rockstars compared to every other vendor in the space.