Hello everyone,
As part of my job at the FSFE, I have been working on the topic of Free Software in banking and I would like to share some of my findings and thoughts with you. This is part of the larger topic of appification/forcing users to use non-free apps to do certain interactions.
Personally, I noticed over the past years that banks are trying very hard to push their non-free apps for banking in general and also for what they call two factor authentication. In fact, they often block other means of authentication altogether. This is of course a problem for us and so I dug a little deeper into this topic.
The Dutch FSFE team made a wonderful start here by contacting a bank about why they make it difficult to use Free Software while using their services. My task was to follow up in a more general way. Unfortunately, it has been very difficult to get answers directly from banks. A very common response was that there are legal requirements to do things the way they do and that the technical departments made sensible decisions that shouldn't be questioned too much.
One reason that banks did sometimes point to was PSD2, an EU Directive that regulates payment services and payment service providers. The way I see it after doing some background research, PSD2 doesn't appear to require specific technical measures, also not for the second factor. However, the way banks interpret PSD2, it means they need to tie the secrets used for authentication to specific hardware. In my opinion, this interpretation is the first problem for Free Software because even though this may not be a legal requirement, it rules out two factor solutions such as TOTP where the secret could be used on multiple devices or simply extracted by using a TOTP app that allows that.
The second big problem here is that banks "tie the authentication secrets to the hardware" completely in software. This is what necessitates the banking apps to do checks for rooted phones and so on because if a phone is rooted, the secret could theoretically be extracted. The root checks usually happen through the use of libraries in the apps that promise security even in malicious environments, such as a phone infested by malware. The banks currently rely more on this promise of security than actual security because real security would mean implementing proper two factor authentication instead of running two apps on the same phone and calling that two factor authentication.
The problem with these issues combined is that because virtually all banks do it this way, it has become somewhat of a best practice. Banks fear that if they were to do it differently, they could be held liable in case of an alleged unauthorized transaction. Unfortunately, just like in other areas, it is often easier to do what everyone else is doing, even if it has flaws because at least you can defend what you're doing by saying you're following the "standard". And in this case that means restricting Free Software as a side-effect.
A kind of way out of this is the use of secure elements of phones. By using them, the authentication secrets would actually be tied to the hardware. This would mean Free Software could use the secure element in a similar way to a smart card where we simply ask it to sign a transaction and that way, the root checks and non-free apps would not be necessary. However, just like with a smart card, there would typically still be non-free computations happening in hardware. So this would not be a perfect solution either.
The bigger problem, though, is that there is no standard way of communicating with secure elements and that makes it tricky for banks to use them, plus they would need to maintain a list of secure elements, just like a list of CAs. In addition to that, banks might not move to that solution if there is no certification for it while they have a working solution; there's simply not much of an incentive for them to change what they have.
One thing I found out is that banks often still use older standards that allow access with Free Software. For instance, some apps give error messages with HBCI error codes. This sounded promising at first because if there still is a system somewhere that is compatible with Free Software, then perhaps we could access it. Unfortunately what often happens is that banks apparently just put another layer around an older interface and then only provide the newer layer to the outside world. This may even make sense from a security perspective if maintenance of those older systems is tricky. It enables banks to continue using legacy systems internally without exposing security holes while still staying somewhat modern on the outside. That means it's not as simple as saying that they run HBCI internally, they might as well give us access as they used to.
Another way in is that banks are required to provide access to third parties to enable new services on top of existing bank accounts. Unfortunately, while this would theoretically enable someone to provide such a service in Free Software, typically the second factor app from the bank is still required for logging in, so that doesn't help us all that much either.
At some point, I thought there was one example of a bank that does allow TOTP as a second factor (or no second factor at all): Paypal. But from what I understand, Paypal doesn't act as a bank in that regard, they are only a payment provider and use their banking license for other things. So the two are separate and that means that even though it looks like a positive example in this regard at first, Paypal isn't really because the requirements for payment providers are very different.
I'm curious to hear what you think about this topic. What's your experience with your bank? How do you do your banking? Is there an important angle that I missed? I appreciate any feedback.
Happy hacking! Florian
Hello Florian, hello all,
Am Thu, Feb 22, 2024 at 07:35:24PM +0100 schrieb Florian Snow:
As part of my job at the FSFE, I have been working on the topic of Free Software in banking and I would like to share some of my findings
Thanks for that! Do you mind sharing some sources of your research? I've had a discussion with a colleague a few days ago about the security of having both factors on the same device. I couldn't find good articles backing my point in the remainder of the lunch break.
I'm curious to hear what you think about this topic. What's your experience with your bank? How do you do your banking? Is there an important angle that I missed? I appreciate any feedback.
Because of the difficulties you described I switched to GLS Bank a bit more than a year ago. They still allow banking with a TAN generator and the chip on the maestro/debit card. It was a bit bumby to activate the account without the app (which seems to be their default as well) but the problem could be fixed with a short phone call and everything is fine since then.
However, if they ever decide to stop providing this method, I don't know what else to do, so this still concerns me.
Ideally, there would be some regulation in place making it mandatory for banks to provide an alternative to (proprietary) apps - or make it possible to do banking without a smartphone.
Greetings,
Guido
Hello all,
Thank you for sharing these details. I think it will be a valuable basis for further steps. I can see us tracking this issue in a similar way to how we track the status of Router Freedom. Do any of you see political opportunity to adress this issue?
Paul Boddie already touch on this a bit in his response by mentioning other groups that also struggle with these apps in their daily life.
In the Netherlands the governmental authentication app was being pushed in favor of SMS. This caused quite some uproar and it was promised that a suitable alternative should be in place, including open source. To me it is still unclear what this will mean in practice. And this doesn't provide any guarantees for private sector banking apps.
Best, Nico
Hi Nico, all
On 27/02/2024 9:41 pm, Nico Rikken wrote:
I can see us tracking this issue in a similar way to how we track the status of Router Freedom. Do any of you see political opportunity to adress this issue?
I recommend to do some further research around PSD2 and in particular delegated acts and standards that have been introduced. Based on that one can evaluate opportunities. I think it is not the same like in router freedom.
Best Alex
Hi Guido,
Guido Arnold, 2024-02-22 22:07 +0100 (UTC+0100):
Thanks for that! Do you mind sharing some sources of your research? I've had a discussion with a colleague a few days ago about the security of having both factors on the same device. I couldn't find good articles backing my point in the remainder of the lunch break.
Most of it were personal conversations and I can't really share that. In regards to the second factor, I tried to find something public, but all I could quickly find right now is a somewhat older video that confirms some of what I describe: https://media.ccc.de/v/34c3-8805-die_fabelhafte_welt_des_mobilebankings (The video is in German.)
Happy hacking! Florian
I'm curious to hear what you think about this topic. What's your experience with your bank? How do you do your banking? Is there an important angle that I missed? I appreciate any feedback.
I heard of at least one bank in my country that charges more for transfers made via the website than it charges for transfers made via its app (I think it was ING but I might be wrong) — that kind of agrees with what you are saying here.
OTOH, I heard of a bank app that first checks if the phone may be rooted and if it may, it imposes some limit on the transfer. That's interesting because if the legality were the only motivation for checking root presence, the bank would likely disallow all transfers instead of allowing them with some limits, right?
As to myself, I still use my bank via its website. When I was opening the account, I was told it's going to work without JS. It turned out to be false (the bank employees were misinformed/the manual was outdated). I kept the account nevertheless — it seems no bank here in Poland nowadays has a web interface without nonfree JS (I inquired about this — via email — at all commercial ones).
Even though I'd like to, I haven't yet tried RE-ing the JS of my bank — it fails to land high enough on my priorities list. And that's the problem — we're worried about being locked by Google Play Integrity but even with the lock absent, we fail to come up with free software for banking :/
At some point after opening my account I learned that Woob supposedly has support for some banks[1], likely developed by scraping their websites. I don't know how many of them are actual "banks" in the sense we mean it and how much does work there. Nevertheless, it seems like something worth investigating.
Best Wojtek
[1] https://woob.tech/applications/bank
-- (sig_start) website: https://koszko.org/koszko.html fingerprint: E972 7060 E3C5 637C 8A4F 4B42 4BC5 221C 5A79 FD1A follow me on Fediverse: https://friendica.me/profile/koszko/profile
♥ R29kIGlzIHRoZXJlIGFuZCBsb3ZlcyBtZQ== | ÷ c2luIHNlcGFyYXRlZCBtZSBmcm9tIEhpbQ== ✝ YnV0IEplc3VzIGRpZWQgdG8gc2F2ZSBtZQ== | ? U2hhbGwgSSBiZWNvbWUgSGlzIGZyaWVuZD8= -- (sig_end)
On Thu, 22 Feb 2024 19:35:24 +0100 Florian Snow floriansnow@fsfe.org wrote:
Hello everyone,
As part of my job at the FSFE, I have been working on the topic of Free Software in banking and I would like to share some of my findings and thoughts with you. This is part of the larger topic of appification/forcing users to use non-free apps to do certain interactions.
Personally, I noticed over the past years that banks are trying very hard to push their non-free apps for banking in general and also for what they call two factor authentication. In fact, they often block other means of authentication altogether. This is of course a problem for us and so I dug a little deeper into this topic.
The Dutch FSFE team made a wonderful start here by contacting a bank about why they make it difficult to use Free Software while using their services. My task was to follow up in a more general way. Unfortunately, it has been very difficult to get answers directly from banks. A very common response was that there are legal requirements to do things the way they do and that the technical departments made sensible decisions that shouldn't be questioned too much.
One reason that banks did sometimes point to was PSD2, an EU Directive that regulates payment services and payment service providers. The way I see it after doing some background research, PSD2 doesn't appear to require specific technical measures, also not for the second factor. However, the way banks interpret PSD2, it means they need to tie the secrets used for authentication to specific hardware. In my opinion, this interpretation is the first problem for Free Software because even though this may not be a legal requirement, it rules out two factor solutions such as TOTP where the secret could be used on multiple devices or simply extracted by using a TOTP app that allows that.
The second big problem here is that banks "tie the authentication secrets to the hardware" completely in software. This is what necessitates the banking apps to do checks for rooted phones and so on because if a phone is rooted, the secret could theoretically be extracted. The root checks usually happen through the use of libraries in the apps that promise security even in malicious environments, such as a phone infested by malware. The banks currently rely more on this promise of security than actual security because real security would mean implementing proper two factor authentication instead of running two apps on the same phone and calling that two factor authentication.
The problem with these issues combined is that because virtually all banks do it this way, it has become somewhat of a best practice. Banks fear that if they were to do it differently, they could be held liable in case of an alleged unauthorized transaction. Unfortunately, just like in other areas, it is often easier to do what everyone else is doing, even if it has flaws because at least you can defend what you're doing by saying you're following the "standard". And in this case that means restricting Free Software as a side-effect.
A kind of way out of this is the use of secure elements of phones. By using them, the authentication secrets would actually be tied to the hardware. This would mean Free Software could use the secure element in a similar way to a smart card where we simply ask it to sign a transaction and that way, the root checks and non-free apps would not be necessary. However, just like with a smart card, there would typically still be non-free computations happening in hardware. So this would not be a perfect solution either.
The bigger problem, though, is that there is no standard way of communicating with secure elements and that makes it tricky for banks to use them, plus they would need to maintain a list of secure elements, just like a list of CAs. In addition to that, banks might not move to that solution if there is no certification for it while they have a working solution; there's simply not much of an incentive for them to change what they have.
One thing I found out is that banks often still use older standards that allow access with Free Software. For instance, some apps give error messages with HBCI error codes. This sounded promising at first because if there still is a system somewhere that is compatible with Free Software, then perhaps we could access it. Unfortunately what often happens is that banks apparently just put another layer around an older interface and then only provide the newer layer to the outside world. This may even make sense from a security perspective if maintenance of those older systems is tricky. It enables banks to continue using legacy systems internally without exposing security holes while still staying somewhat modern on the outside. That means it's not as simple as saying that they run HBCI internally, they might as well give us access as they used to.
Another way in is that banks are required to provide access to third parties to enable new services on top of existing bank accounts. Unfortunately, while this would theoretically enable someone to provide such a service in Free Software, typically the second factor app from the bank is still required for logging in, so that doesn't help us all that much either.
At some point, I thought there was one example of a bank that does allow TOTP as a second factor (or no second factor at all): Paypal. But from what I understand, Paypal doesn't act as a bank in that regard, they are only a payment provider and use their banking license for other things. So the two are separate and that means that even though it looks like a positive example in this regard at first, Paypal isn't really because the requirements for payment providers are very different.
I'm curious to hear what you think about this topic. What's your experience with your bank? How do you do your banking? Is there an important angle that I missed? I appreciate any feedback.
Happy hacking! Florian
I'm curious to hear what you think about this topic.
In my opinion it is a serious problem. Not only about banks: everybody and everything is willing to install trojan horses in our telephones. And the telephone is becoming a bad SPoF -- but most users don't care because everything is backed-up on the vendor's cloud system, so nothing is lost if the telephone drowns in the lake.
But that's old news in this group.
I recently updated by ID card, and the papers I received suggest to install the national app from the play store. Our public administration is strongly suggesting to make an account on a foreign private company. I wasn't quick enough to tell the officer. When I met a not-so-unsavvy friend who works in the same office (but another town), he dismissed my complaint as irrelevant. So that's the world we live in. And I live well withot that app, but the suggestion is very strong.
What's your experience with your bank?
My bank wants me to call a free-of-charge number and dial in the digits it gave me on the web interface. Which is only accepted from the registered telephone number. So I'm happy, in this respect, but it's not common. Other family members installed the app of their bank. My bank has the app, but it's not mandatory: they still accept clients with real telephones, like mine.
I'm convinced that the only way forward is having two devices. One with our contacts and osm and such stuff, and one owned by the vendor where we install the mandatory apps -- to be stored off and/or offline most of the time.
But I'm scared. In the current social and geopolitical situation, all minority groups are perceived as one and the same -- because very often who is against common ideas and practices in one field is against them on other fields too. As a result, we are easily associated with conspiration theories, and thus disregarded by most sensible people.
Hi Florian and all subscribed,
Thanks for the elaborate mail and investigation. As you mentioned we have been at this in the Netherlands for quite some while already. My personal experience is more in regards to mobile governmental identification which too revolves around non-free mobile apps.
[https://blogs.fsfe.org/nico.rikken/2022/03/16/dutch-digital-identity-system-...)
I'll break down this email down into some topics, hoping to increase the detail in our discussion. It is quite elaborate, also to straighten my own thinking.
### How did we end up here?
Growing up I had a debit card with my bank account. I could go to the bank office to arrange many things. I could leave a wire transfer form at the bank with my autograph to make a transfer or make a payment. With the debit card I could pay directly at the store or go to the ATM to get cash. At the ATM I could also check my account balance to make sure I had enough there.
Then internet became abundant. At home you could log in online to check your account balance and make transfers. A username and password wasn't secure enough. Some banks used a sheet of TAN-codes where you'd get a challenge and you'd have to look up the corresponding response code. The security of TAN-codes was increased by sending dedicated codes over SMS which prevented copying of the sheets. Some banks had a unique identifier which you'd have to keep around as the trust was in the identifier. Some banks used identifiers that could be share as they used the debit card for verification. Later identifiers even had a camera that could scan photo-TAN codes to make sure you knew what you were authorizing and to prevent attacks where the contents of the website was changed.
On mobile I recall some apps with early technology that only allowed you to check your balance ('saldo check'), perhaps because mobile transfers weren't considered secure. Over time banking apps got more capabilities and you could make transfers without an external identifiers and at some point you could even start using them as an identifier for banking from your computer. Since Apple and Google dominated the mobile operating space, the features in the app closely followed the developments of the mobile operating systems. Rather than typing a password you could start authenticating with facial recognition or using your fingerprint, paying with the app in the store as if it was a debit card became a thing, even using a smart watch.
In 2015 in the Netherlands the new technology-focused bank Bunq even started mobile-first. Everything relied on the app. You could create an account after identifying yourself by photographing some ID and your face. There was no website to use as an alternative.
And now with mobile apps being so abundant, it is assumed most people use the app. Some banks are eroding the online experience by removing features from the website and creating new features only in the app. This is something André is keeping track of in the Netherlands.
Businesses and organisations might have another perspective to add to this view, as I've heard that in the past some protocols were used. I remembers that one of my sportclubs in the past used some protocol to send wire transfers digitally.
Regarding the security developments, in the Netherlands people are being robbed on the street where they are being forced to log into their app and transfer the maximum amount to an account of a money mule. Security has become so goed that the human is now the weakest link. Like the XKCD comic [https://xkcd.com/538/%5D(https://xkcd.com/538/) Sometimes I wonder if I should just remove my banking app entirely for this risk. And banks don't refund you because you authorised the transfer.
Going over this history I see a couple of trends:
- Banks make it easy to do business with them digitally by providing 24/7 in your pocket availability. Ease of use is important, which is why the latest platform features are used. - Security is a continued effort where technology changes constantly to address the weakpoints exploited by attackers. - Banks don't want to keep (older) alternatives around and reduce it to the minimum in availability and features.
### Digital security
Security is important to banking because money is attractive to thieves, directly hurts the account holders and might have financial consequences for the banks. Which is why there has been a shift in technology. From printed TAN-codes to temporary SMS-tokens to prevent copying. From simple identifiers to ones that use Photo-TAN to show the financial consequences of your authorization to prevent modified transaction details in compromised webbrowsers.
In 2021 the Dutch bank Knab started demanding users to switch to apps for authentication, removing support for the hardware identifiers. The financial regulator considered this reasonable behavior and suggested that the customer would change to a different bank offering an identifier. [https://www.security.nl/posting/722428/Knab+mag+smartphone-app+voor+gebruik+...) Something similar is happening with the Dutch Triodos bank where customers are switching away since they started removing some features in the webbrowser and provide them app-only.
As you mentioned, this is why TOTP isn't suitable, because there is no guarantee that the code is not copied. Solutions have to rely on an external copy-resistant chip/device that stores the material (could be a debit card) or rely on system on chips that have such features built in.
Furthermore, mobile operating systems are more unified with regards to design and security measures to guarantee that nobody messes with the banking app or how it is displayed. You wouldn't want an app to listen in on your pin code, start a fake transaction by simulating screen input or trick you into a transaction by visually changing the amount. Such kind of attacks were common on webbrowsers in the past. As you mentioned banking apps have mechanisms in place to detect less secure environments like rooted phones.
In recent months I learned that methods of rooting now also come with methods to disguise the rooting to make sure that banking apps still function. It seems to be a cat and mouse game.
There are parallels in other security measures like smartcards or modern USB replacements. There exist Free Software firmware implementations like Gnuk and Nitrokey. As I understood in Germany you can identify yourself digitally using the FOSS AusweisApp2 that similarly relies on the chip in the ID-card. Security in chips doesn't address the risk of attackers altering input or output to have you sign a different transaction. This is addressed by dedicated identifiers using Photo-TAN and is also something being addressed by hardware Crypto-wallets (e.g. Trezor) that come with a screen.
FIDO2 seems to be a promising standardised security solution which also supports multiple token variants. I have no practical experience with it though. Still it lacks the guarantees to prevent visual tempering.
I know other means of providing security which have different guarantees. The Dutch FOSS Yivi identification app (previously IRMA) relies on a central webservice during the authentication process which allows you to disable use when your device is lost or stolen (cryptographically it is much more complex).
Some takeaways:
- Banks rely on mobile operating system features and some external detecting software to guarantee security, resulting in a technology lock-in. - It is a cat and mouse game of attackers and control-seeking users working around measures and of banks to increase security and control together with platform developers and security software providers. - Security mechanisms based on chips or external tokens (incl. FIDO2) might enable free software implementations, but the risk of compromised environment (browser/app) remains.
### How does this affect Free Software?
Banking is inherently an external service. The main control is about how we interface with banking. I think it is clear that an app-only bank requiring an iOS or Android with Google services operating system is violating technical user freedom as it ties the user to the banking app and consequently on of two non-free ecosystems.
Let's start from the viewpoint proposed by Richard Stallman in the Respects Your Freedom hardware certification (which can certainly be criticised). Basically that if it is siloed off and cannot changed by the user it is ok. This is why we can accept proprietary firmware on a harddisk controller. Bank cards function like this, with a dedicated chip running proprietary software, interacting via electronic connectors or NFC. Dedicated identifiers function like this, accepting input via challenge codes or photo-TAN. Some can even function over USB, although I'm not sure about the protocols. FIDO2 might be an enabler here.
To enable a Free Software banking app, it would be great if banks would provide an API. I don't think this is a realistic expectation. Banks want control over the user experience and the features provided by banks differ. Will banks trust users to use various applications to do their banking? I expect them to only to support this if required by legislation.
Besides a Free Software app, the second best would be to run the banking application as much in Free Software as possible: in a webbrowser. Modern websites can leverage the power of web standards for integration including for authentication. It can be provides as a Progressive Web App (PWA), so the application itself is cached. All required interaction is defined by standards and it then becomes OS independent and can even run on new GNU/Linux smartphones.
Besides banking and apps, more and more situations only allow wireless NFC payments, sometimes even without a pinpad. Ideally NFC-payments should be possible using free software or debit cards should stay around.
### What can we do to change the status quo?
Some things come to mind:
- We can raise awareness around this issue. Besides all the technical arguments, it is important that people involved in policy and technology are aware of our perspective on things. - We can keep track of relevant metrics per bank and per country to be explicit on how large this issue really is. - We can demand a standards-based browser-first approach which will also be the most portable one. All digital banking features (like creating accounts, setting limits, etc.) should be available in the webbrowser, regardless if used on desktop or mobile. - We can demand a non-app authentication/authorization-solution to be available. This can be a simple identifier with a pin code or something more elaborate that can visualize the transaction being authorized to offer more guarantees. - We can demand banking API's to be available that allows user to use a custom (free software) application for the common day-to-day banking tasks. A stretch goal might be to have API's for all the features offered by the bank through the webbrowser. - We can demand the availability of physical cards to also have a way for wireless payment. - We can demand the support for NFC-payment via Free Software. I lack technical knowledge in this area wat is possible and is already in place. - As a last resort we can demand banking features to be available in analog style at the bank and digitally at the ATM. But I would rather like us to be able to participate in the digital realm on an equal level as everybody else. - We need to address these issues on a regulatory level to prevent each bank phasing out hardware identifiers as we are now seeing in the Netherlands. In the Netherlands the ATMs have become shared infrastructure (Geldmaat) to share the cost. Something similar could be done for identifiers to reduce overhead for individual banks.
I think we can make similar demands for identification apps, which have many similarities and also tie people to the mobile operating system duopoly.
Looking forward to continue this discussion to refine it to concrete FSFE-actions.
Best, Nico
I have some more thoughts. First, context (which most of you know):
The roots checks performed by apps are a strong problem because they (1) block people from using a nonfree app on an otherwise free phone and (2) have the potential to prevent reverse-engineering efforts against the app. Statement (2) might not be obvious but it's true — most apps seem to be using Google Play Integrity APIs (which I'll refer to as "GPI" from now on). GPI can consult the device's cryptographic coprocessor to prove that the device still has its bootloader locked (and is therefore unrooted, unless via unofficial means like exploiting a kernel vulnerability or similar). A proof[1] generated by such cryptographic hardware module would then be verified server-side by the bank. If verification fails, bank can partially or completely limit app's functions.
Not all banks require the such strong, hardware verification right now. But they could start requiring it at any time.
So, in this context, is anyone aware how things look like on Huawei phones? They now come without Google Play and with Google services replaced by Huawei ones. Is GPI absent there? Is there an analogous component instead?
That would be relevant because Huawei is one of the major mobile phone manufacturers. It seems to have even convinced some banks to add their apps to its AppGallery. While all this is still proprietary, it might be opening up an entrance for freesw folks willing to reverse-engineer their way to app freedom.
Btw, I wonder if GPI violates existing consumer and *competition* protection laws? As I understand it, CPU/phone manufacturer must go into some deal with Google to have its crypto silicon respected by GPI. Otherwise, we'd be able to install GPI on a device we fully control and cryptographic proof would be meaningless. So independent CPU/phone manufacturers are effectively harmed by anti-competitive practices of Google.
Best Wojtek
[1] Even keys hidden in hardware can theoretically be extracted from microscopic photos of the integrated circuit (which would enable reverse-engineering). But this is unfortunately beyond the reach of our tiny freesw community :c
-- (sig_start) website: https://koszko.org/koszko.html fingerprint: E972 7060 E3C5 637C 8A4F 4B42 4BC5 221C 5A79 FD1A follow me on Fediverse: https://friendica.me/profile/koszko/profile
♥ R29kIGlzIHRoZXJlIGFuZCBsb3ZlcyBtZQ== | ÷ c2luIHNlcGFyYXRlZCBtZSBmcm9tIEhpbQ== ✝ YnV0IEplc3VzIGRpZWQgdG8gc2F2ZSBtZQ== | ? U2hhbGwgSSBiZWNvbWUgSGlzIGZyaWVuZD8= -- (sig_end)
On Sun, 25 Feb 2024 13:30:35 +0100 Nico Rikken nico.rikken@fsfe.org wrote:
Hi Florian and all subscribed,
Thanks for the elaborate mail and investigation. As you mentioned we have been at this in the Netherlands for quite some while already. My personal experience is more in regards to mobile governmental identification which too revolves around non-free mobile apps. [https://blogs.fsfe.org/nico.rikken/2022/03/16/dutch-digital-identity-system-...)
I'll break down this email down into some topics, hoping to increase the detail in our discussion. It is quite elaborate, also to straighten my own thinking.
### How did we end up here?
Growing up I had a debit card with my bank account. I could go to the bank office to arrange many things. I could leave a wire transfer form at the bank with my autograph to make a transfer or make a payment. With the debit card I could pay directly at the store or go to the ATM to get cash. At the ATM I could also check my account balance to make sure I had enough there.
Then internet became abundant. At home you could log in online to check your account balance and make transfers. A username and password wasn't secure enough. Some banks used a sheet of TAN-codes where you'd get a challenge and you'd have to look up the corresponding response code. The security of TAN-codes was increased by sending dedicated codes over SMS which prevented copying of the sheets. Some banks had a unique identifier which you'd have to keep around as the trust was in the identifier. Some banks used identifiers that could be share as they used the debit card for verification. Later identifiers even had a camera that could scan photo-TAN codes to make sure you knew what you were authorizing and to prevent attacks where the contents of the website was changed.
On mobile I recall some apps with early technology that only allowed you to check your balance ('saldo check'), perhaps because mobile transfers weren't considered secure. Over time banking apps got more capabilities and you could make transfers without an external identifiers and at some point you could even start using them as an identifier for banking from your computer. Since Apple and Google dominated the mobile operating space, the features in the app closely followed the developments of the mobile operating systems. Rather than typing a password you could start authenticating with facial recognition or using your fingerprint, paying with the app in the store as if it was a debit card became a thing, even using a smart watch.
In 2015 in the Netherlands the new technology-focused bank Bunq even started mobile-first. Everything relied on the app. You could create an account after identifying yourself by photographing some ID and your face. There was no website to use as an alternative.
And now with mobile apps being so abundant, it is assumed most people use the app. Some banks are eroding the online experience by removing features from the website and creating new features only in the app. This is something André is keeping track of in the Netherlands.
Businesses and organisations might have another perspective to add to this view, as I've heard that in the past some protocols were used. I remembers that one of my sportclubs in the past used some protocol to send wire transfers digitally.
Regarding the security developments, in the Netherlands people are being robbed on the street where they are being forced to log into their app and transfer the maximum amount to an account of a money mule. Security has become so goed that the human is now the weakest link. Like the XKCD comic [https://xkcd.com/538/%5D(https://xkcd.com/538/) Sometimes I wonder if I should just remove my banking app entirely for this risk. And banks don't refund you because you authorised the transfer.
Going over this history I see a couple of trends:
- Banks make it easy to do business with them digitally by providing
24/7 in your pocket availability. Ease of use is important, which is why the latest platform features are used.
- Security is a continued effort where technology changes constantly
to address the weakpoints exploited by attackers.
- Banks don't want to keep (older) alternatives around and reduce it
to the minimum in availability and features.
### Digital security
Security is important to banking because money is attractive to thieves, directly hurts the account holders and might have financial consequences for the banks. Which is why there has been a shift in technology. From printed TAN-codes to temporary SMS-tokens to prevent copying. From simple identifiers to ones that use Photo-TAN to show the financial consequences of your authorization to prevent modified transaction details in compromised webbrowsers.
In 2021 the Dutch bank Knab started demanding users to switch to apps for authentication, removing support for the hardware identifiers. The financial regulator considered this reasonable behavior and suggested that the customer would change to a different bank offering an identifier. [https://www.security.nl/posting/722428/Knab+mag+smartphone-app+voor+gebruik+...) Something similar is happening with the Dutch Triodos bank where customers are switching away since they started removing some features in the webbrowser and provide them app-only.
As you mentioned, this is why TOTP isn't suitable, because there is no guarantee that the code is not copied. Solutions have to rely on an external copy-resistant chip/device that stores the material (could be a debit card) or rely on system on chips that have such features built in.
Furthermore, mobile operating systems are more unified with regards to design and security measures to guarantee that nobody messes with the banking app or how it is displayed. You wouldn't want an app to listen in on your pin code, start a fake transaction by simulating screen input or trick you into a transaction by visually changing the amount. Such kind of attacks were common on webbrowsers in the past. As you mentioned banking apps have mechanisms in place to detect less secure environments like rooted phones.
In recent months I learned that methods of rooting now also come with methods to disguise the rooting to make sure that banking apps still function. It seems to be a cat and mouse game.
There are parallels in other security measures like smartcards or modern USB replacements. There exist Free Software firmware implementations like Gnuk and Nitrokey. As I understood in Germany you can identify yourself digitally using the FOSS AusweisApp2 that similarly relies on the chip in the ID-card. Security in chips doesn't address the risk of attackers altering input or output to have you sign a different transaction. This is addressed by dedicated identifiers using Photo-TAN and is also something being addressed by hardware Crypto-wallets (e.g. Trezor) that come with a screen.
FIDO2 seems to be a promising standardised security solution which also supports multiple token variants. I have no practical experience with it though. Still it lacks the guarantees to prevent visual tempering.
I know other means of providing security which have different guarantees. The Dutch FOSS Yivi identification app (previously IRMA) relies on a central webservice during the authentication process which allows you to disable use when your device is lost or stolen (cryptographically it is much more complex).
Some takeaways:
- Banks rely on mobile operating system features and some external
detecting software to guarantee security, resulting in a technology lock-in.
- It is a cat and mouse game of attackers and control-seeking users
working around measures and of banks to increase security and control together with platform developers and security software providers.
- Security mechanisms based on chips or external tokens (incl. FIDO2)
might enable free software implementations, but the risk of compromised environment (browser/app) remains.
### How does this affect Free Software?
Banking is inherently an external service. The main control is about how we interface with banking. I think it is clear that an app-only bank requiring an iOS or Android with Google services operating system is violating technical user freedom as it ties the user to the banking app and consequently on of two non-free ecosystems.
Let's start from the viewpoint proposed by Richard Stallman in the Respects Your Freedom hardware certification (which can certainly be criticised). Basically that if it is siloed off and cannot changed by the user it is ok. This is why we can accept proprietary firmware on a harddisk controller. Bank cards function like this, with a dedicated chip running proprietary software, interacting via electronic connectors or NFC. Dedicated identifiers function like this, accepting input via challenge codes or photo-TAN. Some can even function over USB, although I'm not sure about the protocols. FIDO2 might be an enabler here.
To enable a Free Software banking app, it would be great if banks would provide an API. I don't think this is a realistic expectation. Banks want control over the user experience and the features provided by banks differ. Will banks trust users to use various applications to do their banking? I expect them to only to support this if required by legislation.
Besides a Free Software app, the second best would be to run the banking application as much in Free Software as possible: in a webbrowser. Modern websites can leverage the power of web standards for integration including for authentication. It can be provides as a Progressive Web App (PWA), so the application itself is cached. All required interaction is defined by standards and it then becomes OS independent and can even run on new GNU/Linux smartphones.
Besides banking and apps, more and more situations only allow wireless NFC payments, sometimes even without a pinpad. Ideally NFC-payments should be possible using free software or debit cards should stay around.
### What can we do to change the status quo?
Some things come to mind:
- We can raise awareness around this issue. Besides all the technical
arguments, it is important that people involved in policy and technology are aware of our perspective on things.
- We can keep track of relevant metrics per bank and per country to
be explicit on how large this issue really is.
- We can demand a standards-based browser-first approach which will
also be the most portable one. All digital banking features (like creating accounts, setting limits, etc.) should be available in the webbrowser, regardless if used on desktop or mobile.
- We can demand a non-app authentication/authorization-solution to be
available. This can be a simple identifier with a pin code or something more elaborate that can visualize the transaction being authorized to offer more guarantees.
- We can demand banking API's to be available that allows user to use
a custom (free software) application for the common day-to-day banking tasks. A stretch goal might be to have API's for all the features offered by the bank through the webbrowser.
- We can demand the availability of physical cards to also have a way
for wireless payment.
- We can demand the support for NFC-payment via Free Software. I lack
technical knowledge in this area wat is possible and is already in place.
- As a last resort we can demand banking features to be available in
analog style at the bank and digitally at the ATM. But I would rather like us to be able to participate in the digital realm on an equal level as everybody else.
- We need to address these issues on a regulatory level to prevent
each bank phasing out hardware identifiers as we are now seeing in the Netherlands. In the Netherlands the ATMs have become shared infrastructure (Geldmaat) to share the cost. Something similar could be done for identifiers to reduce overhead for individual banks.
I think we can make similar demands for identification apps, which have many similarities and also tie people to the mobile operating system duopoly.
Looking forward to continue this discussion to refine it to concrete FSFE-actions.
Best, Nico
On 2/27/24 11:35, Wojtek Kosior wrote:
I have some more thoughts. First, context (which most of you know):
The roots checks performed by apps are a strong problem because they (1) block people from using a nonfree app on an otherwise free phone and (2) have the potential to prevent reverse-engineering efforts against the app. Statement (2) might not be obvious but it's true — most apps seem to be using Google Play Integrity APIs (which I'll refer to as "GPI" from now on). GPI can consult the device's cryptographic coprocessor to prove that the device still has its bootloader locked (and is therefore unrooted, unless via unofficial means like exploiting a kernel vulnerability or similar). A proof[1] generated by such cryptographic hardware module would then be verified server-side by the bank. If verification fails, bank can partially or completely limit app's functions.
Not all banks require the such strong, hardware verification right now. But they could start requiring it at any time.
the only bank i found to outright block devices from using the app was Revolut (trivial to bypass by adding to MagiskHide/Zygisk denylist).
bunq just showed some dismiss-able warning. ING.pl issued a warning message that some transaction limits are lowered (and blocked HCE contactless payments with a very generic message like "Data retrieval error"; worked on microG after adding to Zygisk denylist). PKO BP blocked fingerprint login.
the only one with Play Integrity/SafetyNet for me was mBank.pl, but even then, it still did not require the hardware-based MEETS_STRONG_INTEGRITY status, and only blocked 2 features: HCE via contactless Blik, and disabling FLAG_SECURE (which blocks making screenshots in the app).
i think too many completely unaware users, even running Android shipped by their device manufacturers, just don't pass GPI/SafetyNet checks for something like this to pass through. the McDonald's app with these and other invasive checks (such as whether com.topjohnwu.magisk is installed, or a directory named "TWRP" exists) stands as a good warning.
So, in this context, is anyone aware how things look like on Huawei phones? They now come without Google Play and with Google services replaced by Huawei ones. Is GPI absent there? Is there an analogous component instead?
there is a Huawei equiv: https://developer.huawei.com/consumer/en/hms/huawei-safetydetectkit
all banks i've checked some time ago either stayed on Google Play only, told customers certain app features are not available on Huawei devices, or went for implementing everything twice, e.g. using Google ML Kit for scanning QR codes on Google Android, and Huawei ML Kit on Huawei, instead of, say, ZXing.
That would be relevant because Huawei is one of the major mobile phone manufacturers. It seems to have even convinced some banks to add their apps to its AppGallery. While all this is still proprietary, it might be opening up an entrance for freesw folks willing to reverse-engineer their way to app freedom.
i've thought about doing that earlier, and i think it's achievable, but just a lot of work. bunq would probably be the best start point for that, since they officially offer API with Swagger-based documentation, a sandbox environment, and SDKs, even to individual customers. AFAIK the same API is used internally by their own apps. https://developer.bunq.com/
Btw, I wonder if GPI violates existing consumer and *competition* protection laws? As I understand it, CPU/phone manufacturer must go into some deal with Google to have its crypto silicon respected by GPI. Otherwise, we'd be able to install GPI on a device we fully control and cryptographic proof would be meaningless. So independent CPU/phone manufacturers are effectively harmed by anti-competitive practices of Google.
Best Wojtek
[1] Even keys hidden in hardware can theoretically be extracted from microscopic photos of the integrated circuit (which would enable reverse-engineering). But this is unfortunately beyond the reach of our tiny freesw community :c
-- (sig_start) website: https://koszko.org/koszko.html fingerprint: E972 7060 E3C5 637C 8A4F 4B42 4BC5 221C 5A79 FD1A follow me on Fediverse: https://friendica.me/profile/koszko/profile
♥ R29kIGlzIHRoZXJlIGFuZCBsb3ZlcyBtZQ== | ÷ c2luIHNlcGFyYXRlZCBtZSBmcm9tIEhpbQ== ✝ YnV0IEplc3VzIGRpZWQgdG8gc2F2ZSBtZQ== | ? U2hhbGwgSSBiZWNvbWUgSGlzIGZyaWVuZD8= -- (sig_end)
On Sun, 25 Feb 2024 13:30:35 +0100 Nico Rikken nico.rikken@fsfe.org wrote:
Hi Florian and all subscribed,
Thanks for the elaborate mail and investigation. As you mentioned we have been at this in the Netherlands for quite some while already. My personal experience is more in regards to mobile governmental identification which too revolves around non-free mobile apps. [https://blogs.fsfe.org/nico.rikken/2022/03/16/dutch-digital-identity-system-...)
I'll break down this email down into some topics, hoping to increase the detail in our discussion. It is quite elaborate, also to straighten my own thinking.
### How did we end up here?
Growing up I had a debit card with my bank account. I could go to the bank office to arrange many things. I could leave a wire transfer form at the bank with my autograph to make a transfer or make a payment. With the debit card I could pay directly at the store or go to the ATM to get cash. At the ATM I could also check my account balance to make sure I had enough there.
Then internet became abundant. At home you could log in online to check your account balance and make transfers. A username and password wasn't secure enough. Some banks used a sheet of TAN-codes where you'd get a challenge and you'd have to look up the corresponding response code. The security of TAN-codes was increased by sending dedicated codes over SMS which prevented copying of the sheets. Some banks had a unique identifier which you'd have to keep around as the trust was in the identifier. Some banks used identifiers that could be share as they used the debit card for verification. Later identifiers even had a camera that could scan photo-TAN codes to make sure you knew what you were authorizing and to prevent attacks where the contents of the website was changed.
On mobile I recall some apps with early technology that only allowed you to check your balance ('saldo check'), perhaps because mobile transfers weren't considered secure. Over time banking apps got more capabilities and you could make transfers without an external identifiers and at some point you could even start using them as an identifier for banking from your computer. Since Apple and Google dominated the mobile operating space, the features in the app closely followed the developments of the mobile operating systems. Rather than typing a password you could start authenticating with facial recognition or using your fingerprint, paying with the app in the store as if it was a debit card became a thing, even using a smart watch.
In 2015 in the Netherlands the new technology-focused bank Bunq even started mobile-first. Everything relied on the app. You could create an account after identifying yourself by photographing some ID and your face. There was no website to use as an alternative.
And now with mobile apps being so abundant, it is assumed most people use the app. Some banks are eroding the online experience by removing features from the website and creating new features only in the app. This is something André is keeping track of in the Netherlands.
Businesses and organisations might have another perspective to add to this view, as I've heard that in the past some protocols were used. I remembers that one of my sportclubs in the past used some protocol to send wire transfers digitally.
Regarding the security developments, in the Netherlands people are being robbed on the street where they are being forced to log into their app and transfer the maximum amount to an account of a money mule. Security has become so goed that the human is now the weakest link. Like the XKCD comic [https://xkcd.com/538/%5D(https://xkcd.com/538/) Sometimes I wonder if I should just remove my banking app entirely for this risk. And banks don't refund you because you authorised the transfer.
Going over this history I see a couple of trends:
- Banks make it easy to do business with them digitally by providing
24/7 in your pocket availability. Ease of use is important, which is why the latest platform features are used.
- Security is a continued effort where technology changes constantly
to address the weakpoints exploited by attackers.
- Banks don't want to keep (older) alternatives around and reduce it
to the minimum in availability and features.
### Digital security
Security is important to banking because money is attractive to thieves, directly hurts the account holders and might have financial consequences for the banks. Which is why there has been a shift in technology. From printed TAN-codes to temporary SMS-tokens to prevent copying. From simple identifiers to ones that use Photo-TAN to show the financial consequences of your authorization to prevent modified transaction details in compromised webbrowsers.
In 2021 the Dutch bank Knab started demanding users to switch to apps for authentication, removing support for the hardware identifiers. The financial regulator considered this reasonable behavior and suggested that the customer would change to a different bank offering an identifier. [https://www.security.nl/posting/722428/Knab+mag+smartphone-app+voor+gebruik+...) Something similar is happening with the Dutch Triodos bank where customers are switching away since they started removing some features in the webbrowser and provide them app-only.
As you mentioned, this is why TOTP isn't suitable, because there is no guarantee that the code is not copied. Solutions have to rely on an external copy-resistant chip/device that stores the material (could be a debit card) or rely on system on chips that have such features built in.
Furthermore, mobile operating systems are more unified with regards to design and security measures to guarantee that nobody messes with the banking app or how it is displayed. You wouldn't want an app to listen in on your pin code, start a fake transaction by simulating screen input or trick you into a transaction by visually changing the amount. Such kind of attacks were common on webbrowsers in the past. As you mentioned banking apps have mechanisms in place to detect less secure environments like rooted phones.
In recent months I learned that methods of rooting now also come with methods to disguise the rooting to make sure that banking apps still function. It seems to be a cat and mouse game.
There are parallels in other security measures like smartcards or modern USB replacements. There exist Free Software firmware implementations like Gnuk and Nitrokey. As I understood in Germany you can identify yourself digitally using the FOSS AusweisApp2 that similarly relies on the chip in the ID-card. Security in chips doesn't address the risk of attackers altering input or output to have you sign a different transaction. This is addressed by dedicated identifiers using Photo-TAN and is also something being addressed by hardware Crypto-wallets (e.g. Trezor) that come with a screen.
FIDO2 seems to be a promising standardised security solution which also supports multiple token variants. I have no practical experience with it though. Still it lacks the guarantees to prevent visual tempering.
I know other means of providing security which have different guarantees. The Dutch FOSS Yivi identification app (previously IRMA) relies on a central webservice during the authentication process which allows you to disable use when your device is lost or stolen (cryptographically it is much more complex).
Some takeaways:
- Banks rely on mobile operating system features and some external
detecting software to guarantee security, resulting in a technology lock-in.
- It is a cat and mouse game of attackers and control-seeking users
working around measures and of banks to increase security and control together with platform developers and security software providers.
- Security mechanisms based on chips or external tokens (incl. FIDO2)
might enable free software implementations, but the risk of compromised environment (browser/app) remains.
### How does this affect Free Software?
Banking is inherently an external service. The main control is about how we interface with banking. I think it is clear that an app-only bank requiring an iOS or Android with Google services operating system is violating technical user freedom as it ties the user to the banking app and consequently on of two non-free ecosystems.
Let's start from the viewpoint proposed by Richard Stallman in the Respects Your Freedom hardware certification (which can certainly be criticised). Basically that if it is siloed off and cannot changed by the user it is ok. This is why we can accept proprietary firmware on a harddisk controller. Bank cards function like this, with a dedicated chip running proprietary software, interacting via electronic connectors or NFC. Dedicated identifiers function like this, accepting input via challenge codes or photo-TAN. Some can even function over USB, although I'm not sure about the protocols. FIDO2 might be an enabler here.
To enable a Free Software banking app, it would be great if banks would provide an API. I don't think this is a realistic expectation. Banks want control over the user experience and the features provided by banks differ. Will banks trust users to use various applications to do their banking? I expect them to only to support this if required by legislation.
Besides a Free Software app, the second best would be to run the banking application as much in Free Software as possible: in a webbrowser. Modern websites can leverage the power of web standards for integration including for authentication. It can be provides as a Progressive Web App (PWA), so the application itself is cached. All required interaction is defined by standards and it then becomes OS independent and can even run on new GNU/Linux smartphones.
Besides banking and apps, more and more situations only allow wireless NFC payments, sometimes even without a pinpad. Ideally NFC-payments should be possible using free software or debit cards should stay around.
### What can we do to change the status quo?
Some things come to mind:
- We can raise awareness around this issue. Besides all the technical
arguments, it is important that people involved in policy and technology are aware of our perspective on things.
- We can keep track of relevant metrics per bank and per country to
be explicit on how large this issue really is.
- We can demand a standards-based browser-first approach which will
also be the most portable one. All digital banking features (like creating accounts, setting limits, etc.) should be available in the webbrowser, regardless if used on desktop or mobile.
- We can demand a non-app authentication/authorization-solution to be
available. This can be a simple identifier with a pin code or something more elaborate that can visualize the transaction being authorized to offer more guarantees.
- We can demand banking API's to be available that allows user to use
a custom (free software) application for the common day-to-day banking tasks. A stretch goal might be to have API's for all the features offered by the bank through the webbrowser.
- We can demand the availability of physical cards to also have a way
for wireless payment.
- We can demand the support for NFC-payment via Free Software. I lack
technical knowledge in this area wat is possible and is already in place.
- As a last resort we can demand banking features to be available in
analog style at the bank and digitally at the ATM. But I would rather like us to be able to participate in the digital realm on an equal level as everybody else.
- We need to address these issues on a regulatory level to prevent
each bank phasing out hardware identifiers as we are now seeing in the Netherlands. In the Netherlands the ATMs have become shared infrastructure (Geldmaat) to share the cost. Something similar could be done for identifiers to reduce overhead for individual banks.
I think we can make similar demands for identification apps, which have many similarities and also tie people to the mobile operating system duopoly.
Looking forward to continue this discussion to refine it to concrete FSFE-actions.
Best, Nico
Discussion mailing list Discussion@lists.fsfe.org https://lists.fsfe.org/mailman/listinfo/discussion
This mailing list is covered by the FSFE's Code of Conduct. All participants are kindly asked to be excellent to each other: https://fsfe.org/about/codeofconduct
Hi Florian and other discussion list members,
If you are in the Netherlands and want to avoid proprietary bank apps, then you have the following options for logging in to public banks:
- ING: scanner device - Rabo: scanner device - Volksbank: - ASN: browsercode - Regiobank: browsercode (phases out digipas device) - SNS: browsercode (phases out digipas device)
(- ABNAMRO: not an option, phases out their e.dentifier device) (- Bunq: not an option) (- Triodos: not an option, phases out their identifier device)
Best regards,
Hi everyone,
Thank you Florian for starting that discussion and thank you Nico for pointing it out on the Dutch list.
Since I wasn't subscribed to this list when the discussion started, I hacked together this reply from the list's archive. Hopefully, it will preserve the threading and such ...
On 27-02-2024 18:32, André Ockers wrote:
If you are in the Netherlands and want to avoid proprietary bank apps, then you have the following options for logging in to public banks:
- ING: scanner device
- Rabo: scanner device
- Volksbank:
- ASN: browsercode
- Regiobank: browsercode (phases out digipas device)
- SNS: browsercode (phases out digipas device)
ASN is also going to phase out the hardware token generator (Digipas). The remaining options will then be authentication through the app or browsercode.
Browsercode
I don't know much about the technical implication, but I have been told by ASN Bank it is essentially a long living cookie in your browser, which requires some second factor to set up. That second factor could be either the app or you registered phone number.
I have a long standing habit of cleaning all my cookies when a tab or window is closed. That would require me to re-authenticate the browsercode every time. But more important, I believe, is the security regarding that browsercode. Once authenticated and living on in your browser's cache, a security flaw in the browser could give a malicious site / app access to that browsercode. I'm not sure what measures have been implemented to prevent that, but it sure doesn't sound very reassuring.
ASN Bank suggested making use of a different browser (profile) for banking only. That way I wouldn't need to re-authenticate every time. I don't think that's a workable solution. For one, I would need to use that setup on every device I intend to access my bank account on (desktop, laptop(s), etc.).
App
ASN Bank recently introduced a new banking app. As with the previous app and as mentioned here for other banks, the app is only made available through the duopoly's app stores. Both worked on my device running LineageOS with MicroG without any warnings or issues.
However, the new app has, in my opinion, such a deteriorated UI/UE that I decided to no longer make use of it. That leaves me with the Digipas or browsercode and soon only browsercode (or nothing, see above).
Phone number
I also distaste having to register my phone number for more and more services. Soon getting hold of a person's registered phone number will increase the attack vector towards that person. The Dutch government's authentication tool DigiD suffers from the same defects. It's either app, which is only available through the duopoly, or registering a phone number to receive authentication codes by way of SMS - a rather insecure medium.
Cheers,
Sandro
Hi Sandro,
Thanks for providing more details about the situation in the Netherlands.
Best, Nico
Hi Nico,
Thank you for those detailed thoughts.
Nico Rikken, 2024-02-25 13:30 +0100 (UTC+0100):
And now with mobile apps being so abundant, it is assumed most people use the app. Some banks are eroding the online experience by removing features from the website and creating new features only in the app. This is something André is keeping track of in the Netherlands.
Yep, unfortunately what you're describing is part of a larger trend that I also perceive as problematic.
Regarding the security developments, in the Netherlands people are being robbed on the street where they are being forced to log into their app and transfer the maximum amount to an account of a money mule.
Well, while this is unfortunate, it's not something we can solve with Free Software. It's a separate question.
In 2021 the Dutch bank Knab started demanding users to switch to apps for authentication, removing support for the hardware identifiers.
I fear this will be the next step for many banks.
As you mentioned, this is why TOTP isn't suitable, because there is no guarantee that the code is not copied. Solutions have to rely on an external copy-resistant chip/device that stores the material (could be a debit card) or rely on system on chips that have such features built in.
Well, at least currently, that is not what many banks do, though. They implement this in software.
In recent months I learned that methods of rooting now also come with methods to disguise the rooting to make sure that banking apps still function. It seems to be a cat and mouse game.
I think it is as long as the user controls the device. For devices where the manufacturer takes great care that the user will never be in control (as certain fruit related vendors do), this is much less of a cat and mouse game, unfortunately.
To enable a Free Software banking app, it would be great if banks would provide an API. I don't think this is a realistic expectation. Banks want control over the user experience and the features provided by banks differ. Will banks trust users to use various applications to do their banking? I expect them to only to support this if required by legislation.
I disagree here. The features are pretty uniform for at least the basics and banks used to provide HBCI without problems for many years.
Besides a Free Software app, the second best would be to run the banking application as much in Free Software as possible: in a webbrowser. Modern websites can leverage the power of web standards for integration including for authentication. It can be provides as a Progressive Web App (PWA), so the application itself is cached. All required interaction is defined by standards and it then becomes OS independent and can even run on new GNU/Linux smartphones.
Yes, I agree that this is the second best option, but it's quite a step down. Just because you install non-free software through a browser, doesn't make it any more free.
Happy hacking! Florian
On Thu, Feb 22, 2024 at 07:35:24PM +0100, Florian Snow wrote:
I'm curious to hear what you think about this topic. What's your experience with your bank? How do you do your banking? Is there an important angle that I missed? I appreciate any feedback.
I have to interact with many different banks in several different countries (in the EU/EEA and outside) as part of my job, and also a few in my private life. Up to recently, the working systems were, depending on the bank:
* Get a nonce/TAN by SMS
* Mostly for USA banks: bog-standard TOTP (they call that "Google Authenticator", but FreeOTP+ or Aegis work perfectly well).
* Some kind of hardware token. Some tokens are "push a button and get a code", some are "enter a PIN code and get a code", some are "scan this color QR-like code" and that generates a code, some use (ABN AMRO Netherlands) one's debit card and a reader where one inputs a code + PIN code of the card, others (Germany Sparkasse) one scans something on the screen with the debit card inserted but one does not enter the card's PIN code.
I basically have a big collection of hardware tokens of different kinds in a big pot that I kept in a safe, and I take the pot out when I need to interact with such a bank.
* The main Luxembourg retail / commercial banks "standardise" on the Luxembourg scheme called "LuxTrust".
Over the last 1-2 years, some banks have indeed started to offer "mobile app only" and to refuse to issue hardware tokens or deactivate already issued hardware tokens, respectively. When I explain that I don't have a Google or Apple account to access these stores, the solution for big amounts in the higher-end business/private banks is... to send instructions by email. I kid you not.
On (Luxembourg) bank said the CSSF (the bank regulator) was forcing them to retire hardware tokens in favour of mobile app because that is "more secure". So I do my orders by email and by phone... like that is even more secure, yeah. The banks of the group in other countries still happily use hardware tokens.
Now, LuxTrust used to be available with a simple push-button hardware token, and officially still is. *But* the banks started announcing they would not allow logins with the token, and push for the Luxtrust mobile app, which uses the same certificate under the hood (the certificate is held by the Luxtrust company "on the cloud", so in reality one authenticates to LuxTrust and LuxTrust issues a signature with "your" certificate... which means that technically they are 100% able to fake your signature, and that is a LEGALLY BINDING SIGNATURE for contracts, according to the EU digital signatures directive, etc. How scary is that?). After pushing back, it turns out one can purchase for 105 EUR a hardware with a camera that scans a code on screen.
Luxtrust is also available through a real smartcard. The driver for that smartcard, and also the local webserver (I kid you not) necessary to use it on websites is available only for GNU/Linux amd64 (and Microsoft Windows and Mac OS X). The driver is a hacked version of the Gemalto driver (the smartcard is a Gemalto one); that hacked version cannot be installed concurrently with other variants of the same driver, so that you can either use Luxtrust smartcard on an OS install OR other Gemalto smartcards, but not both.
I had started, more years ago that I care to count, adding support to OpenSC, I got the authentication key working but not the signature key, because then the commands need to be authenticated to the smartcard; that was in principle not a big problem, I had the right password, I just needed to implement the protocol, but never got around to it, and I never succeeded in getting my patches merged into OpenSC due to some idiosyncracies of the smartcard protocol, which was nearly, but not quite, standard.
This exercise allowed me to realise one thing: authentication to a bank or government website uses the SIGNATURE KEY for authentification. Again, I kid you not. Basically, on a crypto level, it looks like any bank or government website (or generally any website to which one authenticates with a Luxtrust smartcard) can MAKE YOU CRYPTOGRAPHICALLY SIGN ANY LEGAL DOCUMENT without your consent, since usually authentication is made by signing a nonce... replace the nonce by the hash of contract, and you have just signed that contract with a qualified signature. Big facepalm...
On Thursday, 22 February 2024 19:35:24 CET Florian Snow wrote:
Hello everyone,
As part of my job at the FSFE, I have been working on the topic of Free Software in banking and I would like to share some of my findings and thoughts with you. This is part of the larger topic of appification/forcing users to use non-free apps to do certain interactions.
Thanks for raising this issue. Here are some observations from my interactions with Norwegian banks.
Following Nico's template, the evolution of authentication solutions for online banking in Norway over the last 25 years has mostly been as follows, in my experience:
1. Use of one-time codes issued on paper and sent to customers through the postal system.
2. The issuing to customers of code generation tokens which provide a code on screen when prompted. Although I believe that calculator-like devices have been issued by some banks, I have only used the very simple single-button devices. See the following for an example of the general form:
https://en.wikipedia.org/wiki/RSA_SecurID
3. The introduction of the BankID scheme, providing a single authentication mechanism for all participating institutions. This initially complemented the hardware authentication token approach but then broadened to encompass mobile- based implementations. Banks offer a login through BankID as a kind of single sign-on, although some have retained their own code-based login path as well.
4. The proliferation of "apps" for banking and the discouragement of hardware tokens, potentially charging customers fees for the provision of such tokens.
You can imagine that things were a lot simpler before stage 3. And plenty could be written about how BankID was rolled out, perhaps even by myself on earlier occasions. There were several concerns about what it entailed and represented, some of which Lionel touches on:
* Since BankID introduced a "certificate" that could be used for digital authorisation (or document/agreement signing), does the user have actual control over their certificate or are they delegating this to an entity that may lose control over it or misuse it?
* BankID initially required Java and ran as an application, not an applet, and wanted to perform "checks" on the user's environment. (I ran the browser in a chroot for slightly improved isolation, since this is a classic way for companies to claim "unsupported system" and coerce people into buying "a normal computer".)
The BankID experience has since evolved along different directions. For Web users, it became a JavaScript-based implementation running in the user's browser, presumably because Java became a liability. It was then rolled out as "BankID on mobile" to mobile users where I believe that it involved some kind of "secure element", most likely delivered using traditional SIM technology, but I wouldn't rule out vendor-specific technology at least in the case of Apple products.
What has since happened is that "BankID on mobile" is being retired, presumably due to vendors seeking to banish things like physical SIM cards altogether, now replaced by the "BankID app". However, this distinction now needs to be repeatedly explained along with a distinction between that "app" and whatever "app" a bank may be providing. This kind of confusion may actually prove helpful to any cause seeking to prevent needless technological churn and the instability and uncertainty it brings.
== Some Reflection ==
When one bank had to verify all their customers' identities to comply with legislation, they strongly encouraged use of their "app". This "app" was meant to scan the customer's passport using near-field communication, and then the user was supposed to take a picture of the photo page. Evidently this didn't work for many people and wasn't likely to work for many phone users, anyway.
Their guidance for people who didn't have the "app" circled back to a video showing someone using the "app"! Their functionality in the online banking interface for attaching an image of the customer's passport or other identification document didn't work. Consequently, they had to get a bunch of contractors in to staff their remaining branch offices to handle queues of people showing up to do things the old way.
All of this was accompanied by news stories of people trying to use their own phone to help their very worried elderly parents retain access to their bank accounts [1], along with tales of such people not having passports because, as you can expect, they don't tend to travel much any more. It was a complete fiasco involving a million people in total [2]. The people responsible for planning the effort really should have been fired.
What this tells us is that those wishing genuine accessibility to services are our allies. It would be easy for a response to the above situation to be the usual, lazy, "old people need to get digital" exhortation, advocating classes and courses for retired people, but a lot of people who had to queue up to keep their bank account were far from retirement age. Also, retired people are not necessarily sitting around bored and wondering what social media is all about, which is how such encouragement is usually framed, usually by people who try and shoehorn inappropriate technology into everything.
Just today I read another story about "digital exclusion" in schools for children with disabilities in various forms [3]. This isn't exactly the same issue as the one with banking, but it says a lot about attitudes when there is an opportunity to roll out technology. We are actually seeing the active neglect and marginalisation of people who cannot help their personal situation and condition [4], and when this is questioned, those responsible will seek refuge in the usual arguments about cost or efficiency, or that new technology brings "new possibilities" or whatever.
There are plenty of people who are legitimately unhappy with the way technology is being deployed, that their children are being obliged to use Internet-connected devices at school [5], for example. A lot of that circles back round to issues of control, proprietary applications and services, and the predatory nature of swathes of the technology industry, inventivised by perverse economic models, facilitated by corruption, and enabled at the level of the individual decision-maker by classic signs of addiction.
In isolation, Free Software advocacy only gets us so far. But in a broader coalition, it becomes apparent that many people share the same concerns, demonstrating that Free Software is a valuable component in a larger ethical framework. Which I will have mentioned before.
Paul
[1] https://www.nrk.no/nordland/dnb-krever-re-legitimering-av-kunder-_-mange-sli... [2] https://www.nrk.no/nyheter/dnb-kan-fa-dagboter-pa-grunn-av-legitimasjonsmang... [3] https://www.nrk.no/nyheter/alle-barn-kan-ikke-delta-pa-like-vilkar-i-den-dig... [4] https://www.nrk.no/vestfoldogtelemark/mener-laereboker-for-svaksynte-ikke-fu... [5] https://www.nrk.no/norge/skole-nettbrett-regnes-ikke-som-laeremiddel-1.16713...
(Sorry that these are all in Norwegian! Please enquire if you wish to know more about any of these articles.)
Hi Paul,
Thank you very much for your very thoughtful response!
Paul Boddie, 2024-02-27 16:34 +0100 (UTC+0100):
What this tells us is that those wishing genuine accessibility to services are our allies.
Agreed. This is one of the areas we need to look into because accessibility is a much broader angle that would help with similar issues in the realm of appification.
Happy hacking! Florian