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)