G1234! - Who dis? The Right Way To Authenticate - Lakshmi Sudheer & Dhivya Chandramouleeswaran

hey everyone I know it's right after lunch and welcome to our talk whoo this is the right way to authenticate to start off who are we I'm Lakshmi Sudhir and she is Divya so we do all things applications charity we work with we work or to do like secure software development cycle to be involved in secure software elephant cycle and all stages we work with a lot of developers we work for them so that we can go ahead and ship seek out products we had one locally we want to give a shout out to its Narayan garage he worked with us on this project but unfortunately he couldn't be here today I assure you he's alive we have not done

anything to him ah this project doesn't kill anybody so before we head on to the presentation itself just a quick note all of this research is based on publicly available data there's nothing that has been taken from a company or anything like that that's something that's accessible to everyone also one more call-out is we are not advocating that you use anything that's inherently insecure but as you most of you know in the real world there are cases where even if you have a really strong protocol as such there might be a part of it's inherently insecure component that you would have to go ahead and implement in those cases we are just trying to make sure that we just found a

couple of like secure ways of doing it and that is what we are talking about today we are not advocating using anything inherently insecure now that we're done with all our disclaimers let's start with what is this talk about what's the agenda for today so today we're gonna talk about the background itself as to why are we here talking about this and talking more about the problem statement like it's 2019 and we still have to talk about authentication so we're gonna get into more details about why is this problem statement itself and more details about the issues itself then we're going to try to touch upon some of the remediations and try to understand the

patterns across authentication itself and various protocols and then we can have some time for questions and answers so what is indication when we think of a 10th occasion the first thing that comes to mind is identity now how do these two piece together identity is who you are authentication is what verifies that verifies your identity it says that if I'm Lakshmi that's authentication is how I verify I'm Lakshmi and we think of a lot there are a bunch of protocols that have been built bunch of technologies bunch of platforms that we use to establish authentication itself but they inherently lie on three basic principles one is for me to establish my identity it could be something that I know that

could be a secret a token or just when I'm trying to try to get money and cash to gamble out here in Vegas since I'm here I had to use my pin so that is something I knew and then possession possession is more around you beliefs you could have a moral device you could have something else that is a physical entity or something that only you possess such that you could establish identity the third part is something that you inherently are I open my phone it's my face ID I use my touch ID that's something Who I am that's something that's unique and that's how I establish my identity itself so authentication in short for me the user service anything

to do with it is based on three broad things knowledge possession and inherent so where does authentication come into play it could be as a user when you're trying to access an application on an application talking to the backend user authentication some of the common things we spoke about was faced ID a couple of like what L said I talked about how you became password secrets and all of that but when we had to actually put together this presentation and look for all the data we logged into an application that was the user user authentication aspect of it and then these this application spoke to multiple other applications out there and those applications to pull out

like some of these authentication issues for example and they had to access their database pull out all these reports they have consolidated and returned it to the service the service consolidated it fed into a bi tool to make it like more presentable make it into all these fancy graphs such that we understand and we can ingest the data and with each of these communications all the services had to identify to one another to make sure that it does the right service it's talking to so there's so much out there in the ecosystem making authentication a very important aspect it's more of the backbone when you begin communication in this whole complex ecosystem with AWS and other cloud and sensors out there

and cloud services everything is almost reduced to a web service per se so authentication has become more and more important as we've progressed in this ecosystem now why are we here is there a problem of course yes no surprises there and that's why we are here today to talk about this and we are all here to discuss and see how can we make this better if you're still not convinced and skeptic like me we have some data fear so as most of you know o as amongst OS top 10 even during the latest revision the top second one right after xxe I mean xxxx er sorry cross-site scripting exercise so right after cross-site scripting was broken authentication with

sam'l Oh Kerberos we have a million authentication systems out there it's pretty surprising that this is still on the top so we took a little deeper into this and this was the point of Inception where we were like this is a hacker one report for bounties that were paid out by companies companies have seven so much money on it and this came to a close second broken authentication or improper authentication was something that companies had spent a lot of money of the Monti on that was again the second highest after cross-site scripting this was a point where we were like this shouldn't have been a problem really after so long why is it still a

problem I mean we didn't want to remember a lot of passwords it was hard to have complex passwords and remember all these passwords and various applications that's why we came into single sign-on we had all three created multiple systems and multiple protocols and it's still sans there on the top so this was where we felt that this required some research we really want to work on this because this is an actual problem we want to address at one way or another and this is how I talk got I mean this was the inception point for our talk itself now there are further more details we pulled up like some of the records which were high risk and that's

something that further motivated us so the we are going to talk a little bit about that you know okay hopefully you can hear me now all right so once we had the inception point of that hacker one report like the second most problematic area was broken authentication obviously the reigning king has cross-site scripting so we kind of vented to the past year what are all the OAuth issues or at least the general authentication issues that have been reported and one of these like this one even seeing the report kind of pulled me in because like this is a social login scenario which is supposed to be secure but still inherently during implementations something went wrong

similarly you have stealing or tokens where redirect URI and again a similar one insufficient or callback validation again pointing back to redirect URI and finally authorization token not expiring after logout now this is not inherently like an issue or even like a specific authentication scheme or a protocol issue it's just general that ties back to the token so what you are seeing in a screen right now is just cherry pegged like issues that we saw and we kind of dope deeper to do our own case studies but we saw multiple issues not just limited to this and that kind of led to like is it a common issue across protocols is it a common issue across schemes is there

like one protocol that gonna be like I'm gonna solve all your problems regardless of implementation it's good to dream about it but it's not the reality so yeah this is what we the sort topic so as the way I said after this we thought we should come up with an approach to address this and understand if there's some common patterns and themes so we started off going over the top hundred websites and we like what are the most commonly used authentication protocols and how do we classify them amongst these protocols we identified a couple of protocols and then we were like hey what are the high-risk issues what's the worst thing that could go wrong and so that we could

focus on these high ROI issues and then we dug into what could be your remediation what is the best case scenario for remediation because most best practices for the most part are sometimes not really applicable actually most times not applicable in a business scenario so how do we go about maybe having difference in depth are just outlined some of the remediations that may work there is work for us personally when we were talking to developers and maybe that's something that we could share and also I think the primary idea I feel is that as security engineers we owe and responsibility to guide our developers towards the right way in the most secure way that's what our job is

so we felt that we need to make this usable and understandable for the developers themselves so this is approach and for today's talk we are gonna focus on four of these we're going to talk initially about the JSON web tokens the chain abilities are jots and then we got to focus a little bit on what password lesson magic links and then we're gonna talk a little bit about sam'l as well and in our conclusion we want to draw out like what are the common patterns and how do we go about why why is authentication such a big problem even today so let's start with a JSON web token or chart now what is a token in general token is just an

identifier which is used to authenticate that is what is validated by an application you present your token it's like hey this is a valid token I mean this is a valid user this is laxmi and it's hard oaken so let me provide the service but she's on web tokens it's nothing but a JSON encoded representation of a couple of claims which is digitally signed such that you have some key value pairs and this provides authentication because when you submit this token itself the application that's receiving this can actually go validate the signature and you have this JSON body which has something called claims which is nothing but you could have scopes you could have the user ID

in of a single session identifier which has a unique number or a random token you use this which is a JSON body and it is digitally signed so we use both asymmetric and symmetric algorithms so perform this digital signing itself so let's let's just look at a scenario now as a user I sign into some application using Facebook or any of the social authentication systems then the authentication server validates my username password or any the primary authentication part and then it provides a JSON web token back to the user now this JSON web token we are going to dive deeper into the structure of it and more details on that now when this user presents the so go into an application

server the server actually validates it has this been tampered with and it validates the signature itself and then services based on whether this user should have server access to the application server or not and processes the HTTP request that was being sent there it could happen again between service to service as well so there to competence this could be used as a session object as well as between service to service for service to service authentication now why would you want to use charts instead of a session identifier that's because one it provides authentication through integrity again I want to call out that this is just basics for encoded so there's no confidentiality but there's integrity because there is a signature

to the body in the header so you get an indication you can also add some information or an authorization saying hey this user has Coke because it's a key value pair at the end of the day with JSON so that way it's easier to share that information which makes it stateless now with session identifier you would have to store like the identifier unique identifier on your back end and also store like the user ID or any associated primary key out there with this it makes it stateless all the so application server has to do is as soon as it gets a service request it looks into the signature it validates the signature it's great there is the

scope information so it makes it amazingly stateless that makes it scalable as well compared to session tokens it's compact you would say it's compact and lightweight because mostly Jason key values are pretty compact of course it depends on how much you put into the payload of this but it's pretty compact for the most part and again coming back to point of the key value pair in the JSON body you could have information exchange so this could be useful let's say in cases of like oath where you have a token issue or an authorization server that's giving tokens in your multiple applications that way it's more scalable with different applications when you're using JW T's you could have an

information exchange information in this payload part of it saying hey this person has corrupted this application this application or even sent out some usual information around user ID or a gooood or more on those lines so as I said with all of these properties where is the use of jail abilities which is pretty common it's using OAuth it's used in open ID connect in OAuth it could be used as an access token Refresh token and in open ID connect it's used as an identical token and some applications also use it just a session objects itself the structure of a chart so the three parts the two JWT one is the header the the one you see on the left

here the header payload and signature is what is being passed so it is a basic C for URL encoded string that gets submitted to your application so this header is what contains now when you decode this this is what you see for the header component you see the algorithm that's been used to actually create the signature again you could use symmetric as well as asymmetric algorithms to actually get the saw create the digital signature with symmetric I think the challenge is more around like sharing secrets across the other parties that have to validate this so a symmetric is something that's pretty common because you could of course rely upon the public/private key architecture you could mean infrastructure so that way

even if you're a token issuer all you have to have as an application or a client application is just have the public key so you could validate this so the header contains the algorithm and the type is JWT because we are talking about jeopardy tokens there are other kinds of tokens which is out of scope for the stock and the payload is where the meat of this is this is where you can have like hey this is the user is he an admin is he not an admin you could also have more information around like what time was this issue that when who is talking issuer when does this X and all the information out there so

this is what is the main thing that is that has made it more attractive for the developer community to use jots instead of a session identifier so this is where you have all the details and the signature is where the header and the payload are hash I mean it's there digitally sign and this is a part that a server validates when a chart is submitted during our service request now that we know that this is the structure let's move on and see if this is a valid chart show fans if any of you think this is a valid one valid chart okay awesome you're alright the way you are biasing them so awesome you guys are right

actually so even though here we saw that there is a signature company and there is a value for the algorithm itself we see that the algorithm value here is none and there is no signature unfortunately not unfortunately there might be a business there is a business case for the none algorithm but when you're using this as a session object or to establish session or identity as such this is something that most implementations have missed is verifying that the algorithm is not none because when this chart is submitted to a service it looks into the algorithm to see hey was this using a symmetric algorithm or an asymmetric what was algorithm used when it looks at none the

inherent behavior is to not look at the signature and then just process the chart as an attacker I can create any number of tokens out there and just provided to a service with the none algorithm the whole point of authentication is lost here there's a authentication bypass and I have complete control over anybody's account so this is one of the most common issues that have has been there from 2015 I think 2014 ash was the inception of J double tees and this was discovered in 2015 and still there libraries which support this so how do we go about remediating or making sure that we take one we take notice of this and the second one how do we go about

remediating this so again like I said there's a best-case scenario there's an okay I mean like something we could do with in that case programmatic controls of course are the best way to go with any validation as such so one of the things you could do is you could make sure that let's see is using H Mac 256 here you can make sure it's hard-coded that any token comes in you use the same algorithm you try to validate it but that may not be possible in a very real-world scenario because there be multiple algorithms that our authorization server or the application server may support the token issuer may support so in that case one of the okk

the next best approach could be to have a whitelist of all these algorithms that the server supports and make sure that you are validating against just one of those and you do not accept none or something that is inherently cryptographically weak so these are some of the approaches these are like the two approaches that could be taken and the other thing of course is to choose the right library since we have libraries we have these protocols we have this technologies that do most of the heavy lifting I feel like we should leverage some of it JWT dot IO is a good website to go to they have like for each of your tech stack based on your tech stack and

based on the library you're planning to adopt you could make sure to go through that to see what does it support what doesn't it handle that way even when you're implementing it you're aware that hey this doesn't check phone an algorithm so maybe I should implement this check myself or leverage something that already exists here so I think that holds true for any any application per se I mean any technology per se that use the right library and identify so with the respect to jots it's good to look for the none algorithm and go about verifying it now we've checked in an algorithm we are doing great with the validation we are making sure that we

check for the right algorithms what else could go wrong so let's see here okay we are talking about a cool company then ok this is a cool company by the way and the attacker is Joe the Jew has Joe has access only to the mail server we have a token is sure out there so Joe submits his credentials and he's like hey this is great I am Joe which is right he's not an attacker yet and he gets this token from a token issuer and give provides it to the mail service itself the main service validates we have checked for the none algorithm we have checked for the right algorithms it's all cryptographically strong making all

this assumption here it services to Jo with whatever request he does out there no she wants to make more money he wants to attack the finance service all he does is submits the stock win it is a valid token because even the financial service utilizes the same common authorization server so he could just replay this token itself and provide it to finance now if finance doesn't have the check if the client application in this case doesn't have the check of validating if this user actually has access to this service then again it fails as a syndication mechanism the user can bypass the authentication it is a valid token but the user does not have authorization so it's not enough if you

have controls just to validate it but validating with context of what we are using this for is something that's important some of the mitigations that could be used is short RFC provides you with a predefined claim called wad which is not short form for audience so you could use that to explicitly say that hey this user we need to make use of the JSON payload I mean that's why we move to charge so something you could use that for is to have this audience parameter and have like this user has access only to database you can also use the issuer to make sure that hey this users or anyone who accesses when an service might have

a different issue so to make sure that you are looking for the cool company sure and this database itself you could make use of both of these components but audience I think has a higher hold in this case for a mitigation from a mitigation standpoint obviously you could have some extra checks round scope as well because just checking for audience may mean that this person has write access or just read access and you may need to have more of that and you could again move this to the chart itself to handle all of this because you know that if it gets tampered you have a way to identify so this could be one of the mitigations

for this and now that we've handled all of these validation scopes and all of that how do you handle a logout scenario so tokens are short-lived that's great but we don't have a cache of all of these circles like we have the session identifiers so if you're using the session this to establish session if a token has a 4r for example for the sake of conversation it has a four-hour window there then it is still valid even if as a user I log in and log out how do you handle that now one way if I mean the ideal way of handling this right now is to have like you could use the JT I claim which is

nothing but unique identifier and simple words on every JSON token you maintain a back-end copy of the saying hey this is identifier and every time I use the logs out you can go put it into a revocation this and all your client applications can actually would have to use it to write because the token is still valid because it's not expired so in this case you would have to maintain state and you do lose it not being stateless anymore because you have to maintain a state to handle these revocations itself so you'd have to have a list of valid invalid identifiers and make sure even your client applications have this it's not even of just

authorization server hazard especially in the case of an asymmetric algorithm case scenario where you have the public key so that is something that is to be taken care of definitely if you wanna handle sessions this is one of the most common issues we've seen in a lot of places so this is something I feel is a key call-out anytime anyone comes to you and says hey we want to use jots to I do to manage sessions also having of course a short TTL always helps but again it comes between usability and security so if we have to make those compromises then it's better to have this in place so that way we have things controlled

pretty much most of it also it is quite challenging with actually I mean revoking for a particular device or a particular user as such because again that would add more on your back-end to be controlled so that's to do with revocation now we have handled revocation but there it would come to key management at some point there are two scenarios one could be a breach scenario where you have a key on your authorization server or the token issuer that got leaked how do you go about rotating it if you rotate all the keys itself it's a global logout and all the charts would become but one way of approaching it could be again using one of the things that jars

RFC itself provides which is a key identification claim which could be used to mock like let's say you use a particular you use a bunch of keys it's usually like a bunch of keys at every authorization server uses so you could identify which key was the one that was compromised and just rotated for that particular key in case of a server compromise and I think it's an accepted thing that if you force a change in any signing Keys then every chart would be invalid so these are some of the hassles that come along with using charts while there are great set of advantages these are some things to keep in mind and to be handled when you are implementing or

using chart so what are the key takeaways here one is definitely validate your algorithm claim are there in the header make sure to look for what you're using and make sure not to allow any cryptography insecure algorithms and the other part is to validate all claims make use of what is there in the are see instead of like creating your own because that needs to be wet it again so this is something that could do the heavy lifting for like revocation or like key management and I don't find the audience managing to make sure that you don't have authorization bypass also I couldn't tell this enough please handle avocation carefully we are also trying to identify everywhere this Java like

let's talk about revocation and then go back to all the nitty-gritty details because this is something where most applications have been doing a great job so I think this is something that definitely requires a huge call-out and something to look for maybe when next time you're looking at an application so next we're going to talk about what the we are do you want to take the stage hello everyone doing good so far this is the half point awesome okay so next we are moving on to open authentication or open authorization I'm just gonna call it or what so okay a brief primer on what exactly is what it has three entities it has the client which could

be a device it could be a user it could be something acting on behalf of the user which is sending a request to access any resource from a resource corner the third entity which is the authorization server verifies the client and forwards the verification information to the resource server so the way the handshake works is client says hey man I want to access something from the resource server and then the client meanwhile parallely can initiate hey man can you please provide me something to authenticate myself with the authorization server so that I can forward the same to the resource owner so then they can give me back the resource same way in the background the

resource owner has a list of is this client okay to access this particular resource are the set of clients okay to access this particular resource and the way that is handled in both the authorization server and the resource server is between them it changes according to implementation but usually they make sure that they have a whitelist a client either at runtime or statically they can access the resource that's the OAuth primer moving on oh yeah sorry so there are three kinds of tokens here so there is access token there is a refresh token and then there is authorization code which I'm still going to group it under the token so authorization code is nothing but it's

like a binding token or a code that is given to the client during the registration time so this is like a one-time setup that happens between the client and the authorization server and then in return they are given a client ID and a client secret and an authorization code now depending on the implementation a subset of these secrets might be held on with the client and some might be some or all of them will be held on with the authorization server depending on what level of confidential information both of them want to hold on to but the other two which are frequently seen in traffic are the access tokens which are the short-lived tokens which are being sent with every

resource request or with every other every other special kind of request that goes to the authorization server the other one which you have is the Refresh token which is the long-lived token if you run out of access tokens or if you run out of say your initial login expiry or whatever session that you have maintained between the client and the authorization server that's when the client pulls up the Refresh token and he like hey I got this refresh token when I registered with you I want to get a new set of access tokens that I can supply so these are the three kinds of tokens to reiterate access token refresh token now irrespective of whatever token that

you got as long as you have the token with you like as long as the client has this token you are in you get to access the resource you get to communicate with the authorization server and if there are multiple services on the backend that are going to use the same token to communicate you get access to all of them however how do you know that that token belongs to that particular client so it works in a trusted end-to-end system where you can guarantee best practices were followed in every entity that was involved in that particular workflow but I'm pretty sure we all know how like how much of a chance that is of course in Utopia but in reality it may

be lost it may be stolen it may be intercepted proxied what is it relate or altered I was pretty stoked to see there were so many verbs used to what can happen with the token and all of these have been seen in publicly disclosed reports so yeah what do you do to prevent this and I'm using the word prevent here very loosely because this is a mitigation effort it doesn't remove the risk completely so what can you do you serve the tokens over TLS and you have short EDL's and again what is shot five minutes will be shot a minute will be shot some people might think six pawns a shot some people have thought one year a

shot so what exactly does it mean by short aerials so why so you understand that having transport like over using TLS or having short adityas is definitely not enough so what do you do doesn't my name so this has been getting a lot of traction so what it does does in very simple terms is you already have the token you already have the infrastructure that is set up for the client and the authorization server and the resource owner to communicate with tokens this is not disturbing that this is just adding on to something that is inherently generated and known by the client and also mutually shared with the authorization server so what happens is the client generates a keeper and this

is somehow doing of the negotiation calls the authorization is also aware of so with every subsequent call that goes out there is something there is a certificate or there is a key that is sent along with the token that binds the client to the secret that they are sending over to the authorization server so the client-server negotiation that happens in token binding is both of them agree on a couple of metadata that is going to be shared between them one of them is the token binding ID this is basically another UUID that is generated by the client well again depending on the implementation it could be generated by the client it could be generated by

the server but the endgame is both of them know about it and the second one is the signature scheme like what signature scheme are both of them agreeing on what is the payload signed like gonna be signed by and there are other metadata that is available for extensions and for binding type but for the purposes of this presentation we are focusing on token binding ID and signature scheme so what exactly happens like what is token binding in action so there is one like the initial like TLS call happens client hellos over hello hey man hey man and then finally both of them have like identified each other and then there is another specific call just for

initiating and securing the access token and the Refresh token traffic that's going to go on which is called the sec token binding so sec token binding is the header that is passed along every post call that is made and this payload is essentially containing the sign ich ami which is the export key parameter or export key material and this export key material is nothing but the key that the client has already made the authorization server aware of and then something like a signing message like this is the client who has been authorized to communicate with his authorization server the assumption here is that it's not easily predictable because it's still gonna be part of the

payload it's something unique between the client and the server or family of clients and server but that becomes part of the payload right now there is API support for from the observers because the web servers or the browsers are going to be handling the client calls for the client but more on browsers later so for now the servers that support this are nginx Apache and from a language point of view there is Java 8 and 10 support that is available all the developers need to do is just there are ready-made libraries available for OAuth itself and they can just end it comes with token binding support on the other hand if they want to be adventurous they can extend

whatever TLS library that they are using and if that is the case and if you are the one who is reviewing it make sure that the metadata is unique enough and whether they are using all the metadata properly because again there are things that could go wrong with that recover it yeah so basically the payload looks like the sec token binding header that is being sent from client to authorization server on the authorization server and it checks whether the payload contains whatever was already agreed upon so even if there is another client who has hijacked the token itself they do not have this binding information with the client who actually negotiated it so with every subsequent call that goes out

say either providing a refresh token providing an access token or using the access token then you basically concatenate the token binding ID or if you want to go all out you can just just just send the payload again and again but in the authorization server and what you are looking at is the binding ID like is it coming from the client who registered the binding ID with me so I briefly comment her on browser support so right now I understand that Chrome doesn't support it there is only Microsoft H that supports it so obviously this is not going to happen without the user knowing or it's not going to happen automatically without giving pain to the developer so here is

where there is something called self signed certificate mutual TLS and all of this that comes into picture sales 9 certificates are not something alien these have been existing for a long time so it's just repurposed for the OAuth so what happens here is the clients now sends a self signed certificate to the authorization server and again this there is always a negotiation call that happens so the client sends whatever information whatever certificate that belongs to them and that bounced them to what they are to the authorization server and the authorization server on their end register that obviously this is gonna add one another attack vector where there is gonna be a database entry of the binding ID and of all like major

secrets are concatenated secrets that they have with the client but I mean you need the context for subsequent workflows and in subsequent workflows what happens is the access token is then concatenated with the client certificate and then this is being sent off to the authorization server and then now they can see that the it's not it's just not the access token that is coming in it's also the certificate that identifies the client so why is PK a pixie great people are aware of pixie raise your hands okay so pixie is a proof of key x-score exchange what it basically does is whatever I explained so far just substitute your certificates and just substitute your key pair with a Corvair

file so during the negotiation call what happens is the client is gonna send like hey I have a unique code and this is how I generated it so I'm gonna give you the generated code or some form of code challenge and I'm gonna give you the TM which is the transformation method so the authorization endpoint now knows what to expect and how to derive the secret from that because it knows the transformation method now for every subsequent call the access token is appended with the code verifier so like the most fubar case would be a malicious client otherwise you need to overtake every workflow that happen with your authorization endpoint just get in the access token

doesn't work just getting the code verifier doesn't work you need to basically mirror every workflow that happens so yeah that's pixie right now it's you mostly used by mobile workflows because the limitations of storing client secrets on the device but again storing client secrets anywhere is kind of a bad idea so if you want to use pixie you might as well go for it so all like the code the token binding and pixie all of them were to do with inherent weaknesses or implementation weaknesses with token binding or with tokens now moving on to open redirect which was what showed up in three of the hacker one reports that I short so openly direct this case interested me

because of how simple it was to execute so this one was manipulated redirection URI where the redirect URI parameter so basically what happened was the authorization server didn't have a static redirection URI registered with it when the initial registration was happening and the client was basically passing a redirect URI through the refere had and what had happened was in the referent header the URI was passed with an extra percentage and that kind of screwed up the validation mechanism at the authorization server and so yeah it was one percentage mark that was sent along with the URI that was passed on to mitigate this what you can do is people not familiar with this meme the first

one is like the minimum security measure that you can take which is if you are in a position where again usability was a security we need more we need to support more clients and we need to make it secure in that way you let the burden on the client you extend your trust boundary beyond your authorization server or your resource server you include by default the client and the trust boundary if you are wondering it's a bad idea that's why I started off with that so basically you leave the client to authenticate where the token is gonna past gonna be positive so if you have a list of Lea redirect URIs then say a or come to v.com then a.com

needs to verify that b.com is legit and then forwards it to authorization server in their referent header like hey it's okay to pass the token in like the token to v.com the second best way to do this is during the registration phase the client says that hey I have a list of ten twenty hundred redirect you arise and you can whitelist all of them and I'm gonna maintain the whitelist with you and once a call comes in where you have to pass on the token please why a please check against the whitelist and then forward the token this has some issues because all developers like they need to maintain a robust whitelist and they need to make sure that like the

list like the websites are maintained with the urls are maintained and then people might complain like him and this became becoming an availability issue like we need to own both someone like within two days and we can't get to the authorization server then there are pain points to this the third part which is actually advocated in the RFC s and the best practices like any documentation that you will find is to have one static redirect URI and every token goes there and obviously this end point is going to be part of your trust boundary and you leave it up to the trust boundary to like forward to token wherever they want to so but from an authorization server

perspective they can do a string by string much like an absolute match so there is no way that within the OAuth scope the token isn't getting leaked anywhere so yeah those at least in our opinion in all the issues that we have seen so far token and redirect URI seem to be most easy to go wrong and like the best practices that could be followed to kind of prevent it moving on next to magic links so I wanted to bring up magic links because it's been like creating such a buzz lately so basically it's the authorization server or the authorization system doesn't have the burden of storing secrets and to an extent the client also now doesn't need

to store stick secrets so you know in a nutshell the workflow that happens is the client wants to log into a website the authorization server behind the website says that hey this person wants to login so rather than looking for credentials that the client could provide they generate a credential or a secret that is passed on to something known about the user now this might be a phone number or an email where a generated secret is then passed on to either an email or a phone number and then the user is expected ideally within a time frame to click on this code or to verify this code and then get back and they will be

given a login session now these are technically supposed to be short love secrets but there have been cases where they don't expire at all and this is supposed to be a secure transport but depending on the email service provider depending on the phone network provider it's basically shifting blame you assume there is security on third party like other integrations that store the secrets for you yeah like I said email and for network security dictates the risk so before the magic happens these are all the kind of things to make sure that the developers take care of in their code and this is before the magic happens so this is even before the secret is sent out to the email or the

phone a phone number so the first one is please make sure that the user like either the phone number is verified or the email is verified a lot of the times the implementation do not take that verified email or phone number so make sure you do that the next part is when you are generating the token make sure that it has high entropy and make sure that you're using something some established protocol and man I'm I have given the example of jawed here because we have talked about it so make sure that you have an issued for that there is an intended recipient and you also make sure that you're using the correct algorithm so please make sure

they are new they are not using md5 and yeah again token binding again make sure that whatever you are sending whatever secret you are sending to either a phone number or an email make sure that you track who requested it where it is being sent and where the response is coming from and for this you need to make sure either you can store the secret on it so on but you are getting the burden again anyway so you can store a part of the secret to verify that what you sent out in the request or what was what came back in the response make sure that you have that contextual binding information last but not the least make sure that

you have rate limiting enabled it's - over them when there is something generating secrets and it could be easily used for enumeration so make sure that you have a rate limit for where the request is coming from and make sure that the client like you have a legitimate number of times when a user forgets that they click the link already so yeah quit not quit not on sam'l here so we just like brought in sam'l as well because we wanted to see the issues that we saw in char and oh are we able to see something here as well so just a little bit of metadata about sam'l it's basically XML data consisting of signatures and assertions and again this

is something negotiated between the client and the authorization server and they know what's going on but in the case of sam'l there is an increased amount of metadata that goes on so you have like user ID which is the basis of author authorization and then you also give like user attributes like first name last name organization and other things that you want especially in a single sign-on scenario yeah one complaint is that it's - whoa books it's not a simple payload that you can pass in the header or you could but then it's probably going to trip up some load balancers but yeah so one security issue is again because we spoke about signatures already one of the things is

digital signature attacks one missing signatures the client and the server negotiated that here you are gone against York gonna send the signatures but then time of use time of check the authorization server doesn't check if a signature was passed along signature wrapping attacks it could be alleged signature that is being passed on MIT M somebody else decides to wrap the the payload containing the signature with their own signature and then whatever is whatever token is returned is now returned to them and then you have cloning signatures cells and assertions is super interesting because you basically send the payload which contains the key as well so the server looks to what was sent in the pail out payload to verify

this the certificate so it doesn't check with whatever it has in its own database it checks it against what was sent in the pillow this is happy so yeah and the other one which is the XML passing issue where the data that is being sent is again like I said negotiated the authorization server knows what the client is going to send or at least the format of what its gonna send this is a really cool way of gaming the format where the legit text here expected is the admin at example.com but then the way that it is split is there is a text fake if you see the right hand side and then at the

bottom you have admin dot exact admin at example.com now what the server sees it doesn't have enough context to even parse that XML data that it's gonna see text fake and then reject it but then it's gonna come down and read text admin at example.com and it's gonna allow it but overall what it gives the token to is fake admin at example.com so again there is context that is getting mixed missed between the services that are communicating with each other again like authorization bypass so yeah that was sam'l and in conclusion what we saw was across chart caught sam'l and password lists we have seen different developers implement different protocols but then it's the new protocol and it's again the

same problems that we are seeing when we are in a position to advise developers or work with developers to have the secure implemented of authentication we see that we can we continually advise them on how you manage token metadata properly have you chosen the right algorithm are you sure that the server is doing validation at either each and every point is it doing validation across the right data and finally there is missing context in all of them so there is always security entities that are involved in the protocol but then it's never bound to like what entity we are verify so in conclusion there are many ways to authenticate equal or more ways to implement authentication

incorrectly and we did this presentation to understand if we could come up with secure practices across authentication protocols not just context based that they can take care of if they are going to be implementing something so empowering developers Jiali implement authentication is definitely important so questions [Applause]