Hello, my name is Arkady Litvinenko. I'm a lead penetration tester in a Russian company that
has the name Bizon. Also, I'm one of the organizers of the Russian conference of ZON in Moscow,
and one of the organizers of CTF ZON competitions, CTF, and also a co-author of DEFCON CTF.
So, today we will talk about online banking security. And firstly, among projects on my
job, I have a lot of security audits of different online banking applications. And during these
projects, I met and we met a lot of different vulnerabilities and other interesting things.
So, in this presentation, I want to share with you some experience that I got and some interesting
things. And so, this talk will be interesting for offensive and defensive specialists that
work with online banking applications. And also, it will be interesting for developers who
work with online banking and who is trying to make it safer.
But I tried to make this presentation with a growing difficulty level. So, I hope everyone
can get something new from this presentation and get something interesting from this presentation.
So, let's talk about the structure of this presentation, about what we are going to talk
about. So, firstly, we will talk about differences, about remote banking and online banking, and what
is remote banking and what is online banking. We will talk about web banking, mobile banking,
what differences between them. And after that, we will talk about testing approaches,
and how to test the web, mobile, and the server side of mobile banking, and what differences,
what guides we can use for this, and we usually use on our projects.
And the biggest part of this presentation, it will be vulnerability examples with detailed
information, how it works, how to exploit it, and maybe some bad practices of fixing it,
of avoiding it, and so on. And also, we will talk about best practices of how to avoid this
vulnerability, its vulnerabilities. So, let's begin from the differences. What is remote banking
services? It is when the client doesn't need to go to the office to do some actions in bank. For
transferring money, for checking the balance of the account, and some other things.
So, it can be anything. It can be ATM, it can be call center, it can be SMS banking, and also,
it can be a web and mobile banking. For example, we're going to get cash from the account, so we
come to ATM, and it is one of the examples of remote banking services. But there is another
type of banking services, it is online banking. It is not another, it is part of remote banking
services, but it is a thing that we are going to talk about today. So, online banking, it is
web banking and mobile banking. So, web banking, it is when you open the website of
a bank on the browser and do some actions, and for example, log into your account and do some
actions, maybe transfer money, checking balance, and other, and other. So, in mobile, it is totally
the same, but you have to download the application to your mobile, and after that, again, you log
into the account and do some actions. So, today, we're going to talk about online banking,
about web and mobile banking, yeah. And so, we're going to... and all vulnerabilities will be related
to these types. So, let's talk about how does it work. It is very, very simple image, yeah,
but it is a good image for showing that we're going to talk about. We are not going to talk
about infrastructure, our bank infrastructure, about processing, and other very, very complex
things. It is magic for us today, and it is like a black box for us. And so, we're going to talk
about the server side, about the API, yeah. We're going to talk about the frontend mobile. Frontend,
it is something that loads in the browser of clients. So, it can be Angular, it can be React
application, it can be HTML with IAC request, but it doesn't work like this now, usually. Maybe
there are banks with IAC requests, but I don't know. They didn't meet it. So, mobile, it is
totally the same, but mobile application, it is like a custom-made browser. And frontend and mobile,
work with API, yeah, with server side. And they send requests to API, and they get requests from
API, and they render it, they show UI to the clients, and the clients can work with this UI,
and do some actions, maybe clicking the buttons, and other things, and enter maybe some.
And so, usually, in banks, API, it is a similar API for the frontend, and the same, sorry, same
API for the frontend, and for the mobile. Sometimes, maybe there are differences. Maybe it is
split API, so different API for frontend, and different API for mobile. But usually, usually,
it is the same. And API, it is like something between... it is an application that
helps us to work with bank infrastructure. It has API methods, it has some functionality that
can be used by frontend, and that can be used by mobile. And after that, it sends to bank
infrastructure, and there is some magic in bank infrastructure. The bank infrastructure is very,
very complex. It can be anything. It can be monolith, it can be microservices, yeah. And so,
but today, it will be bank infrastructure, and API, it will be server-side for us.
And I think it is all that I wanted to say about how does it work. Again, it is very,
very simple. And we can't talk more detail, because it needs a lot of time. It is a huge topic.
So, testing approaches of server-side and bank infrastructure. Usually, it is... API, it is usual
web application, yeah. And bank infrastructure, it is a very complex thing. It is like
Zoho with different services. It can be anything. And so, it is
very hard to hack it without understanding how does it work. And so, you can only can try to
maybe use fuzzing and other things, and try to understand how does it work. And it is only one
way to understand how to hack the bank infrastructure. So, API, it is usual web
application, so it can have any web vulnerabilities. So, if I'm talking about the possible
vulnerabilities, like I said, it is usual web vulnerabilities. Yeah, it is everything from the
OWASP. Yeah, you just can take the checklist of OWASP and any vulnerability and the most related
to the server-side. So, also, it is misconfigurations. It can be anything like
Nginx misconfigurations, maybe other things. And also, it is logical vulnerabilities,
because the bank and the mobile banking, online banking, it is very, very complex thing. Yeah,
it has very, very complex architecture. And so, when architecture is complex,
developers can do a lot of mistakes in this. And so, it can be any logical vulnerabilities,
like, I don't know, leakage of sensitive data of clients. Maybe, if it's correct to say race
condition, but it is not logical vulnerability, but sometimes it can be based on logical
problems. And other vulnerabilities, it is only example. So, it can be anything.
Next one, it is front-end. So, it is user interface. Yeah, based on the data received from
API. And so, and because it loads in browser, yeah, browser take a lot of security job on itself.
And so, it is very big difference between the mobile application, yeah, and front-end,
because browser do a lot of security job by itself. But in mobile applications,
developers have to do the things by itself. And possible vulnerabilities, it is XSS, it is,
I don't know, DOM-based XSS, it is CSRF, yeah. Maybe forgotten or maybe unfinished pages, yeah.
Sometimes, for example, developers make and publish in production React application,
but this application has pages that doesn't work and they are invisible for clients.
But anyway, they exist in production. And so, after understanding and maybe reversing of
React application, yeah, you can find this and you can recover the API methods that
application sends to API and gets and it allow you to try more requests and
maybe find another vulnerabilities. And also, it can be unsafe communication with API server.
And it is everything about the society, it is everything about communication,
maybe other algorithms and so on, so on. And again, it is only examples,
maybe there are another ones. There are another ones, of course, there are.
So, if we're talking about mobile testing approaches, yeah. Like I said, mobile,
it is an application, it is like custom-made browser. And in this case, you have a lot of,
I don't know, security and customization features, yeah. And so, you have a lot of
possibilities to do something wrong. And in this case, possible vulnerabilities, it is
storing of sensitive data, yeah. And we will talk about this in one example a little bit later.
So, also, it is unsafe handling of external data. And
because there is one good example of vulnerability, when mobile application got
external data and save it to SQLite database. So, and there was a SQL injection in this.
And if you can sniff and if you can edit the traffic that application gets from the network,
yeah, you can do the SQL injection on the client side. It is very interesting thing.
So, also, it is unsafe work with mobile platform. It is, for example, IPC mechanism and
other things, maybe. And also, there are a lot of different things.
And let's talk about testing guides, testing approaches for every type of online banking,
yeah. For web banking, you know, in this slide, I wanted to set, I wanted to make the big
table with comparing of different guides and with choosing the best one. But, no, I just didn't find
any other good guides except Avast per Web and Avast per MSTG. So, maybe, you know, and
if you use something else, you can maybe share it in comments. So, it is really good because...
but for web banking, we also usually use Avast per Web, yeah. It has very good checklist and it
has a lot of different vulnerabilities. So, it is really great and good job of someone who made
this, yeah, of people who made this. And so, mobile banking, it is Avast per MSTG and Avast
Web guides. And Avast per MSTG, it is about everything that's related to mobile platform,
yeah, all vulnerabilities that's related to this one. And why Avast per Web here? Because we have
service side, yeah, and when we're watching the mobile application, we have to check the platform,
the application, and also we have to check the server side and how it communicates with a mobile
application. So, for the platform, for the application, we use Avast per MSTG. And for the
service side, we use Avast Web. And it has maybe some intersections, yeah. And so, in the best way,
this intersection should be fixed, yeah. And the best way is to have that one big checklist
and one big guide. And so, using of this checklist is very, very conveniently and
it is really helps us to don't forget something when we test it. So, after that, we
begin to talk about vulnerabilities. And now it is the biggest part and we will talk about this
until the finish of the presentation. And firstly, I want to say why I choose this vulnerability.
There are three options and there are three
reasons why I choose this. Firstly, it is, for example, some vulnerabilities are very common,
you can meet it in a lot of different applications. And it is very common. And
this is a problem. So, the second one reason, it is because some vulnerabilities are really
interesting. And they are not common. Yeah, maybe it is very rare vulnerability. But anyway,
it is really, really interesting. And it is like really hacking. And for example,
like I said before, it is like making money from nothing. Yeah. And so on. And so, it is really,
really interesting and I love it. And so, the third one reason, it is because sometimes some
vulnerabilities are really hard to fix. Yeah. And developers are trying to fix it and make another
vulnerability. And so, we will talk about... I don't remember one example of this vulnerability.
And so, it... Okay, a little bit later we will talk about it. So, let's begin from the first
one vulnerability. And first vulnerability, it is rounding attack. It is currency rounding attack.
And it is one of my favorite vulnerability, because it is really, really hacking. Like I
said before, and I talk about this vulnerability, it is like making money from nothing. Yeah.
And so, first information that I found about this vulnerability, it was 2011, maybe 2012.
Maybe there are early information, but I didn't find. So, this vulnerability based on the
incorrect or unsafe using of round functions. Yeah. And later we will talk about example.
But now, very, very simple example of using of round functions. And it is very simple. But
for us, interesting last example, when we can... In round function, we can set what is...
We can set the decimal places that will be after rounding. And as you can see on this example here,
it is two decimal places after rounding. So, after rounding, we will get 1.52. Yeah. And so,
you can say that it is not
real vulnerability and it is not possible to meet it in real life. But... And for example,
all banks already fixed it and all companies that work with money already fixed it too.
And you can't meet it in real life. So, but no, there are examples and you can find it on Hacker
One. And I met this vulnerability two years ago and I know one very huge bank. And so,
no examples exist. So, let's watch the example. Yeah. For example, we have one account. Yeah. And
this account has two wallets, USD and ruble wallets. Yeah. And you can transfer money between
these wallets. And when you transfer money, the different currencies convert in between. Yeah. And
for example, in this case, we have unreal rates. But anyway, it is very comfortable for us for
calculations. So, current rates, it is 64 rubles for one dollar in case of buying. And the same
64 one USD in case of selling. And so, we have bank that use rounds into decimal places. Yeah.
And our goal is to become rich. So, what we can do? Let's watch the attack. Yeah.
We have, one second, we have one ruble on the ruble wallet and we send it to the USD wallet.
And after rounding, yeah, firstly, we convert it to the USD. And after that,
calls function rounding. And as a result, we will get 0.02 USD from one ruble. Yeah. After that,
we convert, we send this two cents back to the ruble wallet. Yeah. And
it will be already one ruble and 20. Yeah. And now we have profit 120%. Why it happened?
This has happened because of this. This is main reason. So, we had one number and after wallet,
it became more. Yeah. And this difference is very critical. So, we can get a big profit.
And you can say that now we have two additional ruble cents. Yeah. And it is not rich. Yeah.
But if you can repeat it 1,000 or maybe 1,000,000 times, you will get real money.
I think banks not allowed to make this a lot of time because anti-fraud and some other things.
But anyway, if this vulnerability exists, sometime someone can try to exploit it. And
it is, I think, the best way to fix it anyway. So, and I have very simple plot. Yeah.
Firstly, on the X, we have transfer amount rubles. Yeah. And the Y, we have profit and the persons.
And so, as you can see, the biggest profit when we send about, I don't know, 0.3, 0.4 rubles to
the dollars, to the USD. And in this case, the profit is the highest. Yeah. And as you can see,
if we send more, yeah, the profit less, less, less. And after some specific moment,
it is less than 100. So, it is non-profitable for us. And from this, you can see that it is
first way to how to avoid this vulnerability. It is set the limit of transaction. For example,
if we'll set the limit of transaction in 6 rubles, yeah, it will be unprofitable for anyone
who tried to exploit this vulnerability. So, also, there are two other ways. And
second one, it is that we shouldn't allow to clients to convert money from rubles to USD.
Instead of this, we should allow to buy USD. Yeah. For example, client will buy 0.01 USD.
And after that, client will get price. And after that, they can finish the transaction. So,
in this case, anyway, there is rounding. Yeah. And it will be. But in this case,
numbers are higher. The numbers are bigger, sorry. And it will be unprofitable for anyone
who is trying to exploit this vulnerability. So, and there is another way. It is adding commission
after certain number of transaction. It is not looks like good way. But
anyway, it works. And so, but it looks like not like good fix. So, but this vulnerability that
I found this rounding attack took two years ago, the bank fixed this by adding commission
after specific count of transactions. So, another example, it is sensitive data disclosure. It is
very common vulnerability that is you can meet in every and a lot of application. Not every,
but a lot of. But maybe, maybe in every. I don't know. So, let's watch an example,
good example, interesting example. And this example shows that what is convenient is not
always safe. So, we should look for balance between convenient and for between security.
And it is very important. And case, the bank added functionality that allowed to send money between
cards without login procedure. So, it looked like this. So, user enters firstly information about
source card, about their card. And after that, user enters the information about the destination
card. It is only PAN code. In the first step, we enter the PAN, CVV and expired date. So,
on the second, only PAN code. So, on the third step, user enters the amount of money for transfer.
And on the next step, system checks the balance and calculates the commission. And if everything
is okay, money is enough and so on, user gets SMS. The user that has the source card gets SMS.
After entering the code, the transaction is done. If code is okay. So, let's watch
into the HTTP request that was used for checking the balance. Yeah. And it was a problem. The
main problem was that this server didn't check the expiry date and didn't check the security code.
Yes. So, but it checked the money amount and card number. So, as a result, everyone could get balance
for any card in the bank. So, just by enumerating the card number and just by enumerating the money
amount. So, it worked like if you set too much money, yeah, server will return the error that
money is not enough. Yeah. In other case, it will be everything's okay, enter please code. Yeah.
Please enter the code. So, and you can set any card number. So, you can get information about
every card in bank. And it is not so good. Now, it fixed. Next vulnerability, it is unsafe OTP.
Firstly, what is OTP? OTP, it is one-time password. And it is usually one of the most
popular realization of second factor. Yeah. For example, you enter to the mobile banking. Yeah.
You enter your login and password. And after that, you get the SMS code or maybe push notification
or maybe something like this. Yeah. And you have to enter it to pass the second factor of
notification. And usually, usually, it deliver it via SMS. Yeah. And it is the most popular way
for delivering. So, let's watch an example. Yeah, we are hacker. Yeah. And we got access to
user account. And so, we want to get money of this client. So, we have to send this money from
our account to the... from user account to our account. Yeah. So, and for completing this
transaction, we have to enter the correct OTP. This OTP sends to the mobile of the client
and owner of this account. And so, we don't know this OTP. But we have to enter it. And so,
after free and correct... and every time when we create a transaction, we have only three tries.
After three incorrect entries, transaction will be canceled. And OTP has four random
digits. Yeah, digits. And it is, for example, one, two, three, four. Yeah.
So, how to make this transaction? How to finish this transaction?
It is like a little bit strange. But what if instead of brute-forcing OTP, yeah, we will try
to brute-force transactions. Yeah. What if it will be not brute-forcing, but it will be guessing?
Sounds strange. I'll explain. Okay. Very important thing. If we're not limited in the
number of new transactions, if we can create and create and create and so on, yeah, we can
try the next exploitation. We choose three different OTP. Yeah. It should be a potential
correct OTP. One, two, three, four, I don't know, five, five, five, five, six, six, six, six. Yeah.
And after that, we create new transaction. And try choosing OTP. Yeah. If it isn't correct,
to step two and create new transaction. But on this moment, it is, but every transaction,
it is regenerate the OTP. So, we can just brute-force it. We can just take the one big
dictionary. Yeah. And using this dictionary to enumerate, to brute-force all existing OTP.
No, it doesn't work like this. But it is very, very similar. Yeah. So, and we should repeat this
algorithm, this exploitation until we matched at least one OTP. If we matched at least one OTP,
the transaction will be finished. Yeah. And so, it is one big difference. It looks like brute-force,
but it isn't brute-force. It is guessing. So, in case of brute-force, we know about when it
will be finished. For example, dictionary has size 10,000 lines. So, it will be finished after
trying of 10,000 lines. So, in case of this brute-force, yeah, but it is guessing.
We're not sure when it will be finished. It can be finished on the next transaction,
or it can be finished after 20,000 transactions. Yeah. We're guessing. We're trying to enumerate
transactions. Yeah. Until the generated OTP didn't match our OTP. So, I'll explain everything.
No, I'm joking. I am not going. It is boring. So, no, no, no. But it is very interesting results.
Let's watch the results. So, probability of the successful transaction depends on the
number of attempts. So, in our guessing exploitation, yeah, after 3,000 attempts,
then it will be about 60% probability. Yeah. But if we can try 16,000 attempts,
it will be 99%. So, it is a really good result, I think. And let's watch a little bit more
complex example with new limitations. The same example, totally the same OTP,
totally the same situation, and so on. But after five canceled transactions, we can't create a new
one. We will be blocked for several times. For example, for 24 hours. Yeah. And so, what we can
do in this case? There are two possible approaches. First approach, it's totally the same
exploitation, totally the same steps, but we try not three OTP for each transaction, but two OTP.
So, in this case, we avoid the cancellation of transaction. And in this case,
creation of transaction will not be blocked. Yeah. So, it is one approach. Another one,
we can, in the beginning, create several thousands of transactions. Yeah. For example,
we can create 20,000 of transactions, and only after that, we will try the OTP.
So, in this case, yeah, we will block the creation of new transactions after trying the OTP. Yeah.
But it is not affected. It doesn't affect us, because we already created the 20,000. And
as you can see from the calculations, in case of 20,000, it will be more than 99%
probability of success. So, we will get profit. So, and also,
very good question. Is SMS a secure way of OTP delivery? Yeah. It is a good question,
because there are a lot of attacks against the SMS. It can be fake BTS. It can be
ratio of SIM card. It can be SS7 attacks. Yeah. For example, these two very
cheap things, it can be used for creating the fake BTS, for creating the fake station. Yeah.
And using this, you can try to attack the client. So, let's talk about the recommendations. Yeah.
Firstly, second factor should be enabled for all critical actions. Yeah. If you, for example,
login to account, if client, for example, logins to account, for example, if changes the profile
information, maybe other critical actions, it should be, client should enter the second factor.
Also, it is very important to limit the count of requested OTP. On the previous examples,
we tried to limit the creating of transactions, but sometimes it is a little bit hard. Maybe
you can make another vulnerability and so on. So, the best way is to control the OTP.
So, how many OTP, how many generation of OTP client asked. Yeah. And after specific count,
just stop this process. And also, maybe it is a good way to think about alternative for SMS,
because SMS not looks like the best way for delivering OTP. For example, we can watch on
the push notification, we can watch on the TOTP and HOTP. TOTP and HOTP, it is, for example,
Google notification, it is Microsoft notification. It is applications that you
have on your mobile phone and they use cryptography for OTP process. So,
it is totally silent because it doesn't have delivering. Yeah. So, client doesn't know about
that someone trying to brute force its second factor. Yeah. And so, sometimes it is very
critical because in case of SMS or maybe push notifications, client will get a lot of messages
about that and understood that something's wrong and maybe call to support and support will call
to security information specialists. And so, maybe attack will be stopped. But in case of TOTP and
HOTP, it doesn't look like this. Next vulnerability, it is unsafe randomization.
And it is, you can meet it in application where logic is based on the generation of
random values. It can be sessions, it can be OTP, maybe unique identifiers. Yeah. And it is,
for example, most common problems, it is using of unsafe predictable
random numbers generators. Yeah. In other case, it can be, for example, using the predictable
functions for creating, for example, sessions, maybe unique identifiers and so on. So, in a case
when attacker can recover the sequence of random values. Yeah. And it can be in case,
for example, incorrect initialization of random number generator and so on. And
it is one very known example when... it isn't online banking, of course, but anyway,
Russian engineer, they... but it wasn't one engineer, it was team. Okay, never mind.
A team of Russian engineers, so maybe one engineer, reversed the slot machine. Yeah. And
they recovered the sequence. They recovered it of algorithm, how it used randomization. Yeah.
And they developed their program. I don't know what they did, but they, for example,
they developed a program that helped to recover this sequence. For example, they came to the
slot machine. They played for several minutes. And in these several minutes, they got the sequence
what slot machine showed to them. Yeah. And using this information, they recovered them all sequence
of random. And they can... and they know what will be in the future. And so, using this cheat,
they can... they did a lot of money. And so, it is one of the good examples.
And so, another one good example, I heard from Timur Inusov. And he met... it is on his project.
So, for OTP generation was used LCG generator, yeah, for randomization. So, but using of LCG
is not okay, because it is not cryptography safe. And for example, when you have a sequence of
several generated codes, you can recover all sequence. So, you can predict next OTP codes.
And for OTP, it is very critical. So, something like this.
Another vulnerability, it is mobile banking identification. Yeah, it is not vulnerability,
but it is like evolution, yeah, for mobile banking identification. I'll explain, okay.
For example, we have case. Client installed our mobile banking application on the mobile phone,
and client, very good client, yeah, you know, they know a lot about security. And
so, client has very strong password, yeah. And on the mobile phone, and the very strong
password is not convenient, yeah, and it's not so comfortable. And so, our task is to
develop the simple authentication process, and that works after first login. For example,
first time a user enters their login and password. After that, something happens,
and user can enter there more simply. Yeah, for example, using PIN code or something like this.
And so, let's try to make this solution, yeah. Firstly, what is the most simple way?
After entering the login and password, the application just save the user password to file,
and every time when the user opens the application, the application sends the
password to the server and get the session, the live session. It is awful. It is totally unsafe.
Because of the saving of password, it is awful practice by design.
Do not do this. It is awful. The second problem that unlocked device provides access to mobile
functions. So, anyone who can get access to unlocked device, or maybe device
doesn't have PIN code because it didn't set. Yeah. So, in this case, anyone can just use
the mobile one. It isn't okay. And so, finding the second factor doesn't help in this case,
because this phone has the SIM card, and the SMS will be on this phone. So,
and the third one, the hacker can get access to the file with password, yeah. And in case,
for example, if application has vulnerabilities, yeah, or just because of hacker has
hacked the phone and now has root access. And in this case, hacker can just open any file on the
file system, almost. So, another case, after successful login, yeah, user sets the PIN code.
Yeah, and PIN code saves, or maybe not saves, but it uses it by checking the access by application,
and for example, now we use refresh token, yeah. And I forgot to say that the best practice,
save not password, but save the refresh token, yeah, and using the refresh token for creating
a live session. So, after first login, yeah, user set PIN code. This PIN code used for decrypting
encrypted refresh token, yeah. So, and also, this PIN code used for checking the access. So,
you open the mobile application, you enter the PIN code, PIN code, for example, comparing with
something, yeah, and for example, decrypting the refresh token, the refresh token sends to server,
and server backs a live session, yeah. Again, it is an awful realization, because firstly,
anyway, we store the refresh token in the file, so hacker, again, if there are vulnerabilities,
or if hacker have root access on the mobile, hacker can just get access to file with password.
In another case, encryption of token with short PIN code is useless, because PIN code is very short,
and brute force of this will be very fast. And also, any local checks, like PIN code check,
and other things can be easily bypassed by Frida, if you have enough access on the device.
So, it doesn't work like this. So, next realization, we save refresh token to the
kstore kchain, yeah. And you know, kstore kchain is the very good option, but it is unsafe only
in one case, when we enable the checking of biometric open code, when someone opens this
record. In this case, hacker can't get access to these records in kchain. In another case,
if no access checking, and the application just extract the data from kchain kstore without any
interactions with the user, in this case, it is totally unsafe. Not totally, but unsafe, because
of a hacker with root access can just extract it without any problems. So, also, it can be
problematic if a user has old device. And in this case, maybe problems with kstore kchain,
maybe just device don't have enough security functions, and so on. And also, but it is very
similar to the second one, and the third one, is that you completely dependency on the kstore
kchain security. So, if there are some problems with this, you have problems with the application.
And the last one realization, application asks user to set pin code, and this pin code will be
sent to API. So, API controls the identification process. And in this case, you can control
anything, like brute force, like enumeration, and other things. So, you can control anything.
In this case, it is totally the same. For example, in case of using kstore kchain,
user can't use any pin code, because it will be a pin code of device only. In case of the last
realization, user can use any pin code, because it is no limitation. And we can set, for example,
ask for the big pin code, like six symbols, maybe eight symbols, any pin code, and other things.
But it is very important, too, that now we have to protect our server-side, because
everything depends on our server-side. That's all that I wanted to show you.
So, now about conclusions. Firstly, there are good testing guides. There are good testing
approaches. And you can use it not only for testing the applications, but you can use it for
developing the application, for making applications. And it is really useful. It
has a lot of examples, and so on. Also, the next conclusion is sometimes convenience is the enemy
of security. And as you can saw from the example, yeah, third example with bank that added the
functionality of sending money between cards without login. It is sometimes too critical,
yeah. And so, it is very important to find the compromise between convenience and
between security. Next one, it is be careful with cryptography, randomizations, and other things,
because cryptography is really complex, and it is very important to understand what you do.
And just don't use cryptography without understanding. It is bad practice. And the
last one conclusion is use best practices, and use experience of other companies. Watch on other
products, watch on other applications, because a lot of problems, yeah, and some companies
already solved these problems. And if you find the correct solution, it will be very good.
And so, it is everything that I wanted to say. So, thank you for attention. I hope
you got something new from this presentation. Thank you.