The Secret Life of Secrets

[Applause] our next uh presenters so if you want to learn how to design uh secret keys well you're in the right place so their presentation about is going to be about the secret life of uh secrets so uh if you have any questions please ask them on a slider you SE a QR code outside of the theater or you can go besid s.org Q&A and we'll take them at the end of the presentation thank you and give another round of applause for our speakers

all right well okay so every year hundreds of thousands of people take the wrong medication and some researcher out there looked at that problem and asked how can we use package design to increase medication accuracy so these reers these researchers conducted a study and participants were asked to look at some drug and its packaging and determine whether or not something had the same active in inent so here we see uh package designs for allergy medication note the changes in branding active design and dosage so comparing A and B how much more accurate do you think uh medication take uh active ingredient identifying do you think package B is compared to package a with these changes please raise your

hand if you think it's 10% all right 20% okay and what about 50% Co cool yeah so with these changes the confusion errors were reduced by 2/3 and to dive a little deeper there are two groups being studied there was a younger group and an older group the younger group started at 41% and that dropped to 8% with these changes the older group started at 68% and it dropped to 16% so with some really simple design changes researchers were able to get some pretty notable improvements to decreasing human error and while we're talking about uh medication and whatnot let's talk about how we can use design to better patient outcomes I was talking to my sister and

she is a Psychiatry resident she said that medication adherence is really a huge issue for all patients but especially psychiatric patients um they might think that oh I feel good so I don't really need to take this anyway or their brain tells them that it's a giant conspiracy but um she was saying that uh the big thing in hospitals now is you treat patients that are on antiy otics uh you used to treat them with like daily oral pills and now it's moving to Long acting injectables and the care is designed to be a monthly thing rather than a daily thing so it's so much more convenient and it's way easier to remember and having them come

in for the appointment it's really good to like keep tabs on them the patients can ask any of those offthe cuff things that they might not remember if they meet less often and it has led to much better health outcomes there is an article in nature on the real world effectiveness of long acting in incbles for patients with schizophrenia Spectrum disorders and like the mean number and duration of psychiatric hospitalizations really declined with this change in their patient care and design uh one more anecdote on how user experience and design can have a dramatic impact on the real world uh a few years ago I met the founder of code for America is anybody familiar with

code for America few hands going up um they're nonprofit that do Civic related things and she basically made this argument to me and the room full of people at the time that if you take all of Charity within the United States you add every single dollar up going to every charity across all the United States that's the number you get it's a little bit less than 5 billion dollar for all of Charity um if you compare that to the US welfare system it's not even close like by far if you're trying to get money to people in need there's way more money in the US welfare system to do that than every charity added up

combined so her pitch to the room was basically if we can get one designer one person to make the U the US welfare system a little bit easier to sign up because most people that are eligible for welfare don't take advantage of it it's hard to get through all the paperwork and the user experience isn't great if we could just make it 10% easier that one individual designer can give back more to people in need than all of Charity combined okay so the talks about AP I Keys um what what are we doing talking about all these other things I think the bottom line is user experience in ux can have a dramatic influence on whatever it

is we're talking about if we're talking about API Keys though um it means the way you design your API keys can fundamentally lead them leaking out less or leaking out more or other security implications which we'll get into based on how you design those keys um so my name's Dylan I'm a is there

audio um they asked if we uh wanted to use audio in our talk and we' never done that before we thought it would be fun so we tried to mix in a little bit but um my name Dylan I'm the uh uh security researcher I I started a company called truffle Security based on a popular open source tool that I authored a few years ago um I've spoken at a bunch of large conferences like um deathcon and black hat hi I'm Han um I work in the intersection of software security and ux and I've previously spoke at conferences like besides SF and black hat Arsenal um cool so yeah at at a 10,000 foot view we're not going to go into

what uh truffle security the company we work at does but we spend a lot of time doing open- Source work um on secrets in particular um we're built on top of the open source tool truffle hog which finds Secrets leaked out so that's just to say we've put a lot of thought and Care into this particular space and and that's why we we wanted to talk about it so um let's say you're designing a brand new API um first thing one might do is Google how to design a brand new API um you'll get a whole bunch of documentation explaining how the number one search result is from Postman and it's got a whole bunch of uh different

considerations for the nouns to use and how Json should respond status codes the word security does not show up on the entire page um and uh you know like that's that's kind of interesting for some of the ones where security does show up it's mostly talking about um what you can do within the API ro-based access controls idor those types of things um nowhere could we find a comprehensive guide talking about how to design the keys for your API right it's such a critical piece of security security is usually left out um but you know we we thought just because we spend all day looking at Keys um we could spend a little bit of time just

specifically talking about the way keys are designed and how it can have security outcomes so um what about the keys is the long story short um we're not talking about what the keys can do um so it's not talking about um uh what kind of access you'll get with the keys but specifically we're talking about the user experience of the keys themselves the way they're shaped and textured and how that can have an influence on security all right so why does this matter is is that it are we just talking about shapes and textures today yes that is it uh so why does this matter design influences behavior and I think it's worth examining any Behavior

no matter how big or small if it leads to better and more secure outcomes um if you're interested in more in hearing more about ux practices and security I'm speaking tomorrow again at 11: all right so the form factor of keys so what if we put a square peg in the hole the wrong shape and texture for secrets well if you've worked at a large tech company before and you haven't really and you haven't really seen how decisions get made without security around we're going to pull back the curtain on that a little bit and shed some light on how certain decisions might have happened based on our experiences at these companies so we are

doing a fictitious reenactment of a design choice that resulted in tons of Secrets leaking out so sometime long long ago in an office far far away where in the office of catchat somewhere where all the cool kitty cats gather hey everybody uh I am a product manager here at catchat uh catchat is the company that is designed to make cats collaborate easier with one another we're going to change the world one cat at a time and uh basically we've got this new idea for a feature that we believe can dramatically improve move our API adoption long story short cats don't like our API but they do like URLs we did some intense user research and we

found that cats really like to engage with URLs they click on them they share them and not a lot of cats are using our API uh API keys are scary um so we thought what if we could combine these two things and get more API adoption if we have URLs to transact with those apis introducing the cat chat web

hook hey Cat this is dog from security team this is my first time hearing all this and I have a lot of concerns and a lot of questions but like just to start you said this interacts with apis what exactly does this do with apis yeah no I love that question love the security team great to have you here dog uh so look long story short um with one of these cat chat web hook URLs cats uh will be able to take one of these web hook URLs and send arbitrary messages to a Channel with whatever username they want uh whatever message body they they want uh whatever profile picture they want and they'll be able to upload

arbitrary file attachments to that message cat this sounds like an API key I really don't think Secrets should go in URLs it's basically a whole new paradigm for interaction URLs are often logged they're cash they're shared and people already are used to interacting with URLs in a really specific way way and there's even a whole a whole cwe around sensitive query strings in URLs um so when people see an API key they they know how to handle it they don't share it they don't take pictures of it and they don't log it everywhere but url's I'm not so sure gosh can I just take a moment to say how important Security is to us here

at catchat I I hear you there um tell you what what I heard the most there is that it's an issue to have sensitive data end up in the logs so why don't we spend a little bit of extra time making sure that none of these sensitive catchat web hooks end up in any of our your our logs is that uh does that sound like it'll solve the problem no that's just one of the concerns what about our users these look like URLs and what if they handle them insecurely okay okay that's that's fair um well tell you what what if in our official documentation we say don't handle these insecurely oh my god dude no one reads

our docks what if other companies copy this design as well our logs are fine but like what about their logs yeah I I mean look so I I remember earlier when I said that uh cat chat is changing the world and everything but we're we're a relatively small company All Things Considered I I really don't think we have to worry about a whole bunch of large companies like copying our API key design patterns here I don't know this is bad for the security industry like people are used to interacting with tech in a very particular way why are we changing that all right I don't worry I've dealt with security a whole bunch of times

I've got a plan for this tell you what dog I love the collaboration here why don't we take a lot of these concerns that you have and put them in a document and we'll address them offline how's that

sound that's it all right so do you think this feature was Revisited [Music]

well we cat chat never tackled those concerns and the features were shipped exactly as described for the PM they're right people love URLs and catchat took off but for that security professional their worst nightmare came true what catchat did with keys and URLs became somewhat of a design pattern and companies like slack Microsoft teams Discord they all use that pattern now by the way it's just a fun fact um that uh feature is is called a web hook now those companies all call them web hooks so I thought it would be fun to actually reach out to the person who originally invented the term web hook his name's Jeff he's just a guy it turns

out and I asked Jeff I was like hey do you think this fits the definition of the way you intended the word web hook to mean and he was like no these are web hooks like they're basically just uh API Keys um I don't know why they called them web hooks they don't fit the traditional definition of the word um but as a consequence of the way these keys are shaped the way they're shaped like URLs um we recently went and scraped a whole bunch of websites looking for API Keys there's the breakdown if you ignore cloud from this graph the number one common most leaked out SAS key are these web hook URLs and

that makes sense they look like URLs they don't look like API keys and it just tends to them leaking out way way way more often than every other type of API key out there um so API keys or uh web hook URLs were first introduced in around 20 uh 2015 Jeff the guy that invented the term web hook he also floated the idea that maybe these more closely fit the definition of capability URLs capability URLs are basically a URL that can do stateful things usually not a good practice by the way because of something called csrf um but uh there are some use cases where it's unavoidable like password reset URLs um the thing is

capability URLs are all initiated by a user and these web hook URLs are initiated by services and are used to transact with an API so we didn't think capability URLs really fit the definition either these are effectively just uh API Keys um they're API keys that look like URLs and and that's kind of what led to them leaking out U more than any other key out there is our our general hypothesis around those yeah so catchat sure did a lot of damage but um stepping back for a second have you ever heard of the rule change your passwords once a month well that rule hails back to the day of non- networked main frames and all the concerns about

cracking them and getting access uh some there was some napkin math happening back then and it was like how long would it take to run all possible passwords get into the main frame uh was roughly several months so changing your password once a month was meant to prevent that brute forcing cracking attempt and that became policy and that was the best practice for that situation um a non- network Mainframe in a in a Department of Defense environment but Tech doesn't really work like that anymore and that design pattern was passed down for a really long time without necessarily examining why um now the advice on changing passwords once a month is dying out and that's actually kind of great uh

so before recklessly copying patterns you see in the wild it's really important to examine how and why it is a pattern in the first place and if it even makes sense to implement as well uh we've been talking about an interaction pattern that accidentally became the norm well what if we have the inverse a bunch of companies coming together to create a standard pattern of interaction

all right so you're creating a large distributed system you want things fast you have multiple Services talking to each other and you want to minimize transaction time between them well we have jots here yay jots jots solve all that it centralized creation it decentralizes checking and it provides minimal database transactions they use cryptography to solve all those problems for large distributed systems focused on scale sounds great right we love crypto Ry having crypto solve all our problems so what is a jot uh to kind of break down the structure and the shape and the texture uh we have a header a payload and a signature the header is the specification for the signature uh the payload is a set of claimes and the

signature validates the entire thing um are most people familiar with jots by the way by show hands most hands going up um a common misconception about jots they are not base 64 uncoded there are a special encoding called URL safe base 64 encoding um which just begs the question like when it comes to design in ux why did they go out of the way to make them URL safe like we don't want these things in server logs we don't want them leaking all out over the place um but they were designed to be URL safe it just kind of comes back to base principles of ux um if you make them URL safe it's going to lead to them ending

up in you else

all right so also let's take a closer look at the structure so um in the first block you see there's a algorithm specification and depending on the spe selected algorithm um it's either the jot is either uh symmetric or asymmetric so either a signature or a cryptographic hmac um kind of interesting we see none there that's a really interesting decision and even more interesting is where's the expiration well you probably know that you can't really revoke a jot easily yeah um sorry so um the expiration is an optional field so you can include it in the header um if you don't have an expiration they can't be revoked um if you do have an expiration

um then you just have to wait for it to expire the alternative is you have a database you check but the whole point of the JWT was to cut the database out um so that's why usually they just don't expire or or they can't be revoked or you have to wait for them to expire um if there is an expiration so yeah uh let's focus on the weak symmetric keys if you use a weak symmetric key um yeah are people familiar with uh This research here for cracking jwt's with weak symmetric keys not many hands going up so basically long story short is a a symmetric key in the context of a JWT is often just a password um it

doesn't have to be like you can generate a long secure string um but developers will often just use a password um and the thing about passwords is we have very rich libraries and dictionaries of passwords um and so if you have a JWT that generates a signature and you test every single password against that JWT to see if it matches the signature um when you use passwords to sign jwt's that leads to people being able to guess the passwords and you can do all that cracking offline because you have the JWT um so there's some research there if you want to look into it of what that looks like to crack it if you guess the

password correctly you can then manufacture as many jws as you want with any claims that you want you could pretend to be any user you could set whatever expiration date you want it's bad right um so we decided to take a look um and see how common that actually is so we went to Showdown and for all the symmetric key jws that are returned to you as soon as you hit the website um we downloaded every single one of those it was a few thousand we downloaded off Showdown um and we tried to load them off up into hashcat see how many of them we could guess that password [Music] for so um the long story short is a lot

like um we were able to guess the password for over 2% of them um and it wasn't the most sophisticated password cracking setup out there which is wild because these are production Keys these are the ones on the internet already these aren't pre-production but these are sitting on the edge um 2% of them we could guess that symmetric key and then we could use that symmetric key to then manufacture as many jws as we want with whatever claims we want um and so I I think this is the tricky part when we're recommending something like a common spec or a protocol if we know the 2% of developers that implement it are going to do the wrong thing are going to pick

a weak symmetric key that we can crack doesn't make sense to recommend it that's a huge number all right and that's not not the only issue so we hinted at it earlier but in the Alor the algorithm options uh the word none is there and that's built into the spec and it allows for cre the creation of a jot without cryptography and all the libraries initially supported it because it was literally in the spec um so in the in the libraries like if a developer does not specify an algorithm type the the libraries are just kind of let it through because it none and that's valid so um libraries treated none algorithms as like a valid token

with like a verified signature uh because the developer does not specify and that seems like a bit of a ux oversight because it's like what's the safe default here and we allow the unsafe defa the default to then be unsafe uh there's a lot of interesting bypasses around jots now um about how to use nun to kind of take over the jot yeah take over the jot and there's a lot of best practices a lot of them are around none um so look long story short here are two uh one-off examples of issues that you have when you introduce the cryptography of jwt's but the list is a lot longer like we don't have time to go

through them all we just picked two of the fun ones there's a long list of considerations that you now have to worry about with jwt's all of which are cryptographic in nature um if you're curious about the full list the latest spec for JWT is actually lists them all they're up on the screen here um but this I mean this makes sense like when you introduce cryptography you have cryptographic issues that are a consequence of that and this is just a lot to put on a developer to have to have them understand how all these different cryptographic issues can play into the way they're implementing jwt's and we know from experience from surveying the internet um that some

non-negligible percentage developers are going to mess these things up if you recommend um the standard as a whole um so I I think that kind of goes back to some of the base principles here um when it comes to symmetric keys in jwt's if you recommend symmetric Keys 2% of people are going to mess them up so does it make sense to recommend them I think that's the question um does it make sense to have um sort of this opportunity to mess up um when you maybe could just take that away like if you're only recommending asymmetric Keys there's no opportunity to mess up the symmetric key component as an example of that um so so uh as as another fun fact

I reached out to the person one of the original 10 people who were cited in the first JWT spec um as an author of jwt's this is the father of jwt's I guess um and I asked him a bunch of questions one of the questions was just hey um like how do you think about this like if if you teach developers to do this thing and some percentage of them do the wrong thing um is the answer evangelism education like how do you fix this and he was basically well it's a Fool's error to trust them like no matter what you teach them like it's a Fool's and to have to count on them alone you need you

need additional Security checks and controls in place and that's just a lot to have to worry about if you're recommending the spec and you know the developers are going to mess them up and the author of The JWT is is saying the developers are going to mess them up now you need this whole tail end of checking um and and controls to to account for that all right so when using jots just really stop step back and decide is this the right tool for your toolbx is this another change your path password every 1 month kind of situation do you have a distributed systems problem that needs cryptography what exactly are the benefits given that uh revocation hard

uh there's crypto problems Etc it's really great if the goal yeah so if so basically just like go with the simple flow uh don't introduce other Errors By going with like what's necessarily popular and what's um what everyone else is doing just like think and keep things simple uh and that's not to say there's anything wrong with jwt's it's just it's one tool in the toolbx that should be used for particular problems so if you have a distributed systems problem if you're avoiding database transactions great makes sense if you're going to hit the database every time anyway or if you have a low enough volume of user transactions where it doesn't matter um maybe it's not the right tool for the

job and maybe the risks it brings in aren't worth the benefits um the next one that I'm going to touch on I think we're running short on time so I'll probably have to skip at least one pattern here um but this is a design pattern where you bring your own API key to the table the one that probably Pops to mind for most people is GitHub where you can upload your own um private key to GitHub and use that to transact with github's API um they do that through SSH private Keys you can use it to both read and write code to GitHub um by uploading your SSH key to the platform another maybe lesser known example is Oracle

Cloud same deal you can upload a key to Oracle cloud and use that to transact with the API um technically Google allows you to do this too but it's not the default the default is will make a key for you um but you can override that um with Oracle you're always uploading your own with GitHub you're always uploading your own um well the problem is if you're uploading your own then you have opportunities to mess up your own key Generation Um so I tried to upload an insecure key to GitHub and what happens um I uploaded a key so small I knew I could Factor it so 512 bit key um and GitHub rejects it it's like we

recommend at least 2048 bits um which isn't factorable today um the largest key that I could see factored to date um was $139 I'm not a cryptographer by the way if people know that I'm wrong about some of these numbers feel free to come see me after this is from the wikkipedia page for factoring these Keys a a 1039 bit integer was was factored um so I said okay what if we split the difference like they said upload 2048 and they won't let me do 512 what if I upload something in the middle there um with 1024 I literally had chat GPT make the key for me um and then I uploaded it to GitHub um does anyone

want to gu that's what happened like on the last slide it said make sure it's 2048 uh the long story short is it let me upload it um so that's weird right like that they know that you're not supposed to do it but they let you do it anyway and then that of course led to the next question of um how often are people uploading keys that are small enough in theory they could be factored I I so just for context we downloaded every single s public key off of the platform from every single user and we analyze them all um over 11,000 of them are small enough they can be factored and then we looked at what

repos they were pushing to and they're pushing to some pretty big named repos like I'm not going to name them here but like just trust us like if you could take over those keys you'd be able to push code to some pretty sensitive repos out there um so you know it's just something to think about that um when it comes to uh allowing users to pick their own Keys If you give them the autonomy to do something in some percentage of them are going to do something insecure um that's a log based graph before anybody uh chews me out for that um it's a little bit uh just biased in that way but just as a heads up there

and then the other thing we looked at um which is another fun thing is for all the sh Keys we downloaded how many of them are reused between accounts which you never want to have happen right you want to generate your own Keys you want them to be unique per key how many of those keys were reused between accounts we're running short on time but long story short if you let users do insecure things they're going to do insecure things and here's some fun examples of that um where we just found students ripping random private keys from random places and using it as their SSH key thinking that it would be a secure thing but you know it's not and like it's easy

to check too you could just take these private keys and test them against GitHub see if you can ssh in um if you give users the autonomy to do something bad some percentage of them are going to do something bad yeah so leaving all the bells and whistles to your users uh sure but like bring your own key pushes the security completely on your end user and there are novice and prob people in the field so yay to control and all but what about the guard rails what are the consequences of not H having them and what do we gain exactly by letting users control all this we're running super short on time so we're just going to cut right through

um mtls as a design pattern but the long story short is um with mtls you have uh oops uh oh um long story short um if you use mtls you have the revocation issue that we talked about previously you have the ReUse issue and you have cryptographic configuration options issues so if you introduce cryptography into your system you're going to have cryptography problems um and if you give uh users the ability to have um insecure keys if they have that user experience some of them are going to take that flow um so um I we want to kind of end things with a quote from a famous person um we thought this was a really good quote make things

uh as simple as possible possible but not simpler um Albert Einstein authored this quote um or so we thought actually what happened was we took our talk and we fed it into chat gbt we asked it for a quote that best fit our talk and it gave us a bunch of examples uh and as it turns out Einstein did not write this

quote we thought it was a good quote though all righty so we complained a lot and that's not the most productive so we're gonna go through some recommendations super fast so one generate the security keys for your users don't let them do it two be really careful on when you introduce cryptography it solves a lot of problems but we can also cause them uh three make it easy to discover Le Keys If you find If you're looking at your log and you see a bunch of random strings like do you think that's a key initially well GitHub had a token that was like the same shape and length and texture as a Shaw one hash and a ton of keys were

looking out and it was really hard for GitHub to find it and in their secret scanner it's kind of like security by obscurity so like let's not do that so yeah has since uh prefix their keys so prefixing Keys great idea okay so where does this leave us most of the time um first of all if users have a certain expectation of what keys look like and how to handle those keys if you follow that expectation um that can lead to good outcomes what um Han just mentioned there's a ton of companies doing that pattern so basically uh a secure enough length that you're generating for your user with a fixed prefix that helps you find those

key Keys that's how AWS does it that's how GitHub does it that's how tail scale does it that's how tliia does it that's how stripe does it that's how a ton of different providers Do It um don't go Reinventing the wheel if there is a good pattern that's influencing good behavior today um and also come back to the base questions of why um providers are doing this why are they sticking a prefix in front why are they going with URL design um and sort of question some of those things and how it might influence the behaviors of your users okay so you know what does it mean like secure length and how to generate it I don't know 20 characters is like a

gajillion combination it's probably good enough right um long story short is if you generate 20 random secure characters and you have that prefix in the front and you're generating the keys for your user it will tend to those keys leaking out less than if your keys look like URLs and if you're generating for your users you don't have the opportunity for your users to mess up the key generation themselves um and also it doesn't have many risks of cryptography issues that come from the introduction of JS which sometimes you may have to use because of distributed systems but if you can avoid it um there are some benefits from avoiding it so why make it any more

complicated than that thank you all so much for coming we'll be around if you have any questions [Music]