Insecurity protocols: an overview of modern authentication

hi everyone please give a round of applause to our next speaker Eric Chang thank you all for participating uh in uh this presentation on insecurity protocols and overview of more authentication so if you have any questions please put them in the slider all you have to do is either access the C code that was outside of the theater or you can go besides besid sf.org Q&A and put your questions there especially the support group out front so let's get started all right you can hear me yeah cool uh and yeah there are way too many slides in this deck for questions so if you do have questions just find me at the bar after this talk

and I'm happy to complain to you in person um yeah so yeah welcome to the talk insecurity protocols an overview of modern authentication I'm Eric uh I work at Google I work on things that aren't really related to authentication but uh you know have in the past done stuff like device credal uh device identity um I maintain a lot of really random open source projects so if you see me on the internet say hi I promise and apologize if I've been mean to you over there um and then in the past I've done things like I was the co-lead for the O special interest group in kubernetes so we'll say that I'm qualified to give this talk

um so today's talk is just kind of a whirlwind of modern authentication um and some not so modern authentication we'll get into that um so we're basically just going to go through a bunch of these protocols and you know things and I'm going to say witty stuff and that's basically the talk so I don't know if there's an overarching theme but hopefully that sounds interesting to uh all of you and the people in the Overflow room for some reason um but hello everybody uh buckle up so just to dive into everyone's favorite um sort of authentication scheme uh Json web tokens you've probably heard of these uh and if you haven't um behold the Json web J a

JWT um jwt's are a bunch of Big Base 64d information but it uses a special B 64 that's web native um and it has basically three parts so a Json web token is three pieces of information sort of shoved together so the first part is a header uh this holds metadata about the JWT so you know what algorithm was used to sign it and so on and so forth the payload is your real meat and potatoes this has information like what is the identity that this JWT represents but people just shove random things in there so like this admin key might be a good example and then there's a signature right so the signature is just

a cryptographic signature over the first two parts so you take the first two parts you put them together and then you verify them against the signature nothing nothing too crazy um J WTS are weirdly not the specification for the signature protocol that's jws yeah just bear with us um jbts are actually a specification of what's in the payload so these are just claims like things you would expect you know who created this token what does this token represent uh when does this token expire nothing too crazy here so yeah a JWT is just a signature over some Json data like how bad could that be but if you hang out with people at bsides um

which I assume you do um you might have heard just like a general sense of security Engineers grum about how awful jts are um and you might be wondering like where does that come from and what does that mean so I think that this started about a decade ago with this one particular blog post by ozero um so this is a critical vulnerability in a few Json web token libraries I think this was like four or five so it's not even just like one or two it it was a significant portion of the ecosystem and the vulnerability that this blog post discussed was the fact that the way people were doing validation was that they were looking at the header seeing

the algorithm and then using that to verify the signature which on first you know glance might seem reasonable but at that point you're not actually you haven't verified the signature yet so you can just replace stuff in the algorithm specifically you can use this one funny value one hack to kind of get around all of these validations was just to use the nonone value and then suddenly all of these libraries would just like let you go forward right like the NV value means you don't have to verify the signature so you don't um and I think that the JWT um I don't know reputation never really recovered from this particular moment right uh which is maybe Fair um this is

pretty bad there's actually a really funny website which is how many days since the last JWT Al nunvil I think it was at like 200 or something so we're all like as an industry getting better and I'm proud of us um more recent sort of research into why jts are bad are more focused on the fact that um you know jws it's a really quick explanation and therefore they feel very accessible and people do stuff like Implement their own RSA padding uh just a reminder jwt's are still cryptography uh and you still have to treat them that way and then as I met have you know specified jwt's are part of a much broader ecosystem uh

there's JW's for you know symmetric encryption of a Jon object um there's weird things like multiple signature schemes for jwt's just throw those out if you ever SE them in the wild um and then there's like Cs and headers so there's some just wild stuff that you can do as part of this um and then the thing that somebody has probably screamed at you at some point is don't use jws for sessions um I think that this actually doesn't necessarily correspond to jwt's but is part of a broader conversation about how we want to represent sessions uh specifically should sessions be stateful or stateless a JWT is quote unquote stateless you sign a object you give it to a user they

go use it and come back um but there's not really a good way to like revoke that session right you just have to wait for it to expire or maybe you have some revocation process that sounds awful for DTS um so you know the reality is that regardless of even if jwt's don't just sign documents like you want to be able to track sessions you want to be able to um log people out for example um and I admit that I am totally guilty of this I once regrettably in the past shoved some group information into a JWT definitely don't do that um you know it turns out if you remove somebody a group you don't

want to have to wait for them to get another JWT for that to take effect for example so yeah summary you know I think that JWT is kind of get a bad R if you are ever going to use them use a robust JWT Library there's plenty of successful JWT uses in the wild we're going to go over a couple of these in the in the other slides but things like let's encrypt Acme use them and you know overall I think the main reason that people don't like jts is cuz jws are often the wrong level of abstraction jws aren't pki infrastructure they aren't like a security scheme they're just a signed document and I you know hit this

a lot at work somebody will show up to me and be like hi I want to decrypt if secret with a TPM is that secure and you're like okay like can we take a step back and talk about what you're trying to do and I feel like that's a lot of what people end up using jwt's for on to the next protocol so OA 2 you've maybe heard of this um o 2 is the like you know login with Google or login with x uh kind of thing that uh you see on the internet and just to go over all of this with you um so let's say that I run a third party server and I want to

log in somebody with oath 2 um so let's say I want to log in Tom over here so Tom comes to my server um the first thing my server does is it kicks Tom over to the identity provider that I want to log into so it just redirects them um and it redirects them with two kind of important pieces of information even though there's lots of it um it has the app right like my third party server and it has the access uh the information I'm trying to access from Tom's account so this could be something as mundane as like what is Tom's username it could also be like hi Tom I would like to

manage all of your contacts or all of your drive data uh that's a little bit more extreme but if we get the approval from Tom that this is okay to let me access all his Drive data um we will the the identity provider will redirect back to my app um and it has some information but the important thing is this code here so that code is then something that I can exchange on the back end through my app with the identity provider I provide it my client ID my secret my credentials and then I get an access token and that access token can be used to access anything that Tom has given me access to so again I can now go mess

with his Drive data um for considerations around O2 because since this is a security conference um I lost over this but there's this thing called the state uh states are funny because they're used to protect really weird attacks like there's odd things that you can do to try to trick somebody to log into as your account um and if you don't have some sort of random value that you then compare against later on the flow you can be susceptible to these type of things a really big part of o2 as well is when you don't have a server so a good example of this is a single page app like let's say you have a CDN and

you have a bunch of react um and you're serving a single page app um or if you have a native app so let's say I have an app on my phone um in those scenarios you can't protect a client secret there's no way for me to ship you an app without you know you being able to look at it unfortunately um so more recent developments in um o 2 have been using this thing called pkcs I I've heard this described as pixie so I'm just going to call it that but please tell me someone tell me if that's wrong um and the basic idea is that there's some hashing challenges but it basically allows you

to tast uh take the initial tie the initial authentication request with the off code exchange and this protects against some weird things like somebody stealing your redirect URL and getting the code um and it blocks that and what a cool outcome is is you might have heard of the implicit flow uh you don't have to worry about that anymore uh the implicit flow has been dead and for a while now and it's kind of nice because you just get to use ooth um quick reminder of ooth access tokens are still really really dangerous um this was in March of this year there was a startup that would like manage your um GitHub things or scrape it but

the account credential that it got also allowed it to like upload code to your repos um they had a breach people's code got wrecked I assume um and that's why if you're ever like in an Enterprise setting you're going to see your Enterprise um sort of administrator really restricting what kind of um Scopes particular apps can request and and this is just a funny one from way back in the day like you do have to consider the fact of what if somebody you know creates an oath client called Google Drive and has their logo be the Google Drive logo um this is you know more amusing than anything in people of lock down but if you're going to write

your own O2 provider you definitely have to consider this and and this is just like um in general about not necessarily about O2 but about all the specs we're going to talk about there's always just a ton of additional specs that exist out there um O2 we talked about pkc like that's a really wellestablished way using oath but I've never heard of Sam assertions in oath 2 um and that sounds awful um so for example you know I think the main thing you want to take away from the slide is like just because this is an RFC does not mean it's a good idea um it turns out they don't really just like let anyone write rfc's but like they

kind of do um so yeah summary of o2 it's totally ubiquitous it actually has had some really cool improvements over this like reducing the implicit flow and sticking to that kind of stuff and access code still stuck there's not really a good way of doing that cool open ID connect the one problem with oo 2 is um if I want to do basic things like get your username or your email um every freaking provider implements a different way of doing this so this is on the top left is um Facebook then we have Microsoft then we have some website called Twitter um and then finally GitHub and all of these use different URLs different paths and

like even if you're using a a centralized spec like oh2 you can't actually get people's information in a spec agnostic way you have to know what provider you're talking to so open ID connect is a way of basically avoiding all of that instead of um there being sort of explicit or or spec specific kind of ways to get certain pieces of information it defines a standard on top of o2 that allows you to get things like your email or your password or not password um your profile name um so this includes a standard set of Scopes to EST standard response fields and some Discovery information so when you go through an oath dance uh with open ID

connect enabled uh you'll as part of your token response you'll get this thing um and if you were paying attention earlier on the slide you might know what the ID token is right it's a JWT so that JWT has different information depending on what Scopes you've requested so the open ID scope is the thing that basically says I'm using open ID um open ID connect excuse me um and it'll give you like a unique identifier for the user in the claims of that JWT that You' even passed profile gets you the name preferred username picture and lots of other things and then the email scope gets you email and if the email is verified or not I don't

know why you would ever not have an verified email but whatever and then just as a a nice uh improve you know like quality of life Improvement open ID connect has a discovery mechanism that you can give at one URL and then you can get all the other information about that provider um open ID connect I think while it is a good spec agnostic way there are some weird nuances with different providers um so this is a blog post by truffle security who I think is has a few talks here today but um what they identified is that for Google there's actually some weird edge cases where you can create non-gmail Accounts at like the

food.com with a food.com email um that actually does not imply that you are part of the food.com organization and if you were to like get the email Lop off the front bit and do the that um you might actually allowing people to access your resources that are not um part of your organization and what this kind of implicitly means is that even though oo open ID connect is like this sort of agnostic thing there are really annoying subtleties where you do have to actually end up being provider specific also when you just give people jwt's they happen to use them which is another annoying part about jws so people happen to use the JWT that's

returned outside of all of the ooth flows as authentication mechanisms so data bricks uh Hashi Vault kubernetes these all will accept ID tokens as part of um authentication and you know in the O in the open ID connect and O flow you're using TLS so you don't actually technically need to verify the JWT here you absolutely do and that's when it gets nuanced and and weird um there's things like providers that run multiple issues on the same uh infrastructure there you have to consider the fact that you want to allow some uh client IDs but not others and then people start getting clever with this kind of stuff where they like allow you to request client

IDs on behalf of other ones so this is definitely something to watch out for so yeah open ID connect summary it's a standard op o 2 there are still IDP specific nuances um and yeah you will see people just throwing ID tokens around totally outside of the scope of you know getting the user's email and now my favorite Sable so I think um jwt's like saml you know or saml like jwt's I think get a lot of flak from the internet but um I don't feel that saml gets enough so um I'm gonna basically go through a few slides about why I hate samle okay so saml has a lot of different like ways in which you can um

sort of they're called bindings the way that you can use it but we're just going to uh focus on the ooth like bindings so it's a really similar setup I have a third partyy server I would like to authenticate a user through an identity provider um you happen to use a post rather than a redirect but it's the same sort of thing right I want to log this person in rather than a threel flow though Sam will just immediately post some information back to you so this is a saml response that gets posted back to you so you kind of just have to accept post requests from random places on the internet and it includes a signed XML

document with assertions describing information about the user and other fields describing information about who signed it so you're like okay I have to validate a sample signature how hard could that be uh this is a SLE signature this is a lot but I think the first thing I will call out is that the signature is inside the signed object which doesn't makees sense okay um so the way that you would validate this document is you would pull out the signature run XML canonicalization on the object you're trying to validate and then validate it on this the signature okay unfortunately XML canonicalization is super complicated this is an example from the spec and if you read it closely

you'll notice it's reading a file called world. txt from disk and embedding it in the XML document and I'm not saying that every like XML parsel will do this but this is the kind of stuff when you're trying to implement things and read through a spec you have to know like wait does anyone actually do that um so there's tons of weird ways in which XML canonicalization is complicated XML name spaces are like insane um uh you know the it's not as bad it's not just simply like oh this is an element and this is its Nam space because Nam spaces are inherited you can Alias Nam spaces there are default Nam spaces that are implicit

U attributes can have Nam spaces and Sam will absolutely uses all of this so you have to be aware of it and then finally for some reason you can like not just sign the entire response you're allowed to sign sub portions of the document so you can get a samle response that is not signed but it is totally valid because specific assertions are individually signed which again is insane so trying to just like be a little bit subjective um every SLE implementation I've ever worked with has had an off bypass which like that's not okay right um if you will notice I am on this list right above a CVSs 10 so yeah I you know we'll we'll kind of conclude

this talk or this uh this particular session where it was I think in general summary um I really like this quote which is that you know s is by far the worst common uh commonly used industry cryptographic protocol um again I am kind of surprised that we just like put saml and oo 2 kind of like in the same categories when one is like clearly just completely insane and the other one is I think quite reasonable okay pallet cleanser we're going to do PH2 so um I've used security keys for a long time like 8 or 10 years or something like that and I think anyone who else uses security Keys you'll you'll probably have the general sense

that okay it's a second factor and there's probably some cryptography going on underneath so FAL 2 is two primary protocols webo n which is the JavaScript API that browsers use to talk to your security key and ctap 2 which is the way that your browser communicates with your security key um there are two phases as opposed to you know some crazy number of apis so there's just hey I would like to register this key and then I would later on like to authenticate so this is the registration phase uh there is a challenge in here this is mostly used to avoid replay attacks so this key doesn't actually sign it but effectively what it gets back from here

is it's just a public key and it has an ID so really quite simple and then when you want to challenge that um that public key or the the security key you give it an actual challenge to sign as well as the ID of the key that you previously got from the last step so hi you know I have this key registered on me on your account please sign this Challenge and if it signs it back you're all good um and then under the hood ctap 2 is using this thing called uh get assertion ctap 2 is not I think a general signing like um API you can't use it for example to drive like a TLS

handshake or something like that um it signs a structure that includes information about that um there's actually some fun hacks in op SSH that allow you to use that when negotiating a protocol and that's how SSH security key works and and a really cool interesting part about that credential ID is that for a majority of security keys this is actually encrypted blob that includes your private key so when you try to register a new key um the security key will generate a public private key it will encrypt the private part with a you know a per device encryption key and then hand it over and what's really cool about that is that your security key

actually doesn't need to hold any state so you have these cool applied cryptography mechanisms where you have a security key that only has maybe one or two keys on it but it can scale to allow you to log into a basically unlimited number of websites so yeah I think pH 2 easily one of the best examples of actual modern authentication and you can reason about the PH2 protocol right you can read the spec and it's not like super crazy um so yeah I think it's probably one of my favorite uses of Applied cryptography uh and now we're going to talk about pass keys so pass keys uh basically like a product manager took a bong hit and was like What if we took

these security Hardware keys but put them in software and that's a pass key so a pass key instead of being tied to a um a physical hardware token that is plugged into your laptop it is this ephemeral thing that effectively can be S uh synced between devices so instead of you know it being this one thing here you know it's on my phone it's on my laptop and it's just all kind of magical pass keys are intended as second rather than as a second factor to replace the first Factor so pass keys are used as passwords rather than as addition to your password right it is effectively like a password that you can't see um it

uses the exact same protocol um but some there are some nuances here namely um when your pass when your browser wants to challenge a pass key it does not provide the client ID so instead you get this nice quar of user experience on your side or instead of saying like please touch this security key that might be on other device your browser pops up a dialogue that says hi someone would like to have a you know challenge your pass key here's a set of passwords or pass keys that we have registered for this domain you know what do you want to do unfortunately um pass keys or security Keys turn out to make really bad pass keys and this sort of um I

would say in a way that surprised me at least when I was doing research for this so first off security keys are hard because like like I'm I have like five or six security keys right and whenever I get a new one I back it up for you know the few accounts that I really use security keys for but this just doesn't really work if I am using them to store my passwords right like I'm going to be over there oh wait was it that security key that had the thing and then and just in like a really big like um architectural issue remember how I kind of talked about the how the client ID

stores and allows the security key to be state removing that means that the security key has to store that information so it's this thing called a resident key and basically um for stuff like Ubbi Keys you a lot of the generations only allowed you to store 24 Keys which is like absolutely unacceptable and what's even crazier is that many of those don't provide management interfaces for that so as soon as you hit 24 you're out of pass Keys also like pass keys are great but there are like really practical things that are annoying so for example I have a Macbook um and I want Chrome to store this in a way that syncs to my Android

phone and it turns out there's not really a way because Chrome happens to use iCloud keychain which can't back up to this so practically like it's just really hard to get something that magically syncs between devices when you know your phone won't talk to your laptop so yeah um there are luckily flows that do this but I was quite of annoyed with this particular thing on the left um because like three of these options basically mean either store it in a cloud provider I don't use or store it locally so you can never recover it and you know I think for me like pasy is like I'm a a relative expert in this kind of stuff and even I find this ux

really confusing sometimes so yeah um pasky they're actually just a very small tweak on top of phto 2 but it comes with huge user experience changes and I think we can all agree like the interoperability issues are really blocker if you don't happen to be part of one ecosystem I have five minutes so this is going to be fun um so I I would love to talk a lot more about Hardware off and have other examples but we're going to have to use the trusted platform module as sort of our standin for all the other ones so trusted platform modules provide a few capabilities and when I talk about trusted platform modules you might think

of this as like you know what Hardware off in general tries to provide so you can link keys to devices you can chump to test the state of a particular device so this would be you know what did this operating system did this boot with what were the secure boot Keys um and then Additionally you can guard Secrets uh based on that state um these are all the commands from the TPM 2.0 spec um so again four minutes there's no way I'm actually going to give you a complete overview of how TPMS work but generally um TPMS can store keys so um TPMS have many different kinds of keys and these have different roles and

responsibilities some might be used to sign assertions about the TPM some might be used to encrypt or decrypt um and some might be used by applications but the core thing is as soon as you can prove that one key is on a TPM all it can attest to the fact that any other ones are so if you know that a key is on the TPM you can then create other keys that are provably also bound to that TPM and backed in hardware and then it also has mechanisms for tracking state so TPMS have these rolling hashes called pcrs um and then another thing that's outside of the p uh TPM called a boot uh the event log the event log has a set of

boot events again this might be the hash of yourit ramfs or the um you know the actual secure boot certificates that were used to validate uh your operating system um and then if you want to add a new event you append it to the event log and then you roll the TPM hash forward and there's no way to go back and then later on what you can do is you can challenge the TPM and say hey know you have that key please sign the current state of your pcrs you grab that you gra grab that SS station you can then replay the event log and verify okay what I'm looking at is actually the state of my

uh device and you can do that remotely there are lots of ways that this can go wrong um I uh you know had some fun with some co-workers once who wrote some code and I was like wait um you're relying on a field that isn't part of that digest so again TP are very complicated it's hard to do this stuff if you ever do like feel like looking at the event Log please reach out to me because um there are actually very few vendors that seem to do this and we have a lot of experience of like trying to get the value of particular pcrs from vendors and just not really seeing it for example but yeah to reach out so

yeah TPMS are incredibly complex I say I'm at 2 minutes there's no way we're going to explain it all but I think you know in general this kind of Hardware attestation is incredibly common pace so you might be able to do things like like phto has space for attestation so you can when you do a registration of a security key you can say like oh is this in the batch of security keys that my company purchased um this is also used for anti- spam measures right if you want to know that hey is this application installed on a real Android device you might not be getting the exact Primitives that the operating system is linking into but somewhere

under the hood something like this doesn't happen and then finally like is this key backed by Hardware um again security keys this kind of have these kind of attestation capabilities um and in certain environments this is absolutely required okay in summary so we just talked about you know seven six or seven kind of um authentication protocols that are widely used um you know again I joke but it's like some of this is just going to be me up here complaining um to you all the audience and I hope that was interesting but I think broadly speaking what is very very common is that things that we kind of think are similar are actually have huge differences in complexity if

you think about the PH2 API versus the tpm1 or open ID connect between saml and when you look at how complex something is it is usually a good predictor for like how many cves are going to be against it or how effectively insecure or how much is Eric going to complain against it in its next slides so I hope that was interesting um the slides are on my website and uh thank you so if you enjoyed Eric's venting please give him a second round of applause