Hello, everyone. I'm really happy to see the faces I've already met during the presentation, during this conference. Welcome back. Hello again. I'm Bartek. This is Bartek. We don't have to learn two names. We are actually quite excited to share this story with you because it's the first time we speak about this deployment.
It's, I think, the first deployment of Passkeys in a bank environment at such a large scale. And we are very happy to share the story.
So, let's start with Bartek. Okay.
Hello, Bartek. So, first of all, let's take a glance on how the authentication process looked like in our Go9 Business App from the user's side. First of all, what is Go9 Business App? Go9 Business App is a critical asset for us, which is responsible for payment processing. It's an app dedicated for companies, so we can say that it's an app for business users only. Having said that, you probably feel how important it is for us to have a safe but also convenient authentication mechanism in place.
Nowadays, we give possibility to sign in to Go9 Business App using password. We support, of course, MFA, multi-factor authentication, and for this need, we use mobile token and SMS codes.
Now, you can see the scope and the reality which we have met at the start of this initiative. What more can I say? Even with the MFA in place, we are not safe at all. You probably heard about synchroning and methods like that.
So, we wanted to find something much more secure. So, basically, this is what we started working with. That's the type of authentication you guys know, right? A username, password, or a form of it, and you're in.
So, this is where we started. Let's go where we went. Bartek mentioned problems with phishing, with synchroning, etc. This is the first why we started with this project. Let's get some numbers, which are not that boring, because phishing and security environment did change in Poland in the recent years. Just to say that in 2021, the staggering 182% rise of cyber security attacks, and 72% of those were related to phishing. This is the most dynamic here, but in the following years, the trend continued. As far as I remember, 45% of all attacks were accounted for phishing.
I think the second was denial of service, which was 16%. But the fun part here is that most of those attacks used some sort of financial role, financial scenario as their hook.
So, for banking, that was very important. The other factor that we took into account was the hidden cost of passwords.
So, a thing that not everyone really takes too much credit for, that maintaining, changing passwords, paying for service desks, does add up to a serious amount of money. I will invite you to download our report later on. I will show you the link, which makes some calculations and really shows how the numbers for passkeys, for passwordless authentication, look compared to traditional passwords, both for customers and workers.
So, now let's talk about the drivers of this initiative. So, our first driver was to provide a much more secure, phishing-resistant authentication mechanism for our clients. While our security measures were not in current flow, we recognized the need to address emerging threats, including increasing sophistication of phishing attacks.
So, as you can probably know, passkey is related to FIDO, and with FIDO we are phishing-resistant. Moving forward.
So, the second driver. We wanted to maximize the convenience of authentication for our clients. You probably know how inconvenient it is to sign into the app using a password, and the second factor. We wanted to change that and to get better. Based on our internal statistics, we get about two events of blocked account per one client per year, and the operational cost of such an event is about 10 up to 15 minutes. And the last driver of this initiative. We wanted to become a market leader. We wanted to be the best in Poland.
No bank has switched to password-less authentication yet, and in Europe only one has. Only one, but not at the scale that we are talking about.
So, the BNP Paribas Bank Poland is among the first banks in the world. So, now a little bit of background. During presentations about technical changes in our bank, we often show one slide, which is crucial. This slide shows how many marriages we've gone through as a bank. The BNP Paribas Bank Poland has been formed from multiple different financial institutions that were connected in the past. You may ask, why do we show that?
As you can see, changes in such an environment are never easy, because after any marriage with other financial institutions, different domains must be connected, and different systems must be adapted to a unified network, infra, and so on. And the solution.
So, PASC is a basic story, but it became an obvious solution, right? Well, the complexity of the banks I am was a challenge here. The complexity that you've seen on the previous slide is inherent for many banks, because the technological stack of the bank usually shows the history of the aforementioned marriages, aforementioned transformation, etc.
So, let's perhaps move on to the solution of what we exactly did. A very simple creating of PASC. I'm showing this to you. Unfortunately, it's in Polish, the bank is in Poland, but you do know those procedures.
So, we've got a registering of PASC. You have an easy PASC login.
Obviously, this is not easy here, because it's a dev environment, and the amount of credentials used during testing is staggering, but we'll get to it. So, again, that's logging with PASC, just for the sake of history. And one more thing we've developed is the management of PASC.
Again, this architecture consists of many interlocked technological entities. So, I have a question for you. Knowing the complexity of the project, and knowing what we achieved here, how long do you think the project took? Are there any wild guesses you can think of? How much? Three months. Any other guesses? Two years. I've got three months, I've got two years. Should we do a bidding war?
Okay, I will hold you with this question. I will answer it in a moment. Let's talk a little bit more in depth about the solution. Okay.
So, during this project, specifically the implementation of PASC, in the Go Online Business App, we had many challenges. Unfortunately, I can't tell you all the details, especially the technical ones, which I truly regret. From the technical side, the one thing I can tell you is that we didn't make any changes in the Go Online Business App code. All the PASC-specific buttons and PASC-specific functionalities we added using the SecFence PASC security broker. With this broker, we added functionalities like buttons to add PASC, to edit PASC, to delete PASC.
We added a call to action for users, which sign in to the app using traditional methods. And, of course, we added sign-in via PASC on the login page. All those changes without changes in code.
Yeah, that was one of the challenges we encountered with the project, how to implement PASCs without actually altering the bank structure, the bank environment. So, that's one of the challenges we met, right? The biggest one, I think.
Yeah, the biggest one. So, just a glimpse, we did make use of a technique called content adaptation.
So, basically, all the GUI elements you see here that are embedded in the bank web page are not part of the application code. Those are all injected by our application broker using aforementioned content adaptation and load balancer techniques. The other challenges were...
Yeah, so the second one is about the complexity. Our Go9 business app, like our bank, is made from many, many components that need to cooperate. And this setup, what is important? Those components from which Go9 business app is made are developed with two different independent vendors.
Yeah, which means the documentation for both components is scattered around the place. And that obviously makes it difficult to navigate during such large implementation. We found a way to join together and distinguish the traffic that is meant for legacy.
Well, not really legacy, because those ways are still valid and working, but the current ways of authentication and the traffic meant for our broker. So, we basically cherry-pick the packets we need and we act on them and follow them further.
So, very simple and a very elegant way to navigate through a complex environment. Yeah, and what is worth saying is that we didn't have one unified documentation about all components.
Yeah, exactly. Okay, so the last challenge, probably the most technical.
So, the POC phase. We wanted to make some kind of POC phase.
However, this phase we wanted to make on the production. So, yeah. And we wanted to use a group of users called family and friends. But the challenge was to have to add PASC-specific functionalities only for those specified users, which we took for the POC phase. And how to do that? We used a cookie mechanism.
Yeah, maybe I've said it. Well, the cookie mechanism, alongside the mechanism by our design called OptinList, allowed us to, again, cherry-pick the customers, the user base that will be affected by the change.
This, plus our codeless, agentless and uninterrupted design, actually allowed us to do it from production. It does sound quite funny, right? But it is possible due to the, well, distinguishment of traffic for the legacy part and the new part.
So, how long did it take? Spot on three months. From deploying from the first initial deploying of our VM in the network to the end of the POC phase.
So, well, I have a T-shirt for you, for the guests. Come to our booth. I think she doesn't hear, but yeah, I'll see you. I'll give you the T-shirt.
Okay, so, that was technicalities. Unfortunately, as Bartek said, we are not able to dive too deep into the technical phase, as we don't want you guys to hack the bank. We don't basically want anyone to hack the bank. What about the business case? We've seen some quantifiable improvements. When we calculated the cost of password in relation to path keys, we actually took only the very basic into the account, which was the cost of the maintenance by service desk.
So, basically, password resets and the cost of second factor as text messages. You need to pay to convey this secret code by text. We kind of forego the other hidden costs, like loss of productivity, help desk escalations, security risk, etc. But even while neglecting those costs, we came to a conclusion that in five years' period, the bank will save six times more money.
Well, the path keys will cost the bank six times less than the actual use of passwords. Actually, this is a very clear business case for the bank. We have some more business cases on our page. Please don't worry, this is not a rogue QR code. I do vouchers quite safe. I remember one RSA conference when one of the vendors displayed a QR code with the banner to win an iPhone. Scan this code.
Well, obviously, there was no iPhone in the bank. It was just a very red, very malicious site. While scanning, please also consider visiting us at booth 42. I do know it's hard to navigate about booth numbers in this place, but I can just help myself. 42 is the answer to life, the universe, everything. Who knows?
So, we'll be very happy to see you there. We can talk a little bit more in details when the talk is not live streamed.
So, we'll be happy to answer to any of your questions. Thank you for your attention. Unfortunately, the timer did not work, so I have no idea whether I overdrew or not or was I spot on. Do we have time for questions, though? First of all, thank you very much. Let's start with that. Thank you. I think this is a real-life question or topic. There should be questions. I'll walk over there.
Okay, you need to pass it on. Can you please hand it over? Thank you. Thank you very much for the presentation. I see you added some new buttons on the login page and the account settings. How do you make sure that users adopt pass keys?
Well, there will be definitely an informational campaign about how to use pass keys. Pass keys are still not very consistent. They work perfectly on the Apple ecosystem. When you use devices like iPhones and computers, they do not work as perfectly as I would like them on Android devices, at least not all of them.
However, a proper educational campaign, a proper marketing campaign, and a huge advertisement once the user logs in that shows that this tool is more convenient than passwords, hopefully will do the trick. You had a question as well? The same question. We're actually planning to do a huge educational campaign in Poland regarding the use of pass keys, because we believe in the technology and we want it to get as widespread as possible. Final question? I have another question. How are you dealing with the possibility of sharing pass keys?
Because if you're going to do it on a mobile device such as an iPhone, you can share it with your family. That is a great question. I actually love this question.
Yes, that's the problem with mobile-bound pass keys. They travel. When you register a pass key on an iPhone, there's a huge chance it will travel to your iPad in the kitchen where your kids play Minecraft or whatever kids play nowadays. We actually have an idea for that. We're using also, I believe, a cookie-based technique that allows only to use a pass key from a device you registered it on.
So, your iPhone will be able to authenticate you, but your iPad won't. So, that's also our technique and our idea.
Okay, thank you very much again. Thank you very much for your attention. I'll be happy to see you in our booth.
