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)
Hello all,
Do you want to help advance mobile device user freedom? If so, please
nominate candidates by 19 March for the F-Droid board of directors. The
current developments around the mobile app stores of Apple and Google
make this is an incredibly important time to get involved!
https://f-droid.org/2024/02/28/help-advance-mobile-device-user-freedom-nomi…
Transparency: I am a current member of the F-Droid board of directors.
Best regards,
Matthias
--
Matthias Kirschner - President - Free Software Foundation Europe
Schönhauser Allee 6/7, 10119 Berlin, Germany | t +49-30-27595290
Registered at Amtsgericht Hamburg, VR 17030 |(fsfe.org/support)
Contact (fsfe.org/about/kirschner) Weblog k7r.eu/blog.html
Ada & Zangemann - A Tale of Software, Skateboards, and Raspberry
Ice cream - For everyone from 6 - 106 years - ada.fsfe.org
Dear FSFE Community, over the next several weeks KDE will celebrate the
KDE community's Plasma 6 megarelease in locations around the globe.
https://community.kde.org/Promo/Events/Parties/KDE_6th_Megarelease
Celebrations are planned at the following locations, among others:
- Málaga, Spain (26 February)
- Budapest, Hungary (28 February)
- Nürnberg, Germany (29 February)
- Cambridge, UK (29 February)
- Berlin, Germany (1 March)
- Barcelona, Spain (2 March)
- Ljubljana, Slovenia (4 March)
- Montréal, Canada (8 March)
- Valencia, Spain (sometime in May)
If you are a KDE user, or you are a Free Software enthusiast and you
want to show support for the work of the KDE community, it's be great to
have you join us -- all are cordially invited! Take a look at the wiki
link above for event details.
And if you are KDE fan or community member/contributor, perhaps you
would like to organize a megarelease party yourself? Don't hesitate to
be in touch with me or the KDE community for organizational support.
Cheers,
Joseph
Links:
"Exploring Plasma 6", Linux Magazine:
https://www.linux-magazine.com/Issues/2024/280/Plasma-6
"Introducing the KDE Slimbook V, first laptop with Plasma 6", 22 Feb.
announcement:
https://discuss.kde.org/t/introducing-the-kde-slimbook-v-first-laptop-with-…
"This week in KDE: Inching closer", blog post Nate Graham:
https://pointieststick.com/2024/02/09/this-week-in-kde-inching-closer/
"Support Plasma 6!": https://kde.org/fundraisers/plasma6member/
--
Joseph P. De Veaugh-Geiss
KDE Internal Communications & KDE Eco Community Manager
OpenPGP: 8FC5 4178 DC44 AD55 08E7 DF57 453E 5746 59A6 C06F
Matrix: @joseph:kde.org
Generally available Monday-Thursday from 10-16h CET/CEST. Outside of
these times it may take a little longer for me to respond.
KDE Eco: Building Energy-Efficient Free Software!
Website: https://eco.kde.org
Mastodon: @be4foss@floss.social