Security at high speed: Vipps

all right thank you so much thank you for the introduction uh so yes uh we are Nora and Kenneth here to talk about API Security today or more specifically security at high speeds how VIPs secures their apis or our apis and uh even more specifically than that we are going to talk about psd2 compliant login systems now yeah we know this is a very Niche topic so we are going to try to get into some of the technical details but also lift our view a bit and have some key takeaways that hopefully everyone can take with them even if you're not working with these systems specifically and uh now Kenneth will tell a bit about

the agenda yes so here's the agenda we have for you today uh first we're going to talk a little bit in general about API authentication and what uh Alternatives you have when you are securing your apis uh we will also go a little deter into some of the interesting leg legalisation that nor talked about um before we dive into uh zero knowledge proof algorithms and how that is applied in uh the VIPs login uh system um after that that we're going to go through uh uh the different uh security elements that uh are in place when uh the viap makes a request to the beend services uh and also we will go uh a little bit into what happens on the

client side what kind of threats are on the client side and how can you mitigate it from the back end uh lastly we will uh be speaking about a bit about availability and how to stay up uh uh in periods of very high loud load right all right so uh first of all is anyone here from abroad and maybe doesn't know what VIPs is oh yes okay all right so to explain it quickly uh VIPs is known in Norway as a payment system mostly so it is a way to easily send money to your friends and family and also you can pay with VIPs online and VIPs does a lot of other things but these are kind of the main areas that

people usually think about and um it's kind of fun to work at VIPs in Norway because uh many people know about this so you often get some kind of questions about different types of things uh so for example sometimes we get asked how do I add a pay with VIPs button on my website uh or one time someone asked me how can they remove someone from a group settlement where you share expenses because we were at a party and he had accidentally put his is real estate agent in a uh a group for the party expenses and apparently it was not possible to remove people from the group yeah I didn't didn't know anything about

this particular feature but yeah and uh I think one of the most like fun questions to get is that sometimes people ask oh but why do you even work at vs because isn't the app already finished like what else could there possibly be to do there and I think for those people it can be extra shocking to hear that what can and I work with it is basically this yes looks very impressive here three dots on a screen and uh uh just to say it also Kenneth and I we we don't even make these three dots we are not front end developers this is the app and front end developers that do so people can

Wonder like oh but what do you actually do do you need so many people to work to work on this uh but yes what you see here this is the login system to the VIPs app so for those who don't know what you do is that you can scan your fingerprint or face ID or write a four-digit pin and then you will see three dots on the screen and you will get logged in and uh what Kenneth and I work on is the login system that works in the background here so behind these three dots and yes this might still seem very simple like do you need a whole team working on this and just a disclaimer we work on a few other

things too but yeah uh but yes to create this login system you actually have to be able to answer some quite big philosophical questions so you have to be able to answer if it is possible to have a conversation if someone is always listening a secret conversation you also be have to be able to answer is it possible to share that you know a secret without revealing any information about the secret at all so without saying anything about what it is or why it is true and the last philosophical question of all how to become psd2 compliant yes and for us the answer to this questions was our login system Winx and uh the name Winx it comes from combining

the word SNS sorry yes combining the word snsx with a V for whps and uh this is because in Egyptian mythology the snx is the protector of the pyramids just in the same way as our login system is the protector of all other VIPs apis so we thought the snx would be a nice mascot to use to use for the system and uh Wix uh it needs to live up to some quite High requirements because we actually have 1.2 billion authentications per year if we got billion and million yeah it is 1.2 billion authentications per year so the system needs to be able to scale quite well it needs to handle a lot of traffic and uh again to reach any

other API in VIPs so to do anything else in VIPs you need to go through vs first and this means that the system it needs to be quite quick so here it was not an alternative to make a really slow login system that's very secure it needs to be fast because otherwise users uh they would just drop off so we needed to find some way to combine the security and speed of the system and also Wix has to scale quite well and uh we will explain this in the end of the presentation but sometimes we basically get almost like AIDS attack on WIS so the system needs to be quick and scalable yes and before I go into more

or we go into more about how Winx works we are just going to take a quick quick detour and talk about API authentication in general now this might be well known for many of you but we just want to be on the same page before we start with the rest so if you have some API that doesn't have any authentication at all then you will have some URL and anyone in the world can go to this URL and get the information that's served behind it so apis with no authentication are just a URL where anyone can ask okay give me some data for this user and they will get the data back and uh you can secure apis or add

authentication on different levels so the easiest level is to maybe add a username and password so you could tell people okay you can go to this URL but you also need to provide a username and password to get the data back and uh as many of you probably know there are some security issues with this so if you only use username and passwords they can be brute forceed they can be fished there are many things that can go wrong here so another way to secure an API is that you could ask users that okay you need to provide an API key to get access to data from this URL and an API key it looks a bit different than usernames and

passwords it can look a bit like gibberish with letters and numbers so it might look like it is more secure but actually API keys they have many of the same security problems as usernames and passwords because they can also be brute Forest fish they can be stolen in many different ways so what many apis do is that they require something called an access token to get data from the API and an access token can look a bit like an API key there are also some letters and numbers and you usually send it in a request header called the authorization header and when you send this token you get data back from the API and um tokens they can also be

stolen and they can get lost in various ways however if an access token gets stolen it is a little bit less of a crisis than if someone manages to steal a username and password and uh this is because access tokens they always have an expiration time uh so here you see an access token to the left it is encoded with base 64 and decoded here on the right side and um base 64 encoding it is not encryption or anything like that so anyone who gets this token they can decode it and see the information on the right side um and you can see here in the decoded expiration that we have added an expiry time of 10 minutes to

this token so the apis will check is this token older than 10 minutes and they will not accept it if it is uh but I just said that anyone if they get the token can decode it and get this value to the right so what stops someone from just changing the time here so for saying that okay this token is now valid for 10 hours and uh this is not possible to do because tokens it's important to remember they are cryptographically signed which means that you can always trust this information inside of them as long as you check the signature so for example our login system wiins it also signs tokens with V's private key and

then anyone can check that that token actually comes from the wiing system and they can trust that this information here is correct and uh it's also important to remember when we go on with the presentation that these values here they are called claims we will get back to that later and uh yes kenet so okay we have now said our login system it also gives these tokens that you can use to access other apis um but this is not something new there are many many login systems that do this like login with Facebook log with Twitter uh so can you say a bit more about why don't we just have login with Facebook to log the VIPs

app yes I can say a little bit about that but uh first I need to take this little detail into uh the topic that I know you have been waiting for uh to learn a little bit more about EU directives and namely the uh psc2 directive uh this is the payment services directive and it's a second ation um and it was enacted in Norwegian legislation in 2019 uh and this uh sets some uh Central requirements for everybody who do Payment Processing like we do uh those are uh strong customer authentication uh we must really be sure uh that we know who the customer is who is actually performing this transaction and it sets some specific requir

requirements uh on how uh we must verify this uh one of the most uh important is that um we must always use multiactor authentication so uh a pin code or Biometrics together with some possession elements like knowing that you have the phone or something like that um and also uh we must be able to provide a mechanism called Dynamic linking and that is that not only must we be uh make sure that the uh the customer the user is who we think it is but we also uh must be able to prove that this user approved this particular payment

transaction and uh this user approved this particular uh payment transaction and and this uh Dynamic link kind of creates a binding between this approval that user does when it gets up the payment confirmation screen and the actual uh processing of the payment afterwards so we can be able to uh to maintain this uh chain of evidence throughout okay but uh back to your question uh why couldn't we have this in the viap wouldn't that be nice uh well we could but uh there are some problems uh one of the problem is that all of these are third parties and I don't provide the kind of guarantees that we need uh to to prove the identity

of the user I also don't provide these guarantees that we are required to to be able to do according to the psd2 legislation so they don't provide this Dynamic linking and I don't provide a good enough guarantee that uh they know who the customer are at least not in a way that we as a third party can use um and that's only part of the problem uh the other part is that doing login is just one that's that's just the first step right after that the app will make further requests to the back end and a lots of other things will go on and we must make sure that uh it is still the same party that is talking to

us there has not been a me man in the middle somebody hasn't taken over the conversation midways so there's a lot of other uh mechanisms that we had uh to make sure that we have control over the situation so that is uh why you won't see uh sign in with the GitHub button in the whs app soon okay uh zero knowledge proofs uh sounds like a quite academic uh topic but uh you're going to explain it in a nice and easy way uh yes so so far we have established that we have this login system vinks and that if a user manages to prove their identity they will will get some access tokens from vinkx and uh the question is

now what happens in between here so how does a user in our login system manage to prove that they are who they actually say they are and uh what we use in Winx is something called the SRP algorithm and it is based on a concept which is called zero knowledge proof and uh zero knowledge proof that is a way to prove that you know some secret without revealing any information about the secret at all so if you remember this was one of the philosophical questions that we asked in the beginning and um Kenneth will go more into details about how this works but I will try to explain it on more of a high level with an

analogy so uh the way you can think of zero knowledge proof is that you can imagine this so imagine that you have a colorblind friend and you have a red and green ball so is there some way to prove to your friends that these two balls are actually different without him being able to see the colors or see the secret and uh here is how the proof system works so uh what you could do is that your friend could put the balls behind his back and then he could place one of them forward and then put it behind his back again and place it another one or the same one forward again and each time

time he will ask you have I switched out the walls this time and if you manage to say to him yes you have switched it out or you haven't you managed to say it correctly one time your friend might become a little bit convinced uh but he might also think that oh you just got lucky and you guessed correct because there was a 50% chance of guessing correctly uh but if you repeat this experiment many many many times the chance of you just guessing it statistically goes a lot down so in the end your friend by just knowing if he switched the balls or not would hopefully become convinced that okay you are actually able to see the difference

between them without being able to see the colors himself this is basically how the concept works and uh if you want to learn more about zero knowledge proof there is a nice uh YouTube video that explains it in many different difficulty levels from like beginner to Advanced and we have also linked here the Wikipedia article for the algorithm SRP because in the article in the Wikipedia article there's a really good um overview of all the implementations of SRP so if you want to use it in your own projects you can use some of these third parties in different programming languages and uh Implement uh and integration yourself and uh yes so this was more of

a highlevel concept of how our login algorithm works but Kenneth will now try to explain in more Technic tech details what actually happens yes um first before we get into uh to SRP and how we apply that I just wanted to briefly mention the first step that uh we do whenever a new device a new phone uh tries to speak to the the VIP speckin um because I I said that earlier that we must be able to maintain uh that it's still the same uh device talking to us through the all the API calls that that the phone makes and uh uh the first API call the app makes is uh uh it transmits a key a public key is

it has generated a keypad locally on the crypto Pro processor that is present in all modern phones uh and the private part is stored inside the crypto Pro processor and can't be extracted from there and the public key is sent to uh to vinx and all requests that the app make afterwards is signed by this public key so therefore we know that or signed by the private key so therefore we know that the um uh uh whoever sends this requests has access to this private key and this private key is locked inside the crypto Pro processor inside the phone uh all right so this is just the first step but then we get into the SRP

part um uh the first time you need to do before you can log in with your PIN code of course is to set the PIN code so that you are allowed to do during the onboarding process when you set it up um and uh what we do then is uh we calculate something called a verifier from the PIN code and also some additional data that we pass along so you don't have to worry about the brute forcing our four-digit pin code um and we send it as a verifier to the Wix apis this is a step in this in this SRP algorithm and later when you uh want to log in basically the process is that uh

both on the uh app side and on the server side uh a calculation is done uh we start with uh random values each time uh and uh uh on the app we use the PIN code that the user types in on the server use this verifier and the calculations are a bit different on each side but uh the end result is supposed to be that you end up with the same a same the same secret key this key will be different from each time you log in because you start with random values but it it's supposed to be the same value on both the um appside and the uh backend side and if you manage to do this

correctly that means you typed your PIN code correctly uh you end up with the same value and then you have a shared secret between the parties that you also can use and that has never been transmitted over the U

internet yes after successful login uh Wix emits or issues uh tokens uh just as many other systems do you get an access token which is shortlived and you get a refresh token that you use uh the next time you start up your app after yeah uh doing something else for a while um the refresh token is only used uh with uh Wix itself but the access token is passed to all the other whips apis and they they check that uh it's the correct access token that is sent and that it's not expired and so on yes and then uh I told you earlier about this Dynamic linking requirement that we have that we need to make sure

that uh the user has actually confirmed the payment transaction uh we do that via what is basically a regular login uh but when you use your fingerprint or face ID or pin code to confirm the payment on the payment screen um when the app logs in then it's it passes some key data from the payment along with the login request uh to Ms and if the login is successful then that data is embedded into the access token and then later uh when the payment uh confirmation API call is actually made uh we have the uh the uh the data in the exis token for the payment and it's supposed to match the actual payment being performed so that

means that you can't use one payment U confirmation for one payment to confirm or have another payment process you can't edit the amount or the recipient or anything like that yes uh this was a high level overview um now I'm going a bit more into uh the details about the different security elements that we have in our request to the Rip's backend so uh we have uh talked a bit about the access token and refresh token that is issued by uh uh uh by WX I also briefly mentioned that we sign each request with this private key that is created when the app first uh contacts uh the whbs backend uh in addition uh I've said

spoken about this uh key that is calculated when you log in that is supposed to be the same on the uh the app and backend side and these are all uh present in our request uh to the back end uh and I Ed to prove different things so uh we have the request signature that is locked that is locking the request so that you can't modify the request and reuse it on a different signature the access token also contains a reference to the key that is stored in the in the app uh you have this um MFA signature and it's used to prove that whoever um can sign can make this sign signature correctly was present or was

was the one that actually did the login sequence and all of these elements are uh linked together so you can't take one out and reuse it on another uh device or in another situation so for instance you can't take the access token from one request and use it to make the same request on a different phone because uh there will be a mismatch and you can't do two different requests on the same phone uh but change the details that won't work either so this is how a typical payment confirmation request could look and we have this uh exess token here in the in the authorization header it contains in the just subject claim it contains this key identifier

that I talked about this identifier of the the key that is just stored in the crypto proc processor on the phone and it can also contain the payment details if this is a payment confirmation and then we have the request signature and that is uh basically a sign over all the key uh data under request you have the URL and the method the post method here and all and um and the hash of the request body itself and it also references then this um this private key that you have on the phone and you have the hash here as well that is server that will then verify uh and you have this um MFA signature that is uh connected to the

shared secret that you um uh that is uh calculated during the login and it is linked to uh to the uh exess token so you can't take that and reuse it with a different exess token

either yes so so this was a just a quick tour to how it actually looks uh when you make a request to the the whips uh backend and how all these elements are linked together um now I'm going to go into a different topic um when uh I first started working at uh at whips I was thinking okay I'm a backend developer uh my job is to make secure apis and once if the API is secure and there's no known Hol holes in it then my job is done right I don't need to care about what happens on the client side and whether the client has a compromise because that's that's the users's uh concern right whether the

user has an hacked app or whatever I don't care too much about that I just don't trust the client side and then I'm I'm fine uh but um when you work with this kind of like high value systems that are very attractive to criminals uh and where you have a large user base that is not educated in computer security like we do with whips uh that is not good enough uh we must actually care about what happens on the client side we must actually help uh users so that are not victim of uh of uh different kinds of fraud uh that uh can result from having a compromised uh phone for example and there are different kinds of

threats on the client side of course uh the most common is uh low Tech it's uh social engineering it's fishing uh but uh it's also possible to hack the app of course and modify it you can have malware installed on the phone that uh prevents overlay presents overlays that looks like uh VIP screens for instance uh or do key logging or other kinds of Ling and you could have a jailbroken phone or rooted phone and it can have operating system modifications that can steal your data um from like a when you're on the back end uh trying to defend against all of these it becomes kind of a cat and mouse game it's uh it's not as black as white

and white as as for API security where you either are secure as far as you know or you have a hole and must fix it in this case it's it's a constant uh balancing of uh how many fraudulent transactions you catch versus how many false positives you get so we don't want you we don't want to annoy the users either um and I'm not going to go into in detail uh what kind of uh rules and uh checks we Implement here uh because that can change uh but there's one mechanism I want would want to go into and that is that we use um remote attestations um that is a feature that is um present in both the um Android

phones and iOS phones and where you basically ask the um you asked the the phone to to present to give you an attestation that verifies that the the environment that it's running on uh the operating system and the app itself hasn't been modified so the app will basically make a request to Google or Apple and uh that request will then be sent to the Wix apis and we will uh validate that it really came from Google or Apple and that the attributes the information inside uh says that this device an app can be trusted and if uh this check fails then the device is blocked from uh speaking with the VIPs

apis yes and then the last topic availability and how to stay available uh yes so uh at uh VIPs we have some very high traffic days where we suddenly get a lot more requests than usual uh so for example for for those who are from Norway you might know about 17th of May the Constitution Day where everyone is trying to buy stuff at different kiosks and paying with whps because we almost don't use cash anymore at all then we also have Christmas Eve because we have a gift function so many people send gifts via VIPs and we also have something called tun and that is a big charity event in Norway uh where the state channel uh they create a big event

with a lot of things happening where people are supposed to send as much money to charity as possible and uh during that time we have extremely high traffic via VIPs because that is one of the ways to donate and um so uh we will talk about how we ensure availability and uh one of the things is to make sure that our infrastructure scales but we also need to make sure that our system works quite fast at every time so what we try to be careful about is that every time a request happens there is not more than one read and write to the database so that is a good rule to remember if you're also making other systems and

then we also try to have asynchronous calls for various things so for example if we are going to block a user we don't like stop the entire login sequence to wait to see if a user is blocked even though they they will not be able to log in but this will be an asynchronous H job happening it will not be one step that just simply waits for another at all times and then uh we try to have as scalable infrastructure as possible and uh what we use uh for wins is that we are on Azure so we use Azure functions and Cosmos database which is a nosql database and Azure functions is basically a serverless options so it

means that you don't have to manage your own machines and it's supposed to scale automatically uh however before tun and some of these events uh we still uh have to make sure that we have enough standby instances in the background to be able to scale quickly enough for the first wave and uh with Cosmos we are also able to scale it inside of azure and uh yeah we have had experience with this working quite well for the recent years for T acon when we get a lot a lot of requests uh yes uh so uh in the end we just want to say some uh quick uh key takeaways so when I first started working at whps I

thought it was kind of cool to see the wiing system and the SRP algorithm because to me this was uh being able to see that oh it's possible to make a system that is secure but that also is really quick and hasslefree for users and I think in recent years we have actually seen more of these systems which are like both secure and easier to use for example with the pho2 if anyone is familiar with that that is like a quicker passwordless way to log in it's so it's quicker and both more secure and uh also uh what I saw here is that when you have really high security requirements I think it can actually

drive innovation in a way and this is because if you are going to make a system and you have no limitations so imagine that you have just all the manual resources you want you have no security requirements then I think this will actually lead to a more inefficient system as so for example once I used a like a train app system where you buy train apps and this was in a country where they had access to a lot of lot of manual resources so someone was manually approving each like transaction in the background because they were able to do this uh but if you don't have all of these resources available then you need to think more about Auto

and doing things quicker so I know I hear from some people that uh oh maybe all these requirements that we have all these regulations and security requirements in the Norway and in the EU it will just slow us down we will fall behind but I think actually quite the opposite will happen because um I believe these limitations will lead to more Hightech Solutions because there is simply no other way to get this done yes this was everything from us thank you so much [Applause]