banking and Free Software

Wojtek Kosior koszko at koszko.org
Thu Feb 22 21:13:33 UTC 2024


> 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 at 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
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fsfe.org/pipermail/discussion/attachments/20240222/f84fb74d/attachment.sig>


More information about the Discussion mailing list