Conference PaperPDF Available

Paying the Price for Disruption: How a FinTech Allowed Account Takeover


Abstract and Figures

This paper looks at N26, a pan-European banking startup and the poster child for young FinTech companies. We assess how security is treated by startups that provide disruptive technologies in the financial sector. In an area that has been committed to security, we find that FinTech companies have modern designs and outstanding user experience as their main priority. This strategy is rewarded by a rapidly increasing customer base but reveals a flawed understanding of security. We analyzed all aspects of security of N26, including the frontend, backend, protocols, human factors, and underlying design concepts, and found issues in all of them. We succeeded in leaking customer data, manipulating and carrying transactions and even could have entirely taken over foreign accounts. We reported these findings to N26 and did not disclose them before they were fixed. By publishing this case study, we hope to raise awareness about security considerations in the critical banking sector, especially for other FinTech startups.
Content may be subject to copyright.
Paying the Price for Disruption
How a FinTech Allowed Account Takeover
Vincent Haupert
Friedrich-Alexander University
Dominik Maier
TU Berlin
Tilo Müller
Friedrich-Alexander University
This paper looks at N26, a pan-European banking startup and the
poster child for young FinTech companies. We assess how security
is treated by startups that provide disruptive technologies in the
nancial sector. In an area that has been committed to security, we
nd that FinTech companies have modern designs and outstanding
user experience as their main priority. This strategy is rewarded by a
rapidly increasing customer base but reveals a awed understanding
of security. We analyzed all aspects of security of N26, including the
frontend, backend, protocols, human factors, and underlying design
concepts, and found issues in all of them. We succeeded in leaking
customer data, manipulating and carrying transactions and even
could have entirely taken over foreign accounts. We reported these
ndings to N26 and did not disclose them before they were xed.
By publishing this case study, we hope to raise awareness about
security considerations in the critical banking sector, especially for
other FinTech startups.
Security and privacy Multi-factor authentication
application security
;Software reverse engineering;
Social and
professional topics Phishing;
FinTech, Mobile Banking, Security Breach, 2FA, PSD2
ACM Reference Format:
Vincent Haupert, Dominik Maier, and Tilo Müller. 2017. Paying the Price
for Disruption: How a FinTech Allowed Account Takeover. In ROOTS: Re-
versing and Oensive-oriented Trends Symposium, November 16–17, 2017, Vi-
enna, Austria. ACM, New York, NY, USA, 10 pages. https://doi
Young FinTech companies strive to be disruptive in the nancial
sector. In other words, they try to invent technologies that displace
existing banking technologies. Since FinTech companies operating
in the consumer market focus on usability and user experience,
Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for prot or commercial advantage and that copies bear this notice and the full citation
on the rst page. Copyrights for components of this work owned by others than the
author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or
republish, to post on servers or to redistribute to lists, requires prior specic permission
and/or a fee. Request permissions from
ROOTS, November 16–17, 2017, Vienna, Austria
2017 Copyright held by the owner/author(s). Publication rights licensed to the
Association for Computing Machinery.
ACM ISBN 978-1-4503-5321-2/17/11. . . $15.00 .3150383
well-established security standards of the banking sector are some-
times neglected. This paper presents a range of security vulnerabil-
ities that were identied in N26, a FinTech company. N26, which
currently has 500 000 registered users in countries across Europe,
oers a smartphone-only bank account. Without access to a user’s
smartphone, we were able to not only reveal N26 customer data
and manipulate transactions in real-time but also completely take
over a victim’s bank account. The bugs, taken together, would have
eventually put the consumers’ money and data at risk. We believe a
security-focused development process would have discovered most
of these bugs early on. This raises the question of whether startups
tend to ignore well-established security concepts in favor of a quick
market launch. Also, the focus on usability aspects over security
plays a key role in the advancing downfall of conceptual security
We demonstrate how little thought N26 put into security by
presenting a variety of practical exploits against it. Those exploits
were found in all parts of the N26 infrastructure and have since
been xed in the course of a responsible disclosure process. By
combining those exploits, we show that even a complete account
takeover was possible. We also provide an overview of the state
of the art in mobile banking and shed light on the current state of
transaction schemes used for banking. With the example of N26,
we argue why basic concepts were awed and how established
banking standards were disregarded. We also discuss the current
legal situation of banking in Europe with regard to transaction
security. By highlighting the attacks described in this paper, we
hope to raise awareness among investors, state actors, and founders
alike in order to emphasize the need to include security analyses
early on in the development process.
In this section, we elaborate on how online transactions and their
security mechanisms evolved over time. Today, many FinTech com-
panies like N26 are best described as app-only banks. Everything,
including opening accounts, sending transactions, applying for
loans and more is done through the central app. Of course, estab-
lished banks have oered traditional online banking through the
browser for much longer. Since N26 operates with a German bank-
ing license, we focus on the history and regulations of German
online banking. Soon, however, supranational regulation will en-
force similar rules throughout the European Union, as is outlined
in the following section.
2.1 Online and Mobile Banking
In the German market, even in 1980 when online banking was
rst made public, every transaction had to be secured by an extra
ROOTS, November 16–17, 2017, Vienna, Austria Vincent Haupert, Dominik Maier, and Tilo Müller
transaction authentication number—the TAN. A TAN is a one-time
password that a customer is required to enter after a transaction
has been initiated. This means that on top of a customer’s account
number and password, single-use TANs are necessary as a second
factor when performing credit transfers. The concept of TANs has
been in place for over 30 years now and its security is steadily
increasing. Technological advances in both attacks and defenses
have led to more advanced TAN methods. The development in the
recent past, however, has taken a dierent path, led by startups
like N26. The emphasis is no longer on security but has shifted
toward ensuring a better user experience at all costs, ignoring both
conceptional and technical aws.
Two-Device Authentication
Figure 1: The three classes of two-factor authentication pro-
cedures used in digital banking in 2017.
Today, TAN procedures can be categorized into three classes,
as visualized in Figure 1: two-device authentication (2DA), two-app
authentication (2AA), and single-app authentication (1AA). In a 2DA
scheme, the customer uses one device (e.g. a PC or a smartphone) to
initiate the transaction using their online banking login credentials
and another device to generate or receive the TAN. The pinnacle
of 2DA methods from a security standpoint is the chipTAN method.
This uses the customer’s personal bank card and a dedicated reader
device to create the TAN. Since the reader oers an external display,
is not connected to the Internet, and handles only very limited input,
purely technical attacks are practically infeasible. Mobile phones
have been used to display TANs delivered via SMS, but this method
was proven to be insecure years ago [
]. The possibility to run
software on mobile phones then led to the creation of app-based
TAN procedures. Dierent variations exist that require the device
to be online (receiving TANs via push notications like smsTAN)
or work oine (generating TANs on a device, much like chipTAN).
In contrast to earlier TAN methods, app-based procedures do not
necessarily require the user to transfer the TAN manually to the
transaction-initiating channel; rather, they might conrm the trans-
action directly—without ever displaying a TAN—when both the
banking app and the TAN app are running on the same device.
While using banking services on a smartphone via a separate 2DA
TAN procedure—like chipTan—represents an increase in availabil-
ity without immediate drawbacks in security, the introduction of
two- and single-app authentication schemes constitutes a turning
point in the development of online transaction security for the
worse. These apps openly abandon the strong security guaranteed
by two physically independent devices. Instead of using one device
for transaction initiation and another for conrmation, 2AA uses
a dedicated banking app to issue a transaction and another app
to conrm it. Both apps can operate on the same mobile device.
The 1AA scheme, with the N26 app as an early example, takes
this idea one step further. Here, the theoretical border of a second,
sandboxed, app, is no longer present. Instead, the entire transfer
process is tucked into a single app, leaving almost no trace of the
transaction numbers of the past.
2.2 Legal Aspects
The nancial sector in Europe is regulated. These regulations ex-
tend to bank credit transfers as well. While we already noted that
German online banking has historically been concerned about se-
curity, the European Banking Authority (EBA) stipulated rules that
apply throughout the European Union [
]. The hallmark of these
guidelines is that transactions need to employ strong customer au-
thentication (SCA). It should make use of two mutually exclusive
authentication elements of the categories knowledge,possession,
and inherence. Furthermore, these elements need to be independent
in such a fashion that “the breach of one does not compromise the
other(s)”. As these rules were established by the end of 2014 and
were drafted as early as 2010, it might be surprising that 2AA and
1AA procedures are allowed at all. This is due to a major exemption
of these EBA guidelines. They only aect transactions issued using
a web browser. This means that the same transaction does not need
to follow the rules if it is executed using a custom-made banking
app instead. This is a classic niche that a startup could use to dis-
rupt the market. Traditional banks are also taking advantage of
this aw, even releasing banking apps that merely wrap the banks’
web page in a WebView inside an app. Consequently, these apps
are exempted from the requirement of SCA even though the same
functionality through a web browser would have required SCA.
The Revised Payment Service Directive (PSD2), however, explicitly
accounts for mobile devices and forces them to make use of SCA.
While an early draft [
] still indicated that PSD2 will force payment
service providers to implement the elements of SCA in separate and
trusted execution environments, the nal draft [
] dismissed this
requirement. The EBA even emphasizes that SCA on a single device
will be compatible as long as they make “use of separated secure
execution environments through the software installed inside the
multi-purpose device”. Whether this will prohibit 1AA schemes in
their current form is not publicly known yet.
2.3 Related Work
As stated, the course taken by authentication schemes entirely
operating on a single device poses a security risk. Such schemes
oer a single point of failure: the integrity of the single multi-
purpose device they are running on, most often an Android- or
iOS-driven smartphone. Given the sluggish update policy of many
Android vendors and emerging attacks like Drammer developed
by Fratantonio et al. [
], the integrity of smartphones cannot be
guaranteed. Malware running with high privileges can be placed
even in ocial app stores [
]. Grassini et al. consider smartphones
Paying the Price for Disruption ROOTS, November 16–17, 2017, Vienna, Austria
to belong to the same device group as chipTAN—namely “multi-
factor OTP devices” [
]. However, as they are connected to the
internet and able to run arbitrary third-party code, we deem smart-
phones more vulnerable than chipTAN devices. By analyzing and
attacking two popular app-based TAN procedures—the pushTAN
and the photoTAN methods—we oer proof that these methods are
a clear security downgrade and thus have a signicantly broader
attack surface. The rst case that shows the decline of concep-
tional security is the photoTAN procedure [
]. In contrast to the
pushTAN procedure, the photoTAN method is used to leverage a
dedicated hardware device—comparable to the security properties
of chipTAN—to authorize transactions, thus oering a secure and
trusted display. However, a special implementation of the app-based
photoTAN method is implemented as a 2AA procedure. With two
elements on the same phone, the user no longer takes photos but
these are passed into the photoTAN app directly behind the scenes.
Second, we showed an attack against the pushTAN 2AA procedure
based on a privilege escalation exploit that transparently tampered
with a user-initiated and user-conrmed transaction without the
user being able to notice it [
]. Konoth et al. propose similar at-
tacks and label them as 2FA synchronization vulnerabilities [
as these exploit the heavy synchronization that recent versions of
smartphone operating systems make use of. Bai et al. researched
mobile payments that work oine, revealing major limitations of
existing token-protection techniques. They also point out the ad-
ditional attack surface through the web, much like the shift from
chipTAN to app TANs for online payments [
]. Yang et al. show
that payments on phones are secured even less in a non-banking
context—namely in the case of in-app payments. They uncovered
hundreds of apps with at least 100 000 users which had awed pay-
ment processes that could cause nancial loss as well [
]. Research
on online banking with regard to security was already underway in
the 1990s through the work of Arie et al. [
]. The security of online
banking has increased steadily ever since. Aside from payment, as
discussed in this paper, a security-second approach can be seen in
other areas that nourish innovative and fast-moving companies. In
contrast to the banking scenario, the newer trend of the internet
of things (IoT) has no history of security improvements to build
upon. Historically, security has been rather grim for connected
devices. Large-scale studies of rmware by Costin et al. [
] and
in-depth rmware analyses by Shoshitaishvili et al. [
] uncovered
a range of errors in embedded devices. Still, new products in the
IoT sector face the same problems as the latest FinTech products:
not enough emphasis is placed on security. Fernandes et al. argue
that security in the IoT is facing the same problems as in traditional
computing [
]. Quite similarly to the gist of our paper, Dragoni
et al. use the IoT as an example to state the same facts. They show
that here too a shift in culture is needed. According to their paper,
“The Internet of Hackable Things”, only 48% of organizations focus
on security from the beginning of the development phase. Further-
more, Dragoni et al. provide data indicating that startups take a far
laxer approach toward security in the IoT eld. Their study shows
that the percentage of startup executives who feel their products
are highly resilient to cyber-attacks is 16% lower than in traditional
rms [
]. Further blurring the line between the IoT and our app
scenario, the security assessment of smart home applications by
Fernandes et al. [
] considers the devices as well as their apps,
showing errors on the app side. Thus, they unveil a lack of security
understanding in the producing rms.
2.4 N26
N26 is a Berlin-based startup bank that focuses on bringing all -
nancial services to the customer’s smartphone. We chose N26 as our
case study because it is the poster child for startups in the nancial
sector. N26 acquired over 500 000 customers since its launch in 2015
and is one of the few European FinTech companies operating on
a full European banking license [
]. The success of N26 is based
on its having all services and oerings entirely within a single app
that provides outstanding usability. On top of common Single Euro
Payments Area (SEPA) credit transfers, N26 also enables customers
to perform direct payments to other N26 users, request an overdraft,
or take out an insurance policy—all from within the app. While
it is undoubtedly worthwhile to create intuitive and easy-to-use
solutions, it is particularly important for a bank to repose business
condence by keeping their customers’ money and data safe. In the
past, established banks took a conservative approach by valuing
security features very high. This strategy led to a steady increase
in transaction security, but it came at the cost of user experience.
Today, even established banks provide app-based authentication
schemes operating on only a single device. This shift toward user-
focused technologies can partly be accredited to disrupting new
players like N26 which are changing the market. As a matter of
fact, N26 was the rst German bank that implemented the entire
transaction process in one app [
], with others slowly following
suit, despite the obvious security drawbacks. Implementing both,
transaction initiation and conrmation, in a single app eectively
eliminates two-factor authentication. In turn, strong vetting of the
remaining infrastructure should be put in place. Following best
practices with respect to technical security becomes increasingly
important. The following sections, however, provide evidence that
neither N26’s Android and iOS apps nor their backend or underly-
ing concepts could be described as secure. Seemingly, security has
at no point been a focus of the young but well-funded company
that handles the personal data and money of half a million people.
This section describes practical exploits against the infrastructure
of the evaluated startup, N26. We reveal a variety of dire security
aws, most of which could have been prevented by following best
practices in the development process. All aected user accounts
were part of the research group. The bugs have since been xed in
a professional manner as part of a responsible disclosure process.
Still, for the sake of readability, we chose the present over the past
3.1 Security Model
Before the presentation of the distinct security aws, this section
gives an overview of N26’s security model and the most important
security anchors. In comparison to other online and mobile banking
systems, the N26 account’s authentication scheme consists of more
than two elements. All of them, however, relate to either knowledge
or possession. The authentication factors inside the app that are
based on knowledge are as follows:
ROOTS, November 16–17, 2017, Vienna, Austria Vincent Haupert, Dominik Maier, and Tilo Müller
Login Credentials.
To log in, a user’s email address and pass-
word are required. Both are given in a standard fashion during
the registration process, at which time the user also automatically
opens a bank account at N26. The password needs to satisfy the
following policy: It should be at least seven digits long, consisting
of a minimum of one digit, one special character, and one capital
letter [
]. In our tests, however, it was not necessary to specify a
special character. Providing a password of this length with only a
capital letter and a digit was sucient.
Transfer PIN.
The transfer PIN is a four-digit numerical token
that the user denes during the account activation process. The
transfer PIN is mainly used to authorize transactions and cash
withdrawals. The customer can change the transfer PIN at any time;
this does not require entering the old pin but only the MasterCard
ID, a token that is distinct to the N26 account and described below.
For ATM withdrawals, the card is blocked after entering the wrong
PIN three times.
Apart from these knowledge-based factors, the following el-
ements aim at authentication through something only the user
MasterCard ID.
This 10-digit numerical token is printed below
the name on the customer’s MasterCard (cf. Figure 2 for an example).
This is not the credit card PAN. The MasterCard ID is properly the
most important static authentication element of the N26 security
scheme. A user needs it for the initial phone pairing, to change the
transfer PIN, and during the unpairing process that is covered in
greater detail in Section 3.3.4.
Paired Device.
Through personalization, the customer’s smart-
phone serves as a possession element relying on asymmetric cryp-
tography. To dene a paired device for the rst time, the customer
needs to supply the MasterCard ID and a one-time password de-
livered via SMS. After successful conrmation, the app sends the
public key of a 2048-bit RSA key to the N26 backend, thus making
this smartphone the paired device. Subsequently, this key is used in
a challenge–response authentication system. There are some busi-
ness cases that require the paired device—most notably transaction
SIM Card.
During the pairing process, a user also needs to supply
a phone number that they want to pair the N26 app with. The
client’s phone number, however, does not serve as an authentication
element. It is only required for unpairing.
Figure 2: The N26 MasterCard. The 10-digit number beneath
the cardholder name is the MasterCard ID.
Besides the knowledge- and possession-based authentication ele-
ments, the N26 account also has other security features. Those have
in common that they are not used for authentication but answer
the purpose of user-specied bank account restrictions and allow
the customer to quickly respond to abnormal incidents:
Immutable Data.
While most of the data—including many secu-
rity elements—can be changed by the users themselves only by
knowing the account’s login credentials, some data is immutable
and can only be changed via the N26 customer service. This most
notably includes the customer’s email address that is used to recover
a forgotten password. Further immutable data is the customer’s
name; the shipping address, however, can be changed at any time
(even on an unpaired device).
Card Usage.
A user can decide how one is allowed to use the N26
MasterCard. This includes switches that decide if online payments,
ATM cash withdrawals, or payments abroad are permitted.
Card Limits.
Like the card usage settings, a user can dene a
custom daily limit for cash withdrawals and payments. The range
for cash withdrawals lies between
2 500, while for pay-
ments the minimum and maximum values are
10 000. Both
withdrawals and payments have a xed monthly limit of 20 000.
Lock Card.
The N26 MasterCard can be locked, preventing its
usage completely. The user might also unlock the card again—at
any time—in the same fashion.
Push Notications.
On various occasions, the customer’s smart-
phone receives real-time notications. This includes successful and
failed payments, incoming and outgoing transfers, and direct debit
transfers. These notications might help a customer to react quicker
in the case of fraudulent transactions.
3.2 Frontend Flaws
This section is dedicated to the security aws that we identied in
the N26 frontends. The main means of interaction of N26 customers
with their account is through the N26 app, which is available for
Android and iOS. On top of this, N26 also oers a web app. The
online version is limited as it does not allow the conrmation of
transactions. It quickly became clear that all three clients talk to the
same API endpoints. The Android app did not use any defensive
mechanisms and was therefore a good choice as the main target.
It allowed us to comfortably reverse-engineer the communication
protocols and to examine the functionality up close. This yielded
a device-independent vulnerability that one might abuse to carry
out a transaction manipulation attack. On top of this, we found
an Android-specic aw that allows an attacker to inject arbitrary
web content into the N26 app itself.
3.2.1 Transaction Manipulation. The goal of this attack is the
transparent real-time manipulation of a user-initiated transaction.
In this scenario, the victim, Bob, is in the act of sending a transaction
10 to the beneciary Alice. He lls in Alice’s international
bank account number (IBAN) and an amount of
10, and submits
the transaction. Thereafter, Bob is prompted to conrm his transfer
as the app displays the transaction details again. As the details seem
sound, Bob conrms the transaction. The next day, however, Bob
uses the browser-based online banking service of N26 on his com-
puter and realizes that he did not transfer
10 to Alice; it turns out
that he transferred
200 to an unknown IBAN. This attack becomes
Paying the Price for Disruption ROOTS, November 16–17, 2017, Vienna, Austria
possible because N26 did not sign the transaction data despite al-
ready making use of their private and public key infrastructure
during the transaction conrmation on the paired device. They
also did not make use of certicate pinning. Technically, a credit
transfer works in the following way:
The customer enters the transaction details—that is, the ben-
eciary’s IBAN and the desired amount—in the N26 app and
presses the send button.
Next, the user needs to supply the four-digit numerical transfer
PIN, which is sent along with the transaction order.
If the provided PIN is correct, the transaction initiation is com-
pleted and the N26 backend sends a push notication to the
customer’s paired device. The payload of the push message
contains a TAN encrypted with the public key of the paired
After opening the push notication, the app displays the trans-
action details again and asks for the user’s conrmation. If the
user authorizes the transaction, the encrypted TAN is decrypted
using the private key and sent back.
(5) If the TAN is correct, the transaction comes into eect.
If an attacker can launch a man-in-the-middle (MitM) attack, the
transaction can be tampered with transparently. This becomes pos-
sible because of two reasons. First, even though the N26 apps make
strict use of HTTPS, they do not make use of certicate pinning—a
best practice that prevents unauthorized third parties from breaking
the condentiality and integrity of the transmitted data. Second,
the push notication only contains the encrypted TAN but not
the transaction details. Therefore, the app is forced to rely on and
display the data that the user entered in the rst step instead of
presenting transaction details received through a second commu-
nication channel encrypted with the paired device’s public key. In
summary, an adversary can circumvent the three-step authentica-
tion procedure only by compromising the network layer. This can
be achieved by successfully executing one of the following attack
A user can be tricked into installing the certicate through phish-
ing or other means of social engineering. The user is the weakest
point in the system. So, the app should pin its certicates. In gen-
eral, attacks using phishing or social engineering are particularly
dangerous and have a high success rate [6].
A trusted certicate authority (CA) issues the certicate. Vulner-
abilities in CA validation processes sometimes allow an attacker
to take hold of a certicate for domains they do not own.
Both Android and iOS are frequently the prey of privileged
malware—that is, malware that performs a privilege escalation
exploit before executing their payload. It is a trivial task for
privileged malware to place a certicate.
3.2.2 Popup WebView Injection. While reversing the Android
app, we stumbled upon many deep links registered in the app
manifest. Opening many doors is never a good idea and deep links
are mostly considered to have a negative security impact [
]. In this
case, we found one link—
which allows a popup injection. The web link enables an attacker to
launch the N26 app and make it display a popup window containing
a WebView rendering any user-provided content. The WebView
Figure 3: WebView Injection. An external deep link starts
the app and allows it to display any web page inside it.
is code-enabled and the N26 app injects a Java callback object
that allows sharing to Facebook, navigation inside the app, and
more. The possibility to run JavaScript increases the attack surface,
depending on the app and Android versions. Even worse, the popup
poses a severe threat through advanced phishing attacks. Since the
user logs into the app as usual before the popup is displayed, the app
name is still N26 in the system and there is no way to distinguish
this popup from a genuine app interaction. In contrast to known
phishing attacks on Android that usually need malicious apps with
appropriate permissions to be installed [
], this attackvector does
not depend on any permissions. Instead, making matters worse,
deep links starting the attack can even be triggered by a hostile web
page while browsing. The size and look of the popup is completely
dependent on the target URL. Figure 3 displays an example popup
that shows the app in the background. The link URL indicates that
the reason for the existence of the aw must have been to allow a
general way to display tutorials. This is a rather unfortunate choice
that might have been noticed earlier had there been a larger focus
on security during development.
3.3 Backend Flaws
In contrast to the previous section on the security issues of the
N26 apps, this section deals with security aws related to the N26
backend. As all N26 frontends make use of the same API calls—
that is, there are no app-specic requests—these vulnerabilities are
independent from the device that a customer uses. Apart from the
internals already acquired from reverse-engineering the N26 apps,
we learned the most about their communication protocol through
HTTPS interception. While presenting the frontend aws in the
last section, we noted that the apps do not make use of certicate
pinning. Hence, we were not even required to alter the app in order
to intercept the communication using a MitM proxy. Through this
analysis, we identied a broad variety of partly severe security
ROOTS, November 16–17, 2017, Vienna, Austria Vincent Haupert, Dominik Maier, and Tilo Müller
3.3.1 Information Leakage. N26 also oers peer-to-peer pay-
ments called MoneyBeams. They are sent immediately and,—in
contrast to SEPA credit transfers—, come into eect without delay.
This feature, however, is only available if the beneciary is also
an N26 customer. Therefore, when a customer wants to send a
MoneyBeam to a friend, the N26 app scans the user’s address book
for contacts that use N26 as well. Even though it is comprehensible
that N26 wants to present other N26 users directly in the app, the
technical implementation does not preserve privacy as the N26
app uploads all email addresses and phone numbers found in the
customer’s address book in plain text to the N26 backend. This is
also illustrated in Figure 4. There is no hashing and even a zero-
knowledge approach may be applied. Consequently, this feature
can also be abused to identify if a given email or phone number
is associated with an N26 account. In particular, having a set of
email addresses which are known to be used for an N26 account
is useful for launching a targeted attack. As a customer’s address
Figure 4: N26 customer identication.
book potentially contains many entries, it is easy to probe more
than 1,000 candidates in a single request. Technically, N26 sends a
POST request with a JSON array of email and phone number strings,
and the backend looks for those entries which are associated with
an N26 account and returns them in the response body. As this
endpoint does not implement any rate-limiting, one might use it
to scan massive data sets of email addresses and phone numbers
for N26 accounts. Owing to the limited entropy of phone numbers,
even a brute force attack on them would be feasible.
3.3.2 Unrestrained Siri Transactions. Since the release of iOS 10,
third-party apps can use Siri to interact with the user. N26, being
an agile company, adapted this feature early on. Hence, users of
iOS 10 can dictate to Siri a transaction’s beneciary and amount
(with a limit of
25 per transaction and a maximum of
200 per
day). Siri asks the user for conrmation of the details and executes
the transfer. The user is not required to enter the login credentials
but might only perform these transactions on the paired device.
Here, we can see once more the strong focus on usability. Figure 5
seems to conrm this restriction and suggests that N26 uses the
same mechanism for Siri transactions as for regular or peer-to-peer
transactions—that is, it conrms them with a TAN. As it turns out,
however, N26 created a new endpoint for unveried low-amount
transactions that, as the name suggests, do not require a TAN to
become eective. Besides, not allowing Siri transactions from an
unpaired device is solely a client value. An attacker who directly
communicates with the N26 API does not have this restriction and
may therefore perform arbitrary transactions. Enforcing client-side
security clearly ignores best practices. After a successfully executed
Figure 5: A Siri transaction on the paired device on the left
succeeds while the same request is denied on an unpaired
Siri transaction, we could withdraw the sent money from an ATM
immediately. This makes attacks attractive. If an attacker were
able to steal a single MasterCard and its transfer PIN, he could
consequently use it as an exit account.
3.3.3 Permissive Risk Analysis. Taking the vulnerabilities pre-
sented so far into account, one might wonder if exploiting them
in practice is not signicantly more dicult thanks to transaction
risk analysis. This is not far-fetched as even N26 claims intelligent
algorithms that “immediately detect irregularities” would be able
to prevent fraud before it even occurs. We tested these algorithms
by automatically performing over 2,000 Siri transactions in a 30-
minute period. Each of these transactions went through without
an issue. We were surprised that no limits were applied as issuing
this amount of transactions in the given time frame using voice
commands is impossible and therefore denitely irregular. Never-
theless, we were condent that N26 would reach out to us shortly.
However, this happened more than three weeks later when the N26
support reached out to us seeking an explanation for the unusual
amount of transactions and informed us that this activity could
result in account cancellation. Even though this reaction at rst
seems reasonable, N26 did not contact the sender; rather, it reached
out to the receiver of the amount. Apart from the clearly manual
processing of irregular activity, this may indicate that N26 reacted
not because of security concerns but following a violation of their
terms of service, probably assuming a business usage of the account.
Furthermore, our entire analysis of N26 security can in no way be
described as stealth. In summary, we doubt that N26 could have
reacted appropriately to a real-world attack with higher amounts
of money, possibly distributed over multiple accounts.
3.3.4 Unpairing. Even in case an attacker is able to obtain the
login credentials as well as the transfer PIN, performing SEPA credit
transfers with an arbitrary amount is still not possible because of the
unavailable private key of the paired device. The goal of this attack
Paying the Price for Disruption ROOTS, November 16–17, 2017, Vienna, Austria
is to gain the possibility to initiate and conrm attacker transactions.
To achieve this, the attacker will rst unpair the victim’s device and
pair an attacker-controlled device right after. The pairing process
is straightforward and requires the user only to supply a mobile
phone number. N26 sends a four-digit numerical token as a text
message to the given number. After the user enters the token into
the app, the pairing process is completed. The unpairing process,
however, is secured by a multi-step and multi-factor procedure. The
steps one must perform to unpair an already existing pairing are as
Start the unpairing through the app or web interface. An email
with a link (that contains a token as a parameter) to start the
actual unpairing is sent to the user’s email account.
After following the link, the user needs to supply the transfer
(3) The user is prompted to enter the MasterCard ID.
N26 sends a ve-digit token to the number which was used in
the previous pairing.
This conception of the unpairing process would require an attacker
to (1) have access to the victim’s email account, (2) know the transfer
PIN, (3) have the MasterCard available, and (4) be able to receive the
victim’s SMS. Even though it is generally commendable that N26
identied the unpairing as particularly critical, each of these steps
can be circumvented by knowing only the victim’s login credentials:
When the user starts the unpairing process, this technically
leads to an HTTP request which causes the backend to send
out an email. But instead of only sending the link to start the
unpairing with the customer’s email address, N26 also sends
it as a response to the HTTP request. As a result, an attacker
does not need access to a victim’s email account.
During the actual unpairing process, one is rst prompted to
enter the transfer PIN. Given that the PIN can be reset by only
knowing the MasterCard ID,—which is required in the next
step—, this step is redundant and does not oer any additional
security. Hence, an adversary is not required to know the trans-
fer PIN.
The MasterCard ID ordinarily would require an attacker to
possess the victim’s MasterCard. Once again, it is noteworthy
that this ID is in no way derived from the PAN nor is it directly
connected to the PAN. Despite the PAN, which is probably
masked in any response body, the MasterCard ID is part of every
transaction performed with the card because it serves as a prex
in the unique identier (UID) of transactions. Consequently, any
card action, whether—buying something online, withdrawing
cash, or making a payment on a POS terminal—, causes the
MasterCard ID to leak in the transaction history. As noted in
the previous step, the MasterCard ID also allows one to reset
the transfer PIN to an attacker-controlled value.
The last step in the unpairing process would require the at-
tacker to either possess the victim’s SIM card or be able to
intercept messages sent to it. We were also unable to trick the
backend into sending the unpairing token to a phone that is
under the adversary’s control and changing the phone number
is an action that requires calling the customer service. The back-
end endpoint that validates the ve-digit numerical token,—in
contrast to the endpoint used for login—, does not implement
rate-limiting. As we were on average able to probe 160 candi-
dates per second, guessing the right token takes approximately
ve minutes.
Email Account Transfer PIN MasterCard SIM Card
Deeplink leaks Resettable ID leaks Guessable
Figure 6: The authentication elements involved during the
As summarized in Figure 6, an attacker can unpair a victim’s phone
without having access to the email account, without knowing the
transfer PIN, and without possessing either the MasterCard or the
SIM. After a successful attempt at unpairing, an attacker can simply
pair a new phone. Although this attack even in its worst case only
takes approximately 10 minutes and an attacker would likely exe-
cute it at night, the described unpairing attack generates a total of
three emails and one SMS that the victim inevitably receives. There
is one email containing the unpairing link, another two emails
informing the victim about the reset of the transfer PIN and the
successful unpairing, and an SMS with the token this attack per-
forms a brute force attack on. After a successful unpairing attempt,
a victim has no possibility to regain control of the account without
calling the customer service. If this attack is executed outside of
N26’s oce hours, even a victim who notices the attack on time
can do nothing but watch.
3.3.5 Overdra Abuse. N26 also oers a real-time overdraft.
This feature is particularly interesting because N26 immediately
grants an overdraft ranging from
50 to
000 depending on the
client’s credit score. N26 is aware that using credit is a particularly
critical process; hence, an overdraft might only be applied by using
the customer’s paired phone in a similar fashion as legitimizing
transactions. Therefore, as the previous Section 3.3.4 demonstrated,
an attacker can gain control of the paired device by only knowing
the user’s login credentials. Since the money is available imme-
diately after the overdraft application, an attacker can steal even
more money than the victim has available. In the best case,—from
an attacker’s point of view—, this could be as much as an additional
So far, we have described various aws of the N26 frontends and
backend. However, we are yet to discuss how an attacker could
gain access to a victim’s login credentials or how they could use
these aws to launch a feasible attack. After outlining how to ob-
tain the login data, this section describes an attack scenario that
involves constructing a large-scale attack based on a spear-phishing
attack and combining several of the described vulnerabilities. Later,
ROOTS, November 16–17, 2017, Vienna, Austria Vincent Haupert, Dominik Maier, and Tilo Müller
we briey describe an impersonation attack by calling the N26
customer service.
4.1 Obtaining the Login Credentials
A precondition of taking control of the entire N26 account is that
the attacker has either already obtained the login credentials or is
able to sni out an access token, which is a longer-lasting login token
used for ngerprint or pattern login. There are many possibilities
for gaining access to this information, among them:
Gain access to the victim’s email account. This is a weak point
of the N26 password-recovery procedure. In general, N26 has a
solid password policy which requires the user to supply at least
seven characters containing at least one digit, one capital letter,
and one special character. In conjunction with the employed rate-
limiting, this virtually defeats brute force attacks. The password
can be restored only by having access to the user’s email account,
which eectively reduces the password policy to the one the mail
provider enforces. This could be as bad as
. Apart from this,
email accounts themselves are subject to attacks and databases
with email addresses are leaked from time to time [19].
Password reuse. The email address is often a semi-public token.
Owing to the vast numbers of accounts everybody owns and
uses every day, passwords are frequently aected by reuse. So,
it is likely that a customer of N26 is not using their password
exclusively [
]. This is even more likely because N26’s password
policy is slightly below current accepted standards and conse-
quently the customer does not need to invent a new password
(or modify it) to fulll the password restrictions.
A victim falls for a phishing attack. Phishing mails are a serious
threat because it is hard to mitigate them. Plenty of literature
and papers available deal with the alarming success rates of
phishing, which has not declined over time. A recent example
is the phishing attack against Raieisen Bank [
]. We do not
know if phishing is already an issue for N26 but the company
could become a more attractive target as its customer numbers
An attacker can easily hijack a victim’s account if he is able to
obtain an access token. This could happen, for example, due to a
forgotten logout.
Apart from the login credentials, the victim is required to already
have used the MasterCard at least once to have the MasterCard ID
available in the transaction history. The type of usage—for example,
card payment or cash withdrawal—does not matter. Considering
that the N26 MasterCard is not only automatically issued and sent
to the customer but also an important part of the N26 business
model, this is a weak precondition.
4.2 Large-scale Attack
In this section, we want to outline an attack that makes use of sev-
eral of the presented security aws and by combining these could
have been able to take over thousands of accounts. The previous
section already noted that a phishing attack is an eective way to
gain control of a victim’s login credentials. At rst glance, N26 is
an attractive phishing target because the only personalization they
use in their business emails sent to the clients is the customer’s
rst name. Frequently, the emails also contain clickable links. How-
ever, N26’s total number of clients is still relatively low. Hence, a
phishing mail sent out to random email addresses will probably be
highly ineective. An improved form of phishing is spear phishing,
which is basically a more targeted version of phishing: By gaining
additional information about the targets, the attackers send emails
containing more details that the customer might relate to; thus, this
is more eective than a regular phishing attack [
]. Owing to the
information leakage vulnerability described in Section 3.3.1, we can
eectively identify the N26 customers who use a given set of email
addresses or phone numbers. In the past year, a huge database of
over 65 million email addresses and password hashes obtained from
a security breach at Dropbox was made publicly available [
]. We
evaluated the entire data set exploiting the given information leak-
age vulnerability and identied more than 33,000 email addresses
that are used to log into an N26 account. An attacker could have
used this information to launch a highly targeted spear phishing
attack that, for example, prompts the user to change their N26
password because they are aected by the Dropbox leak, as using
the same password for both accounts could pose a security risk.
Furthermore, Section 3.2.2 outlined an attack against the Android
version of the N26 app that could be used to inject arbitrary content
inside the N26 app. Therefore, the attacker email could also have
asked the customer to click on a link to change the N26 password
inside the app. This would further increase the victim’s condence
in the legitimacy of the phishing mail. After an attacker knows
the login credentials, the rest of the attack is straightforward: An
adversary can now already make use of Siri transactions because,
as we uncovered, they do not require the paired device. They are,
however, limited to
200 per day per account. Even though this
could fetch a signicant amount of money, pairing an adversary-
controlled phone by performing our unpairing attack would allow
the attacker to gain access to all of the victim’s money and even
more. As a paired device also allows one to apply for an instant
overdraft, an attacker could transfer money that the customer does
not even own. This seems a particularly useful part of the attack
because it is rumored that many people open an N26 account only
to use it occasionally rather than as their main account because of
its attractive credit card conditions (e.g. no account management
fees, no transaction fees, a limited number of free cash withdrawals).
In this case, a victim might not have a lot of money in the account
but exploiting the overdraft can make up to
000 accessible. Last
but not least, Section 3.3.3 showed that the transaction risk analysis
that N26 performs is too permissive, which supports the idea that
the depicted attack scenario would be highly successful.
4.3 Impersonation Attack
While the previous section showed an attack scenario that scales
very well and combines multiple vulnerabilities to create a complete
attack, it is also possible to perform a more individual-oriented at-
tack after getting to know the victim’s login credentials through
impersonation. Section 3.1 already noted that owing to security con-
siderations some of the data of an N26 account is immutable. Most
importantly, this includes the customer’s email address, which is
required for login, and the phone number, which is required during
unpairing. However, there are legitimate cases where a customer
Paying the Price for Disruption ROOTS, November 16–17, 2017, Vienna, Austria
may need to change the phone number because, for example, they
have lost access to the original number. As N26 seeks to be a pure
mobile bank, they do not have any bank branch that a customer
could visit. Therefore, a client needs to call the N26 customer ser-
vice to enter the new phone number. Naturally, N26 authenticates
a customer prior to any action. However, the answer to each of the
three questions the N26 customer support asks over the phone is
either already available from the vulnerabilities described so far or
can be extracted:
After obtaining a customer’s name, the customer service execu-
tive asks for the MasterCard ID. The unpairing attack already
revealed that this token can be leaked as it is used as a prex of
the UID of transactions performed with the MasterCard.
Next, they ask for the place of birth. Even though this is neither
visible through the app nor processed, the place of birth leaks
out in the queries the app performs.
The last authentication question relates to the current account
balance. It is sucient to just have an idea of the account bal-
ance. As the exact values are always available with the login
credentials, this does not pose a problem anyway.
After answering these questions correctly, an attacker has full
control of the account and might request to change arbitrary data.
This includes the phone number, which would allow an adversary
to pair their own phone and gain control over all of the victim’s
money including the overdraft accessible. Even though this attack
does not scale well since it requires human interaction, it has the
advantage of absolute stealth because the N26 customer service
does not notify the victim by email or SMS that crucial account
data has been changed.
We chose a responsible disclosure process to give N26 enough time
to address all the issues, so as not to put any customer at risk. As we
were unsure about how N26 might react from a legal perspective,
we asked the Chaos Computer Club to establish the contact. The
contact with N26, however, was professional and friendly, and the
technical sta was not only thankful for our reporting of the issues
but also interested in improving their development process. After
we granted a three-month period to address all the issues, we rst
presented our results at the 33rd Chaos Communication Congress
to the public [
]. To the best of our knowledge, N26 addressed
all our reported ndings prior to this talk.
We showed various exploits against N26, a well-funded, fast-growing
startup in the vital banking sector. Taken together, these exploits
could help attackers to steal the customers’ money, thereby poten-
tially pushing the company out of business. At the root of those
exploits, we identify a strong focus on user experience combined
with the high expectations of investors in the FinTech startup scene.
This leads to the pressure of a quick market launch. Admittedly,
if no analyst looks deeper into it, there is no immediate return on
investment for security owing to its non-functional nature. But it
is necessary to keep in mind the damage to customers, the loss
of reputation for the company, and more generally the decline of
condence the public has in the bank’s responsible use of their
money. Once a security aw becomes public, however, it justies
embracing security from the beginning even from an economic
point of view. To summarize, we showed attacks against dierent
points in the infrastructure of N26, including the frontend, backend,
protocols, and underlying design concepts. After our revelations,
N26 is indeed placing greater focus on security, but they could
have avoided most of the problems from the beginning. We hope
to raise awareness among the founders of and investors in other
FinTech startups about the importance of including security anal-
yses early on in the development process. We also outlined the
ever-increasing evolution of online banking security and its recent
decay. In general, we argue that multiple apps running on the same
system, separated only by the integrity of the operating system,
cannot be considered as secondary factors. This is also true for
banks other than N26, including well-established banks that have
shifted to the same technology in the recent past. Moreover, we
see an obligation among governmental institutions in this regard.
Particularly the vetting process in place for banking requires an
understanding that is tailored to the digital era. In our opinion,
in-depth security analysis and penetration tests that not only are
based on reading a company’s documentation but also perform
practical attacks must be included in the development process.
We wish to thank Felix Binder for the insightful discussions on
the N26 security conception and implementation as well as the
anonymous reviewers for their helpful comments.
Xiaolong Bai, Zhe Zhou, XiaoFeng Wang, Zhou Li, Xianghang Mi, Nan Zhang,
Tongxin Li, Shi-Min Hu, and Kehuan Zhang. 2017. Picking Up My Tab: Under-
standing and Mitigating Synchronized Token Lifting and Spending in Mobile
Payment. In 26th USENIX Security Symposium (USENIX Security 17). USENIX
Association, Vancouver, BC, 593–608. https://www
Zinaida Benenson, Freya Gassmann, and Robert Landwirth. 2017. Unpacking
Spear Phishing Susceptibility. In Targeted Attacks (Financial Cryptography and
Data Security Workshops) (FC ’17). Springer, 1–17.
Chaos Computer Club. 2016. Shut Up and Take My Money! (30 12 2016). Retrieved
October 01, 2017 from https://fahrplan
Qi Alfred Chen, Zhiyun Qian, and Z. Morley Mao. 2014. Peeking into Your App
without Actually Seeing It: UI State Inference and Novel Android Attacks. In
23rd USENIX Security Symposium (USENIX Security 14). USENIX Association, San
Diego, CA, 1037–1052. https://www
Andrei Costin, Jonas Zaddach, Aurélien Francillon, and Davide Balzarotti. 2014. A
Large-Scale Analysis of the Security of Embedded Firmwares. In 23rd USENIX Se-
curity Symposium (USENIX Security 14). USENIX Association, San Diego, CA, 95–
110. https://www
Rachna Dhamija, J. D. Tygar, and Marti Hearst. 2006. Why Phishing Works.
In Proceedings of the SIGCHI Conference on Human Factors in Computing Sys-
tems (CHI ’06). ACM, New York, NY, USA, 581–590. https://doi
Nicola Dragoni, Alberto Giaretta, and Manuel Mazzara. 2017. The Internet of
Hackable Things. (08 2017).
European Banking Authority. 2014. Final guidelines on the security
of internet payments. Technical Report. Canary Wharf, London, UK.
European Banking Authority. 2016. EBA consults on strong customer authentication
and secure communications under PSD2. Technical Report. Canary Wharf, London,
European Banking Authority. 2017. EBA paves the way for open and secure elec-
tronic payments for consumers under the PSD2. Technical Report. Canary Wharf,
ROOTS, November 16–17, 2017, Vienna, Austria Vincent Haupert, Dominik Maier, and Tilo Müller
London, UK. https://www.eba.europa .eu/-/eba- paves-the-way- for-open- and-
secure-electronic- payments-for- consumers-under-the- psd2
E. Fernandes, J. Jung, and A. Prakash. 2016. Security Analysis of Emerging
Smart Home Applications. In 2016 IEEE Symposium on Security and Privacy (SP).
636–654. .2016.44
Earlence Fernandes, Amir Rahmati, Kevin Eykholt, and Atul Prakash. 2017. In-
ternet of Things Security Research: A Rehash of Old Ideas or New Intellec-
tual Challenges? IEEE Security & Privacy 15, 4 (2017), 79–84. https://doi
Samuel Gibbs. 2016. Dropbox hack leads to leaking of 68m user pass-
words on the internet. (31 08 2016). Retrieved August 24, 2017
from https://www
passwords-68m- data-breach
N26 GmbH. 2017. N26 increases number of customers to over 500.00. (21
08 2017). https://n26
com/content/uploads/2017/08/mobile-bank- with-strong-
organic-growth.pdf Press release.
Paul A Grassi, Michael E Garcia, and James L Fenton. 2017. Digital Identity
Guidelines. NIST Special Publication 800 (2017), 63–3.
Vincent Haupert. 2017. N26. (01 02 2017). Retrieved October 01, 2017 from
Vincent Haupert and Tilo Müller. 2016. Auf dem Weg verTAN:Üb er die Sicherheit
App-basierter TAN-Verfahren. In Sicherheit 2016 (Sicherheit, Schutz und Zuver-
lässigkeit Bonn 05.4. - 07.4.2016) (SICHERHEIT 2016), Michael Meier, Delphine
Reinhardt, and Steen Wendzel (Eds.). Gesellschaft für Informatik e.V. (GI), Bonn,
Vincent Haupert and Tilo Müller. 2016. On App-based Matrix Code Authentication
in Online Banking. Technical Report. Freidrich-Alexander-Universität Erlangen-
Troy Hunt. 2017. Pwned websites. (2017). Retrieved August 26, 2017 from
Maik Klotz. 2017. Online-Banking: Digitaler Stillstand since 1980. (10 08 2017). Re-
trieved August 21, 2017 from https://paymentandbanking
digitaler-stillstand- since-1980/
Radhesh Krishnan Konoth, Victor van der Veen, and Herbert Bos. 2017. How
Anywhere Computing Just Killed Your Phone-Based Two-Factor Authentication.
Springer Berlin Heidelberg, Berlin, Heidelberg, 405–421. https://doi
978-3- 662-54970- 424
Fang Liu, Chun Wang, Andres Pico, Danfeng Yao, and Gang Wang. 2017. Mea-
suring the Insecurity of Mobile Deep Links of Android. In 26th USENIX Security
Symposium (USENIX Security 17). USENIX Association, Vancouver, BC, 953–
969. https://www
D. Maier, T. Müller, and M. Protsenko. 2014. Divide-and-Conquer: Why Android
Malware Cannot Be Stopped. In 2014 Ninth International Conference on Availabil-
ity, Reliability and Security. 30–39. .1109/ARES.2014.12
Collin Mulliner, Ravishankar Borgaonkar, Patrick Stewin, and Jean-Pierre Seifert.
2013. SMS-based one-time passwords: attacks and defense. In International
Conference on Detection of Intrusions and Malware, and Vulnerability Assessment.
Springer, Berlin, Heidelberg, 150–159.
N26 GmbH. 2017. Password For Your N26 Account. (2017). https://
Arie Segev, Jaana Porra, and Malu Roldan. 1998. Internet Security and the
Case of Bank of America. Commun. ACM 41, 10 (Oct. 1998), 81–87. https:
// .286251
Yan Shoshitaishvili, Ruoyu Wang, Christophe Hauser, Christopher Kruegel, and
Giovanni Vigna. 2015. Firmalice-Automatic Detection of Authentication Bypass
Vulnerabilities in Binary Firmware.. In NDSS.
Lukas Stefanko. 2017. Phishing attack at Raieisen Bank by MazarBot. (08 2017).
Retrieved August 26, 2017 from https://b0n1
attack-at- raieisen-bank- by.html
Victor van der Veen,Yanick Fratantonio, Martina Lindorfer, Daniel Gruss, Clemen-
tine Maurice, Giovanni Vigna, Herbert Bos, Kaveh Razavi, and Cristiano Giurida.
2016. Drammer: Deterministic Rowhammer Attacks on Mobile Platforms. In
Proceedings of the ACM Conference on Computer and Communications Security
(CCS). Vienna, Austria.
Ding Wang, Zijian Zhang, Ping Wang, Je Yan, and Xinyi Huang. 2016. Targeted
Online Password Guessing: An Underestimated Threat. In Proceedings of the 2016
ACM SIGSAC Conference on Computer and Communications Security (CCS ’16).
ACM, New York, NY, USA, 1242–1254. https://doi
Wenbo Yang, Yuanyuan Zhang, Juanru Li, Hui Liu, Qing Wang, Yueheng Zhang,
and Dawu Gu. 2017. Show Me the Money! Finding Flawed Implementations
of Third-party In-app Payment in Android Apps. 24th Annual Network and
Distributed System Security Symposium, NDSS (2017).
... So far, FinTechs often tend to deprioritize IS and the compliance of certain regulations, or their prioritization lacks sophisticated approaches (Gai et al., 2017;Haupert et al., 2017). The resulting risks can lead to regulatory issues, including financial penalties, or have significant adverse effects on revenues due to declining customers' trust (Mahalle et al., 2018). ...
Conference Paper
Full-text available
The number of FinTechs has been proliferating over the last decades. While their innovative offerings inherit disruptive potential, the security of their cloud services remains a fundamental issue. Tight budgets and the need for rapid product development force FinTechs to focus on the most necessary information security measures (ISMs) that ensure regulatory compliance and avoid customer losses due to security incidents. The question arises of how FinTechs should prioritize ISMs. To answer this question, we follow design science research to develop an artifact by which cloud service using and providing FinTechs can obtain a prioritized list of ISMs. Our resulting artifact builds upon extant research on FinTechs and information security (IS), relevant regulatory frameworks, and the shared responsibility model for cloud services. Our research contributes to the conceptualization of integrated ISM prioritization for FinTechs and provides practitioners with a structured prioritization approach based on a standardized logic.
... According to the prior studies, perceived trust has been confirmed as a critical factor that positively influences the adoption of M-payment" (Al-Saedi et al., 2020: 2). This is only compounded by the fact that as m-payment has become more popular there has been a rush to capture market share which in some cases has come at the expense of secure systems (Haupert et al., 2017). ...
Conference Paper
Mobile payment applications are becoming more and more prevalent around the world. Especially during COVID-19, mobile payment applications were seen as a contactless and thus safer alternative to cash. It is expected that such technology-based solutions are especially attractive to Generation Z, a cohort that grew up with technology. And while Gen Z is considered to be a global cohort, the technological divide between developed and developing nations has meant that members of this cohort in countries like Thailand did not have the same exposure and thus do not have the ensuing relationship with technology. This empirical study utilized a survey to quantitatively investigate the extent to which espoused national cultural values impact Thai Gen Z's technology acceptance of mobile payment. The survey was distributed to cohort members at a university in Bangkok, Thailand. It was found that this generation of Thais are generally willing to adopt mobile payment with the espoused national cultural value of collectivism influencing the extent to which they trust the system as well as the extent to which they seek and perceive that others important to them want them to use the system.
... Arvidsson (2014) investigated consumer attitudes towards mobile phone payments in a study that included Swedish consumers and founded that the adoption of a new payment system is linked to perceived ease of use, age, income, trust, perceived security risks. Security is considered to be a major issue in mobile payment and studies have shown that attackers could have access to customer's accounts due to server security vulnerabilities (Haupert et al., 2017). ...
Full-text available
Poverty alleviation has become one of the biggest challenges for many countries and access to financial services is considered to be a key driver of development and economic growth. Finding solutions that can break down barriers that poor people are facing to access formal financial services has become a major concern for researchers, governments, financial institutions. Financial services must reinvent themselves and the adoption of new technology is a crucial key to overhaul their operations and to find innovative solutions to manage customer expectations. The escalation in access and penetration level of mobile phones and the Internet can improve financial inclusion by facilitating easy access to financial services, by providing secure transaction platforms, by reducing transaction costs, by providing a competitive business framework. There has been relatively limited research on the impact of Internet and mobile phones use on financial inclusion, therefore our main purpose was to investigate this linkage in a sample of 11 post-communist countries of the European Union from 1996–2017 using panel cointegration and causality analyses. Firstly, we investigated whether mobile cellular phone subscriptions and the rate of Internet usage affect financial institutions’ access; secondly, we analysed the impact of these variables on financial market access. Results indicate that mobile cellular phone subscriptions positively affect both financial institution access in countries like Hungary, Latvia, Lithuania, Poland, and Slovenia and financial market access in Bulgaria, Croatia, and Hungary. Also, a negative relationship between mobile cellular phone subscriptions and financial institution access was noticed in the Czech Republic and regarding financial market access in the Czech Republic and Poland. Our findings also indicate both positive and negative relationships between Internet usage rates and financial institutions and financial markets access. By increasing Internet usage we can improve access to financial institutions in Bulgaria, Croatia, Czech Republic, Hungary, and Poland and we can increase financial markets access in Latvia and Slovenia. First published online 13 April 2021
... Technological advancement, digitalization, and globalization benefit countries, companies, and potential stakeholders and invigorate a growing community of hackers to take advantage of the same advancement in the tech world at a rapid pace. Financial institutions take a significant shift (e.g., fintech sandbox) from the last decades due to this technological innovation (Haupert et al., 2017). In some cases, innovation runs ahead of security development (Arakji and Lang, 2007). ...
Full-text available
In the new and evolving digitalized world, the cybersecurity threats have placed the assets and information of corporations, institutions, governments, and individuals at constant risk. Banks are not an exception. Offering the low-interest rate is becoming the fundamental strategic move of the banks to sustain. Due to the high demand for a tailored portfolio of financial products, the availability of sophisticated communication and advance transaction mechanisms lead to an emergence of a new type of competitor known as financial technology service (i.e., fintech). The collaboration between these fintech organizations and banks has recently increased to provide fine-tuned service to the consumer and satisfy emerging market needs. However, this collaboration between banks and fintech firms has triggered significant cybersecurity risk. Hence, the dilemma is whether the bank should embrace such collaboration to resuscitate the profit margin or be pragmatic, and shirk to eliminate sustainability risk? We argue that the alliance between bank and fintech firms triggers a high-level of cybersecurity risk. We propose a theoretical model and discuss various types of cybersecurity risks. The benefit (or cost-if any) of having alliance could be enormous in yielding profitability and increase sustainability if both fintech and banks collaboratively abate the cybersecurity risks.
... • Data security - Haupert et al. (2017) assessed how security is treated by start-ups that provide disruptive technologies in the financial sector. They found that FinTech companies have a new business model and outstanding user experience as their main priority. ...
... Android nowadays has adopted a mixed approach at app security, betting on safeguards on the runtime environment, e.g., the Trusted Execution Environments (TEE) on mobile phones, encryption and signature standards on both the mobile phone and the app itself, and lastly, also obfuscation mechanisms targeted at protecting the apps source code, e.g., ProGuard [87] which is even part of Androids build process. Research soon revealed Dalvik-only solutions severely as protection mechanisms proved to be ineffective and sometimes even reversible in an automated fashion [69,92]. ...
Full-text available
In this thesis, we investigate different possibilities to protect the Android ecosystem better. We focus on protection mechanisms for application developers, and present modern attacks against sandbox-protected applications and the developer’s intellectual property, ultimately providing enhanced approaches for defense against these attacks. Our defensive approaches range from runtime-shielding measures to analysis-impeding obfuscation mechanisms. First, we take a closer look at communication possibilities of sandboxed applications on Android, namely the UI layer and Android’s inter-process communication. We introduce attacks on applications working through the actors on Android’s UI, starting with overlay windows, accessibility services, input editors, and screen captures. Android’s inter-process communication is the second attack avenue we pursue. It is the primary means of communication for apps to interact with each other despite being sandboxed by the Android system. We show through assessments of the Google Play Store and third-party app stores that attacks on these mechanisms pose a blind-spot in current attack models considered by developers. To provide relief we introduce new protection mechanisms that developers can implement and enhance testing methodologies to consider these attacks in the future. Second, we direct the reader’s attention towards attacks on the developer’s intellectual property. Due to Android’s open-source nature and openly communicated standards, a trend of repackaging popular applications with malicious enhancements and republishing the malicious app has rooted itself in the malware community. To counteract this development, we present an enhanced centroid-based approach at clone detection and improved analysis-impeding obfuscation mechanisms that build on virtualization-based obfuscation. Our obfuscation approach works on Android’s current runtime environment, as well as the previously employed ‘Dalvik virtual machine’, and can be used to obfuscate critical portions of an application’s functionality against prying eyes. To make valid assumptions about the strength of virtualization-based obfuscation, we conduct a de-obfuscation study on the more mature x86/x64 platform, developing a reverse engineering approach for virtualization-obfuscated binaries. We analyzed several hundred thousand Android applications during our research with automated approaches and several thousand apps with manual analysis, always opting for a responsible disclosure process of found vulnerabilities by providing developers with at least three months’ due notice before attempting a publication. The tools presented in this thesis are open-sourced under the MIT license, to help in the inclusion of development projects and their extension or further development. With the insights gained through the research for this thesis, we hope to provide developers with the tools and testing approaches they need to make the Android ecosystem more secure and safe.
The acceleration of cyber-attacks in the past few years certainly has negative influences on the investors and shareholders’ trustworthiness in the firms’ abilities to protect their interests. This is likely to be reflected on the firms’ shares price. Thus, the influence of cybersecurity on firms’ overall performance is a questionable issue. To be able to proceed through the cyber risks, firms face the challenge of enhancing their cybersecurity to avoid and combat against the endless cyber-attacks. Further to that the studies that cast light on the relationship between cybersecurity and firms’ performance from a holistic perspective are lacking.
Riding on the widespread user adoption of mobile payment, a growing number of mobile apps have integrated the service from third-party payment service providers or so-called Cashiers. Despite its prevalence and critical nature, no existing standard can guide the secure deployment of mobile payment. Thus, the protocol designs and implementations from different Cashiers are diverse. Given the complicated multi-party interactions in mobile payment, either the Cashiers or the apps may not fully consider various threat models, which enlarges the attack surface and causes the exploits with severe consequences, ranging from financial loss to privacy violations. In this paper, we perform an in-depth security analysis of real-world third-party payment services for mobile apps. Specifically, we examine the mobile payment systems from five top-tier Cashiers that serve over one billion users globally. Leveraging insecure protocol designs and practical implementation flaws, e.g., vulnerable backend SDKs for mobile apps, we have discovered six types of exploits. These exploits enable the attacker to violate user privacy and shop for free in the victim apps, affecting millions of users. Finally, we propose the fixings to defend against these exploits. We have shared our findings with the affected Cashiers and got their positive responses.
Full-text available
Zusammenfassung Eine etablierte Methode der Sicherheitsforschung zur Feststellung von Schwachstellen in Software ist Reverse Engineering. Verstößt eine solche Analyse von Programmen gegen das Urheberrecht? Mehrere deutsche Forscherteams erhielten nach der Veröffentlichung von gefundenen Schwachstellen Unterlassungserklärungen sowie Anträge auf einstweilige Verfügung von einem Anbieter von Sicherheitssoftware.
Internet banking security is set to take a major step forward: On September 14, 2019, the Regulatory Technical Standards of the Revised Payment Service Directive (PSD2) are going to be effective within the European Union and the European Economic Area. This regulation makes two widely demanded transaction security properties mandatory: two-factor authentication, and the dynamic linking of the authentication code to the transaction’s beneficiary and amount (full transaction authentication). Even though the regulation is undoubtedly a positive development from a security perspective, it does not account for all the technical and human weak points involved in the transaction process. In this paper, we look at a series of attacks targeting online and mobile banking that are possible even in a post-PSD2 era. Despite the regulatory motivation of this work, the presented issues and suggestions to address them are likely to be universal for internet banking in general.
Technical Report
Full-text available
These guidelines provide technical requirements for federal agencies implementing digital identity services and are not intended to constrain the development or use of standards outside of this purpose. The guidelines cover identity proofing and authentication of users (such as employees, contractors, or private individuals) interacting with government IT systems over open networks. They define technical requirements in each of the areas of identity proofing, registration, authenticators, management processes, authentication protocols, federation, and related assertions. This publication supersedes NIST Special Publication 800-63-2.
Conference Paper
Full-text available
Mobile off-line payment enables purchase over the counter even in the absence of reliable network connections. Popular solutions proposed by leading payment service providers (e.g., Google, Amazon, Samsung, Apple) rely on direct communication between the payer's device and the POS system, through Near-Field Communication (NFC), Magnetic Secure Transaction (MST), audio and QR code. Although precautions have been taken to protect the payment transactions through these channels, their security implications are less understood, particularly in the presence of unique threats to this new e-commerce service. In the paper, we report a new type of over-the-counter payment frauds on mobile off-line payment, which exploit the designs of existing schemes that apparently fail to consider the adversary capable of actively affecting the payment process. Our attack, called Synchronized Token Lifting and Spending (STLS), demonstrates that an active attacker can sniff the payment token, halt the ongoing transaction through various means and transmit the token quickly to a colluder to spend it in a different transaction while the token is still valid. Our research shows that such STLS attacks pose a realistic threat to popular off-line payment schemes, particularly those meant to be backwardly compatible, like Samsung Pay and AliPay. To mitigate the newly discovered threats, we propose a new solution called POSAUTH. One fundamental cause of the STLS risk is the nature of the communication channels used by the vulnerable mobile off-line payment schemes, which are easy to sniff and jam, and more importantly, unable to support a secure mutual challenge-response protocols since information can only be transmitted in one-way. POSAUTH addresses this issue by incorporating one unique ID of the current POS terminal into the generation of payment tokens by requiring a quick scan-* The two lead authors are ordered alphabetically. † Corresponding author. ning of QR code printed on the POS terminal. When combined with a short valid period, POSAUTH can ensure that tokens generated for one transaction can only be used in that transaction.
Conference Paper
Full-text available
The Internet of Things makes possible to connect each everyday object to the Internet, making computing pervasive like never before. From a security and privacy perspective, this tsunami of connectivity represents a disaster, which makes each object remotely hackable. We claim that, in order to tackle this issue, we need to address a new challenge in security: education.
Conference Paper
Full-text available
The security of smartphone GUI frameworks remains an important yet under-scrutinized topic. In this paper , we report that on the Android system (and likely other OSes), a weaker form of GUI confidentiality can be breached in the form of UI state (not the pixels) by a background app without requiring any permissions. Our finding leads to a class of attacks which we name UI state inference attack. The underlying problem is that popular GUI frameworks by design can potentially reveal every UI state change through a newly-discovered public side channel — shared memory. In our evaluation, we show that for 6 out of 7 popular Android apps, the UI state inference accuracies are 80–90% for the first candidate UI states, and over 93% for the top 3 candidates. Even though the UI state does not reveal the exact pix-els, we show that it can serve as a powerful building block to enable more serious attacks. To demonstrate this, we design and fully implement several new attacks based on the UI state inference attack, including hijacking the UI state to steal sensitive user input (e.g., login credentials) and obtain sensitive camera images shot by the user (e.g., personal check photos for banking apps). We also discuss non-trivial challenges in eliminating the identified side channel, and suggest more secure alternative system designs.
The Internet of Things makes possible to connect each everyday object to the Internet, making computing pervasive like never before. From a security and privacy perspective, this tsunami of connectivity represents a disaster, which makes each object remotely hackable. We claim that, in order to tackle this issue, we need to address a newchallenge in security: education.
Conference Paper
We report the results of a field experiment where we sent to over 1200 university students an email or a Facebook message with a link to (non-existing) party pictures from a non-existing person, and later asked them about the reasons for their link clicking behavior. We registered a significant difference in clicking rates: 20% of email versus 42.5% of Facebook recipients clicked. The most frequently reported reason for clicking was curiosity (34%), followed by the explanations that the message fit recipient’s expectations (27%). Moreover, 16% thought that they might know the sender. These results show that people’s decisional heuristics are relatively easy to misuse in a targeted attack, making defense especially challenging.
Conference Paper
Exponential growth in smartphone usage combined with recent advances in mobile technology is causing a shift in (mobile) app behavior: application vendors no longer restrict their apps to a single platform, but rather add synchronization options that allow users to conveniently switch from mobile to PC or vice versa in order to access their services. This process of integrating apps among multiple platforms essentially removes the gap between them. Current, state of the art, mobile phone-based two-factor authentication (2FA) mechanisms, however, heavily rely on the existence of such separation. They are used in a variety of segments (such as consumer online banking services or enterprise secure remote access) to protect against malware. For example, with 2FA in place, attackers should no longer be able to use their PC-based malware to instantiate fraudulent banking transactions.
The Internet of Things (IoT) is a new computing paradigm that spans wearable devices, homes, hospitals, cities, transportation, and critical infrastructure. Building security into this new computing paradigm is a major technical challenge today. However, what are the security problems in IoT that we can solve using existing security principles? And, what are the new problems and challenges in this space that require new security mechanisms? This article summarizes the intellectual similarities and differences between classic information technology security research and IoT security research.