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 -- Florian Snow - Free Software Foundation Europe e.V. Schönhauser Allee 6/7, 10119 Berlin, Germany Registered at Amtsgericht Hamburg, VR 17030 Your support enables our work (fsfe.org/join) _______________________________________________ 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