Room 101 Sunday Mar. 08 - SCaLE 23x

This talk covers methods for cracking passwords using various tools and techniques. The speaker emphasizes the importance of strong password storage methods, such as salting, and critiques common practices like the use of MD5 hashing. He discusses tools like John the Ripper and Hashcat for CPU and GPU password cracking, respectively, highlighting the advantages of each. Several techniques are explored, including dictionary and mask attacks, and the importance of unique passwords for different accounts is stressed to mitigate the effects of data breaches. The speaker also provides insights into the vulnerabilities of Windows' password storage methods and shares statistics to illustrate common password practices among users. Ultimately, he advocates for the use of password managers and cryptographically strong passwords to ensure better security.

Can you hear him now? >> Okay. >> Can you hear me now? >> Can you hear me now? Whoa. How? This is really loud. I guess it works. Put my pocket. Jay Jay, do you have 11:42? >> Okay, we'll wait three minutes. >> Introduction. What's up? >> I'm here to >> introduce me. >> No, if you want. >> No, I don't. I'm okay. >> Are you going

to give me a fiveminute warning and stuff? >> And I check the microphone. >> Can you slide this down somehow? >> Sure. >> I can't. >> I Let's see. I don't think I can. Sorry about that. >> At least it has two ear things. >> Yeah, but this is for one ear and I have to tape it on. >> This is like for somebody with a shrunken

head. >> I know. >> Don't Don't worry about it. >> The microphone handheld works. >> There's a handheld here. >> Yeah. >> Are you going to carry this around to people? >> I'll do it. I'll question. >> Um when when it's five minutes warning, you have to come really really close. I've got reading glasses on >> and if you're like those cards I can hold up. >>

It's got to be a big card close. I will do that. I will sit right here. >> Cool. >> Is there some way to adjust this? Because this is made for somebody has a head that's like shortening head. You slide that down like um I couldn't figure out this. >> Oh, good. >> Slide it down like a long way. >> Oh, that's just sliding the other thing

>> No, that's fine. I I'll manage. Okay, cool. Thanks, guys. We're going to start in a minute. That'll be good. Okay. Okay. >> Good enough. >> Can you guys hear me? All right, I think we're going to get started. It's 11:45. This is about cracking passwords. This is about me. If you guys have any questions, and they're short questions, feel free to ask them during the event.

Otherwise, you get to ask them afterwards. So, there's basically three different ways you can crack passwords. You can use a CPU and John the Ripper is the best tool that I found for that. It's open source. I have links for all the open source stuff where to get it. There's hashcat which is the best tool I found for cracking GPUs. These slides are all available on the

scale website and they're all available at dyic.com but feel free to take pictures. And then there's a thing called rainbow tables which I'll get into later. Um it has some applicability but not a whole lot of what I was doing. you might wonder how passwords are stored. So plain text passwords are converted cryptographically into a hash and the hash is stored. There's many different ways of doing

that. So MD5 is a very popular way of doing things. Not a good one. I don't recommend it. But the MD5 hash of password one 123 is that whole long thing. So with modern hashing, people add what's called salt. Salt mixes in with the actual password to make it longer and harder to crack. This first came about in 1979 with Unix and they used 12 bits of

salt which gave 4,000 possibilities. The oh modern Linuxes are using 120 bits of salt. So the reason people want to have salt is if you have a password password one two three that MD5 is the hash for it. But if you add 12 bits of salt to it there's going to be 4,000 different hashes for the password 123. And it might be feasible to store that one

hash. But when you multiply that by 4,000 or in the case of modern Linux, two to the 128, it becomes a huge amount of stuff that's not feasible to store. The thing that's interesting is my favorite operating system, Microsoft Windows, does not use hashing. And because it does not use hashing, it's susceptible to rainbow table attacks. Why they don't use hashing or salting, I don't know. As

I said, it started in 1979. probably long long time ago. So there are many different ways that you can hash a password. Some of them are very good, some of them are bad, some are slow, some require a lot of resources. So with NC Land Man, that's the standard Windows hashing algorithm. You can basically get 24 million I'm sorry 24 billion hashes a second which is a

lot. If you're using brypt which is the standard way people do things on Linux you get 13,000 hashes a second which is slow. You want it to be slow because if you're typing something in and it takes one over 13,000 of a second it's going to you know be a few milliseconds to slow you down. Nobody really cares about that. But if you're a bad person like

me and you're breaking passwords, you want the hashes to be as slow as possible. So a good question is how long does a password have to be? So if it's your computer and you control the hashing algorithm, you have quite a lot of control over things. If you're using a website like Amazon, you have no idea how they're going to hash their passwords. Some websites are real

bad and they store passwords in plain text. That's super duper terrible. Some of them store the passwords with some weak encryption. Some store with strong encryption. If that website gets breached, somebody might steal all of the hashed passwords. And at that point, you might want to be changing your own password. But if they're storing things with brypt, it's probably not really feasible for people to break them.

If you're if they're storing things with uh MD5 or nand man, it probably is feasible to break things. Unfortunately, very few websites say this is how we store our passwords. And very few of them are going to tell you if your passwords get breached. So, this is why you want to have a separate password for every website that you're using because in case one gets breached, you

don't want the password used for everything to get taken. So, if you're just using lowercase passwords, you're going to need to have an additional 4.4 characters. um if you're using N Landman versus BCrypt to have equivalent security. So that's 26 to the 4.4th power will give you roughly the same password breaking speed. Does that make sense to everybody? So the thing is if you want to have

strong passwords maybe you can memorize a 20 character password. I can't. Maybe you can memorize a 100 20 character passwords that are random. I certainly can't. So, the way to solve that is use a password manager. Um, all the different browsers have password managers. They're ones that are on the web that will store your passwords. I don't trust any of them. I only trust passwords that I

store myself. The manager that I like, it's KeyPass. I'm sure there's other good ones out there. KeyPass is open source. I've got a link to it here. It's under the GPL2 license. Um, so because you can't really control how the websites will store passwords or how they will do use a password manager. I'm sure some of them are awesome. I'm sure some of them are terrible, but

finding out which one is which is very difficult. So what I like to use is 20 character cryptographically strong Most of the password managers have ways of generating these. I wrote my own Python program that would generate 20 character crypt with roughly strong passwords. The reason you want that is that I was talking to a guy earlier today. He said, "I'm using song lyrics for my password."

I said, "That's a really bad idea. Anything that you can find on the internet like in Wikipedia or lists of song lyrics people are going to use." They put in what's called password dictionaries. So these password dictionaries people use as raw input and they make permutations on that to break passwords. This is the most efficient way to break passwords. So if if you're using song lyrics, bad

idea or again anything that might be found in in anywhere online. So there's a thing called masks. If you know information about a password like you know it's eight characters long and you know the first what is it three characters or digits you can make a mask where it is basically digit digit digit and then alpha alpha alpha and this is much faster than doing a complete

brute force attack because it limits your search space. Um this this is a somewhat advanced thing and hopefully people don't know this information about your password. Maybe you you've lost your password and you're absolutely sure it's eight characters longer than the first three characters or digits. So that that's how you go about recovering your password. for a brute force pass brute force password breaking the mask is

basically a a basically means anything. So this is going to take a long long time. So with the GPU I was using which is a 3060Ti which I've since upgraded when you have just eight character uppercase lowerase and numbers. This is how many passwords you have and it'll take me 229 days to go through all of them. And you say that that that you know not such

a long time. You might have a faster GPU but when you switch to 12 characters by adding four characters you get this very very large number and it's 12 million years. So clearly if you have random passwords and you make them a little bit longer it's going to become computationally infeasible very very quickly and for 16 character passwords it's a very large number of years which probably

is more than the lifetime of the universe but again this is for completely random passwords not for passwords that are in So the dictionary attack is the very best way in terms of cracking passwords per second to get passwords. There's many many people that say they have password dictionaries out there. The best one I found is called Rocku 2021. I think it's about 30 gigabytes. There was

a previous Rocku one that was a little bit smaller. Um, so using Rocku, I was able to get 10 to 50% of the passwords just using the dictionary, nothing else. So if if you're trying to break passwords, the passwords I was trying to break, I had 1.2 billion of them. If you can get half of them, that's an awful lot of passwords. So even if your password's

safe and your password's safe, you know, somebody else that you work with's password might not be safe and I can get into your computer and cause havoc from there. So after you've gone through all of your good dictionaries, you do what's called the rulebased attack. And with the rulebased attack, you take a dictionary and you add a rule. The rule might be add a number in the

beginning or make the first character uppercase or all kinds of different stuff. And usually people sort the rules in terms of the most effective ones first. So using a rulebased attack you can probably get up to 90% of all the passwords that you're trying to find. So this is a very very efficient way of doing things. Um this can also take a long time and a fair

amount of resources to do. But I've been doing this on this latest data set for about a year and I've got 82% of 1.26 billion passwords. So I found a billion passwords this way. So I might not find some individual's password but statistically speaking I got quite a lot So the tools to use the primary one is John the ripper. The advantage is it works on Windows

it works on Linux. It has relatively infrequent official releases but very very rapid unofficial releases. Um it has very very good support for making custom rules and it has very very good online support. Hashcat until recently I was using the version from 2022 in August 2025 they came up with a newer release. Uh it has very very good GPU acceleration. GPUs are more efficient than p than

CPUs at breaking passwords but you have to buy GPUs which are kind of expensive. the rule syntax is much less sophisticated. So I made my own rule to add control characters to passwords. So imagine you want to add a control character to the first position in a password. So with John the Ripper, it's like a two or three line thing that will do that for each position

in the word list. For Hashcat, you have to have one rule that says insert a control A at the first position. Insert a control B at the first position. So you're going to have like 26 rules just to insert a character at the first position. Then if you have 10 different places you're going to be inserting, you're going to have to do another 10 times that. So

you're going to have to have 260 lines of inserting control characters into a word list. So the rule syntax is very primitive. They say that their system is so fast they can't have more sophisticated rules. Maybe that's true, but I'd rather have one or two lines to do my insertions than 260 lines. The other thing is I made another rule that did replacement. So instead of inserting

a character, replace the first character. So that was again another like two lines with John the Ripper, but with Hascat it be hundreds and hundreds of lines. So the word lists, most most of them are full of junk. Um, I've I've grabbed maybe 50 or 60 of these things. Some of them have long lines. By long lines, I mean hundreds of thousands of characters long. Some of

them have not asky characters. Um, some of them don't even have new lines. So, if you get one of these things, you're edit it and massage it to make into useful rules. Most passwords are like under 100 characters. So, a line of, you know, 100,000 characters is not going to help you when you're cracking passwords. So the standard tools to manipulate these word lists there's GNU sort

GNU sort that that's the standard sort on Linux can sort files that actually are bigger than will fit in memory. So if you've got 32 gig of RAM but you've got 100 gig dictionary it's going to sort it it's going to take a long time. There's unique which will remove duplicates in a sorted list. There's comm which you can use to find things that are duplicates between

two different word lists or things that are unique between two different word lists. And there's my favorite editor, Emacs. Emacs kinetic gigabyte files. It has regular expressions. It's my tool of choice for actually looking at these things. In addition to the standard word list tools, there's tools that I wrote. I wrote a program called short which will truncate long lines and will give you things in this

particular usage only shorter than 40 characters. So if it's got 50 characters it prints the first 40 and throws away the last 10. Uh I wrote a thing called msort which is my inmemory sorter. I wrote it long before GNU sort existed. I wrote a program called ASKI lines which will filter out and remove stuff seven bit ASI. Um, I wrote a program multimemerge that can merge

together multiple sorted files. Uh, I have a thing called sample which you can just look at like in this instance every 10,000th line it'll print out just to give you an idea what's in the file. I have a program called file length which will give you statistics on the lengths of characters in a file. I have count which will show the frequency count of the characters which

I'll show you later on. Um, I wrote a program called password stats which I'll show you the results. It gives you statistics about passwords and there's password unhex. The cracking tools when I find something that's not asky printable, we'll say like dollar hex and give some hexadimal values. But when I want to use statistics on control characters, you want to actually have those non-printable values in there.

So this is all open source. I wrote it all most of this in Python and C. Whoops. So relative hashing speed um nand man it's the fastest standard thing out there's MD5 which is at 24 billion hashes a second that this is on a specific CPU so it might scale up or down depending on how fast your CPU but relative CPU speed is is very accurate. There's

deescrypt which is what Unix used in the mid 80s which is as you can see 40 times slower than nandman which is again what Microsoft is using today. So there's scrypt which is a pretty popular hash there's WPA2 which is what most Wi-Fi systems use and there's brypt which is the Unix standard hashing algorithm. So you definitely want to pick a slow hashing algorithm if you want

to keep your password secure if you have control over your stuff. Why Windows is using something that's so fast to hash and doesn't have salt? I don't know. You can ask them. So the salt thing again 1979 it was invented in the 1980s. Unix went to 48 bits which is a pretty good number. 96 or so brypt and argon he came up with 128 bits of salt.

So there's 3.4 * 10 38. That's a big number. So if you have one password, password 1 2 3 and you want to encrypt it with all the salt, you're going to end up with 3.4 * 10 38 hashes, which is not feasible to store. That's more than the storage that you have unless you're, you know, Facebook or Amazon or something. So land man, which is a

predecessor to nand man and land and nand men don't use salt. Bad on Microsoft. good for me breaking their passwords. So, here's some statistics on a billion passwords that I've broken. So, this is the length of the password. So, if you look at things, basically between eight and 10 characters is the length of most of passwords. These are the ones I found. Maybe there's some that are

longer, but like for 30 characters plus, I only found 11,000 passwords. So, not a lot of really long passwords. If you're trying to break passwords though, you want to know the statistics on what people are using. And and this is pretty good statistics. Some people use one character passwords, but if you look at 20 character password, which is the length I use, there's only 2.3 million of

those that I found. So more statistics. This is the characters of people we were using. All lowercase is 16%. uh lowercase and digits is 41%. So if you don't know anything about the passwords, you should probably start dealing with the lower and digit passwords. How else you're going to get 41% of them that way? That's a good thing. Um there's other stuff. Control characters is 0.1% 8bit

ASKI, that's where the most significant bit is turned on somewhere in the string is a tenth of a percent. Um there's all these different classes and this all came out of the password statistics program that I wrote. So now we come to string classes. All alpha means all letters upper or lower case 19%. Then we have letters followed by numbers. That's 35%. So when people are putting

numbers they're usually sticking them at the end statistically speaking. Then we have numbers and letters. That's 6.6%. And you see the other stuff there. So breaking down the alpha and number stuff further. So this is alpha and then one character that's 12%. The sweet spot is alpha then followed by four digits. That's 25% of the passwords. So, if you're trying to break things and you're using a

password mask, you probably want to start off with a bunch of letters followed by four digits. If you look down at 10 digits, that's like, you know, 1.2%. So, again, this is just statistics, but it's pretty good statistics. And this is on 380 password of the form letters and numbers. So, but it's a pretty good sample size. Now, I get to my fun one. control characters. None

of the standard rules deal with control characters. None of the standard character sets include control characters. Started with my own. So line feeds, that's tab, got eight of them. Um I'm sorry, line line feeds, it's part of the charact life feed. Horizontal tab got 140,000 of those. Character turns got 23,000 of those. Delete characters got 4,000 of those. So when I was breaking DSC passwords, I got

most of the password. I was down to a couple of them. And I said, I know these things are eight characters or less. I've tried all the standard characters, so it's got to have some control characters in them. And sure enough, I found two passwords that had some control characters in them. But I wanted to break every single password I had, which is 1500 DS crypt passwords.

So I wrote these rules. So, how do you defend against this? First rule, don't use NT landman. That means don't use Microsoft standard password encryption. Two-factor authentication is the best way to deal with this. Um, it basically is what you have, which is some physical device. And I guess you have to include what you have, what you know, and what you are. So what you are are

things like fingerprints um and face ID the Apple picture taking stuff. So Google has a Titan security key. It's a very good security thing. They were giving them away for a while. I think they sell them for a few bucks. Their little USBC thing. Uh Ubi has a very good two-factor authentication thing. Smart cards extremely good two-factor authentication. People sending you text messages on your phone. That's

two-factor authentication. that's incredibly weak. It's possible to spoof SMS messages. It's possible to steal them off the air. So, it is two factor authentication, but compared to these hardware two-factor authentication or fingerprints or face ID, it's really, really weak. So, use cryptographically strong passwords. I'm going to say that again. Don't use things that are online in dictionaries, and Wikipedia, anything like that. Um, so use a good

password manager. There's keypass, one pass, bit warden. There's probably other good ones out there. If it's open source, you can look at the source code. You can have some assurance that it's good. If it's a closed source program, you have to trust the vendor. Are they good? Are they bad? Who knows? If they're online, you have to trust the infrastructure that the website has is perfect. And

I'm not a very trusting guy. So my password generator, this is just a random example that I gave. It generates these 20 character cryptographic strong password. I'm not using them for anything. And it shows number of bits of entropy of each of these. If you can memorize these things, more power to you. I can't memorize these things. But no password cracker is going to find these passwords.

These are going to be proof against anything but an extremely determined nation state trying to break your passwords. So let's get into advanced cracking stuff. So, I'm cracking 1.297 billion passwords. The dump came from a website called Have I Been Poned? These are all stored using NT Land Man, which is good for me because it's the weakest encryption scheme. The bad news is there's 1.297 billion. I'm

going to say 1.3 billion. So, to break these, you need to take a big data approach and you're going to need to have lots of RAM. So, my computer start off 128 gigabytes of RAM. It works, but I upgraded to 256 gigabytes. If I was extremely rich, I'd upgrade it to 512 or a g a terabyte of RAM. But the current RAM apocalypse, that's like stupidly expensive.

So, this is using John the Ripper. Having more memory means I can run more threads in parallel. Right now, I can only run 14 threads in parallel because I'm limited by my RAM. If I had twice as much RAM, I could run it twice as fast. Um, so far I found 83.1% of the passwords, which is pretty good. I'm still running a password cracker on my CPU

and I have a GPU which is also cracking passwords, but it gets slow after you've done this for a while. It just that that's the nature of password cracking. The easy passwords quickly, the hard ones come slower. So, rainbow tables does not work well with salt. The good news is it's fast. The good news is it works with Landman, NT Land Man, and MD5. Defcon has the

data duplication village and you give them six terabyte hard drives and they fill them up with these rainbow tables for you. You could download them off the internet, but these things are pretty big. Um, so here's a website free rainbowtables.com and there's there's more stuff for that. So the problem with this, this is really good if you want to break one or two passwords, but if you

are breaking lots of password doesn't work so well. So I tried it with rainbow crack. Uh I downloaded 43 gigabytes of rainbow tables. That's for lowercase alpha and spaces and um I couldn't get it working. So I sent in a bug report September 24. Haven't heard back. So the other problem is that it uses 16 kilobytes per hash and when I had all my hashes 960 million

hashes needed 150,000 gigabytes of RAM which obviously is more than anybody's going to have. So I started to use our crack i mt that means multi-threaded. Um this is this is open source. I don't have a link for it, sorry. But its table for lowercase alpha and spaces for nine characters was only 35 gigabytes. So it took six seconds per file and there was 84 files. So

it took me 504 seconds for one hash. That's using a SATA SSD. Maybe you have a faster SSD, so it would only be 50 seconds, but doing one hash in 50 seconds is not really good. So 900 million it would take me 16,000 years. Again if I had one 10 times faster it would be 1600 years. That's still a long time and that will only get you

the lower alpha in space nine character passwords. So if you have one or two passwords and you're using anti-land men it's a great way to do business. If you have a billion passwords not going to work. So hashcat hashcat is the CPUbased I'm sorry GPUbased password cracker. So, it turns out if you're trying to use its rules, you're going to run out of RAM. I had 16

megabytes, I'm sorry, gigabytes of RAM on the computer. And um I basically figured out I'd need and that that took 667 megabytes. So, for 936 million passwords, I need 624 gigabytes of RAM to run it, which is a lot of RAM. Um, so I didn't use the rules of hashcat. Instead, I used the brute force attack, the mask attack. So I was doing this on roughly 200

million passwords. And with my 8 gigabytes of graphics memory, VRAM, I ran out of memory. It somewhere between 120 and 150 megabytes, it runs out of memory. So the solution is buy a card with 16 gigabytes of RAM. So, I bought an Nvidia 5060Ti and it was able to run all 233 million hashes at the same time. It's also 45% faster than my old uh GPU, which

is very nice. So, 8 character uppercase lowercase numbers takes nine days, which isn't that long. It It's, you know, medium speed. It would be faster if I wasn't cracking so many passwords. When you're cracking 960 million passwords, it slows it down substantially. So John the Ripper that's I use it for CPUbased attacks. So they have standard um and you can start and they have the default dictionary

built in. So using the default dictionary using the default rules basically um I was able to get quite a lot of passwords. So it was 30 gigabytes of memory per fork. So when I had 120 gigabytes, I could only run four forks. After I increased that, I could run more forks. So I upgraded my computer from 120 gig to 256 gig. That was when memory was cheap.

I think it was $200 to get to upgrade my memory. So that was a good deal. Um, so using the standard rules in the standard dictionary, I found 487 million passwords in 12 days. This is the power of a rulebased attack and a good and a good default dictionary in John the Ripper. So this is the most efficient way to do things. This is what you should

start off doing initially for breaking um using their default dictionary and rules in time I found 154 million passwords. That was really cool. They have an incremental attack which is their brute force sort of attack but it starts off with the best guesses first. I found 325 million passwords. So I used the Rocku dictionary which I mentioned earlier found another 156 million passwords. Um then I got

more memory and I could double the amount of forks I was using. So using that I found 50 million more passwords in a couple of days. Um so one of the things you can do is you can apply these rules twice. So the first rule might be uppercase the first character. The second rule might be append four digits at the end or something of that nature. Um

so I started eventually I got to where I could have eight forks with the rocku stuff. I found 256 million passwords that way. That that's a good chunk. That was like a fifth of all the passwords. So when eventually I could crank the number of forks up to 18 and I found still more passwords. This this thing gets slower and slower with time. So they they optimize

the rules to have the best rules first. Um so you can also do brute force attacks with John the Ripper. It's probably not as good as using a CPU, I'm sorry, a GPU, but if your GPU is busy doing other stuff, you can still find passwords that way. So I found a total of 811 million passwords with a dictionary based attack. That that's quite a lot of

so then I started to apply the rules. So when you found passwords when you found 800 million passwords, you can use your found passwords as a dictionary. So I'm sorry, as a as a word list. So the thing is some of these word lists are good, some of these are bad. the ones you found are the best possible quality dictionaries. So, it's like using a feedback loop.

And since it's such a good source of passwords, you can find more passwords that way. Um, so here's the control character stuff. I don't expect people to memorize this stuff. This this is the command line I used that would do um replace a control character. That's overstrike. and the other one was insertion of a control character. So using these things I found 8 million I'm not sure

7.9 I found the pass I found 8 million passwords pretty quickly. Um so these are the actual rule rules used. You see where it says optimized that one line will do an over strike in of any position one position one position two position three until the last position and the second rule which is on the last line is the insertion of a password I don't understand the

syntax the guy that told me this is a guy named Solar Designer who's a Linux kernel security researcher who is the main developer for John the Ripper but he gave me the rules the rules work so with hash hashcat. I was only using it for the brute force attack because the rulebased attacks was running me out of CPU RAM. Um, so I was able to get lowerase,

uppercase numbers and special special things like tilda, amperand, things that aren't numbers or letters. So length of seven I could do in 3.7 days. Length of eight I could do in 10 days. Um, and these these just show how long these things take to run. But like for lower in number length of 10, 180 days, this this clearly shows that making your password longer is going to

make it very difficult to do a brute force attack on. these things obviously scale with your GPU, but this was the GPU I was using. And that's the last slide. You have questions? A lot of questions. >> Hi. Uh, I know you talked about how you do not trust password managers. >> Speak up a little bit. >> Oh, hi. Uh, I heard about how you do not

trust uh, password managers. >> Yes. But I would like to get your recommendation on the top password managers you do not recommend and maybe >> password managers that are what >> that you do not recommend and why >> I I don't have specific ones but if if it's on a website I just don't trust it. I mean why why use something on a website when you can

have your own? You know you can run these things on phones. you can run >> What? >> I I just don't trust something if it's a company run thing. I mean, if it it's easy to do yourself. There's open source ones you can write your own. Why Why trust something you don't have to trust? I just see no advantage in it. So, I'm not going to unrecommend

anybody. I'm just going to say have have an open source one, have it run locally. Next question. Um any thoughts on uh passwords that are essentially made in LET? >> So there are specific rules that that do lead that turn you know L's into ones or turn E's into threes and things like that. So if you take some standard word like password and you replace the O

with a zero, it's not going to be really secure. So, I I I really recommend cryptographically strong passwords, things that are not in dictionaries, things that nobody else knows. >> I don't know if there's dictionaries for leak, but there's definitely rules for leak transformations. And and there probably dictionaries for the stuff, too. There there's a trade-off in dictionaries between how many words you have that are like

words and how many permutations of words. So, if you have the word password, you can append one to the end of it. You could pen two to the end. You could pen three to the end of it. So if you do that 10,000 times, you're going to get a long list of things. Is that an efficient way of storing a dictionary? Probably not. You probably run a

rule, stick a couple digits the end of the word. So the same thing with elite stuff. If you can think of a transformation to make it elite, there's probably a rule for that. >> So um if I have let's say keypass installed locally, >> yes. Um, how do I synchronize my password database across various computers that I'm using in my >> I I haven't done that, but

I would guess you just copy the encrypted file from computer to computer. There there's a master password. You type in your master password and there's an encrypted database of files. If you copy the encrypted database to your phone and to computer one and computer two and computer 3, it's all secure and without the master password, it's useless. So that's my best guess. I don't know because I

haven't done it. Uh so I would like to uh ask your thoughts on u the trade-off between uh passwords that you know are cryptographically strong and uh passwords that you know you can remember because I have run into circumstances where there are passwords that I need to remember on the spot perfectly every time. There's no option for an SSH key. there's no option for uh two factor

off uh like on university networks for example you are given a you are given a chance to create a password and that is your way into the university network and you have nothing else uh what do you recommend for choosing a right password that you can remember every single time >> so I've had similar situations like that and what I do is I have a base password

that is really really random and I've memorized and what I do is I add a bunch of characters to the end of it and I write down the characters I'm adding. So if my password is password and I want to add four characters to the end of it, I'm going to write down ABCDE or ABCD. And so I know my root password which is secure and I

just append the ABCD and that's going to be the password I use when I have to have a password of that form. It's probably not the best thing to do, but it's what I do. And and unless you know my super secret strong password, you're not going to get it. >> Right. Uh for the gentleman who asked about synchronization, uh Next Cloud is great for that sort

of thing. It's open source. They have a booth here. You can just ask them. >> Cool. U now um a sort of historical question. and I came to possess an old silicon graphics machine that was a time capsule and it was stuck in 2007 I believe was the last time it was used. >> And it used the latest OS that was available at the time, the latest

irrix. They had taken all the security precautions. The root password was 10 characters long which was sufficient for 2007. >> Sure. And um it used exclusively random characters and uh punctuation. John the Ripper cracked it in five minutes with a brute force attack. >> So it was probably some permutation of a dictionary. But this this is why something that was secure 20 25 years ago is not

secure anymore. But John John the Ripper is totally >> Yeah. So, I just have a PSA because I noticed you talked about the uh for physical pass key, the security keys, the Titan key. >> So, I have a Titan key. I broke it and there's no real like support for it from Google. Um, so just FYI, if you are in the market to get a security key,

um, >> they've abandoned it. >> I there's no real recourse for getting like any sort of support for it if you break something like that. like there's a little button on it and it will wear out and um yeah, >> I didn't know that. So, I I'd suggest Ubique or some other hardware, you know, second form of authentication has better >> That That's too bad because I

thought the type was pretty awesome, but I I don't have one. I I had one. I gave it to a friend of mine. >> Hi. Hello. >> Yes. So you mentioned trying to stay away from passwords that are on websites. Yeah. So how do you get around the randomness? How do you how do you generate you said you wrote your own password generator. What do you do

for entropy to create truly random secure cryptographically secure passwords? >> So P Python has two random number generators. One's like the standard one and one is the cryptographically secure one. So, I use Python's cryptographically secure random number >> How do you know that's but but I I don't know. So, I trust it. But if if you don't trust it, the the password managers will have ways that

they claim will be cryptographically secure. If if you're really really worried, you know, the only thing that's really provably secure is something like decaying radioactive particles in a radiation counter. And and if you're the NSA, it's probably what you use to generate your randomness. But anything done on a computer is not going to be as secure as a physical process such as radioactive decay. But I I

trust that the Python people are making cryptographic secure random number generators and and they're good enough for my use case. Um for the first part, uh for the person that was curious about the Titan um the Titan support for things like that, usually the way you uh prevent stuff like that from happening is you just get a bundle of two and register them both to the website

that you're using. >> That way if you lose one, you have another one and you can still get in. Um the question I had was uh how do you usually attack um uh passwords that have been salted? >> So GES uh DS crypt has 12 bit salted passwords and I broke a bunch of those. So you simply don't use rainbow tables. So I was breaking 1500 GS

passwords and each for each password I would generate uh I I had word list and I would do do encryption with that particular salt to see if it matched. But John the Ripper and Hashcat are great for doing that. It's just the rainbow table stuff fails when you have salted passwords. So so any civilized passwords are going to be But it it's still quite doable. You just

can't have stored pre-enrypted tables of >> Hi. So, uh just to add something to the person who was wondering about the security of cryptographically secure random number generators in Python. um they rely on well okay that you can get an actual USB key that actually um injects randomness by decay of radioactive material. Um some places like Cloudflare use uh randomness you know by measuring changes in lava

lamps and you know calculating that in video. >> The sun guys started that they they really did. They started a rack of lava lamps. >> It sounds crazy but it's true. A a lot of it really depends on just um the noise in your system and being being able to have um you know hard hardware noise happening. But anyway um what do you say to people uh

who say that uh the password doesn't matter because two-factor authentication handles my security? >> So there have been breaches where people have been able to bypass two-factor authentication. it it has happened. And so I would never just use like password one, two, three because I have a two-factor authentication. Um it just it it's a bad idea. So there aren't a lot of bypasses for two factor authentication.

They do exist and and you still want to have secure passwords. I mean, not having that is like having kicked me on the back of your shirt. It's just not a good idea. >> Okay. So, for the folks who are having the issue with a broken two-factor authentication key, uh recommending at least adding another one andor doing a soft token. So, if you lose your keys or

something else, that's an easy way to fix it. I would love to see pictures of your rig. >> Of my rig? >> Yes. Of your password cracking rig. It >> It's not very cool. So, so the one with the GPU is just a little, you know, standard size ATX case with a 5060 Ti in it. and my main computer. It's a Anttech P280 case. I've got a

server grade motherboard, so I could put in up to two terabytes of RAM if I had incredibly deep pockets. I'm I'm always looking for donations from Red Hat or anybody else. Um, but it's just it's just a epic. Uh, it's a third generation with 64 cores, but I I use server grade equipment because it's cheap and I can get lots of RAM. Can I have one more?

What do I tell my partner who does the following thing? Uh, she just types in random things as the password, >> never remembers any password and when she has to log in, she just goes and reset my password on the website. >> That that that problem is beyond my abilities. That that's that that that's your problem, not my problem. Sorry. >> Thank you. Any more questions? It's

not a technical problem. >> Okay. Um Oh, is there one more? >> Hi. Yeah. I want to know your thoughts on the implications of quantum computing and how that affects the security of >> So that that's a really good question. Um at the unclassified level, I don't think anybody really knows and at the classified level I have no information on this stuff. I think eventually quantum computers

are going to be a real thing and they're eventually be able to break standard passwords very very quickly. I think that's probably going to be 20 years off. I could be wrong and if I am then it's going to be a problem. There are quantum resistant algorithms and and some people like in the DoD are migrating the quantum resistant algorithms and they're probably going to come up

with quantum resistant algorithms for password hashing and hopefully before the quantum computers are a thing people have migrated from BCrypt and argon on Linux and other things to something that's cryptographically I'm sorry that's quantum resistance. That that's that's my best guess though. I think the people that know can't talk. >> Any more questions? Thank you very much for AND >> BRILLIANT. >> Thank you very much. >>

Who I don't know put these things up Another question. >> So that's a good question. So no idea how to turn this off. All right. Yeah. Pinch hitting pinch hitting for Pedro Borbone. Manny Ma. >> Yep. I think it's good if audience is this. All right. The laptop works. The microphone's on. The room's not empty. We're We're in good shape. This is Hey, there it is. All

right. And I think we're ready. All right. So, uh, welcome everyone. Um, glad you could make it. This is the last round of talks before the closing keynote. Um, so I'm just going to try and get you really psyched up for that. Um, this is actually the first talk I've ever given that started out as me making a dumb joke about Pirates of the Caribbean. Um, it

is also, I realized after watching Mark Rousinovich's keynote this morning, probably the only talk in the history of software supply chain talks that doesn't use the famous Nebraska diagram from the XKCD comic. Um, there are probably people outside waiting to throw me in uh, supply chain jail for not using that, but I apologize. Um, so like I said, you know, this started with me just making a

dumb joke. If you've seen Pirates of the Caribbean, you get it. If not, there's a scene in the movie uh where one of the pirates says, "You better start believing in ghost stories." And he steps into the the spooky light and all of a sudden his flesh disappears and he says, "Because you're in one." Um and I I had this idea when I started thinking about um

you know the I'm not a supplier uh argument that comes up a lot in uh from open source maintainers talking about the software supply chain and I am very sympathetic to that and I hope that reflects in this talk. Um, but my motivation here was really, okay, you're not a supplier and you may not have chosen to be a part of of somebody's software supply chain, but

you are. And there are things that are going to happen because of that. Companies are going to come to you and say, "Hey, um, I've got all this homework you need to fill out. Please do that because you're my supplier." Um, people are going to start looking at you like, "Why don't you have this security feature enabled? Why aren't you doing this? Why aren't you doing that?

And as an open source maintainer, you do have the freedom to tell them to pound sand. Um, and at the end, we'll cover some other options you can say, but you know, just because a billion-doll corporation is using your project, that doesn't mean other people aren't, too. And so, I thought it was really important um for open-source contributors and maintainers to have an understanding of why the

software supply chain matters, even if they don't want to be a part of it. Um, so we'll start off with the usual housekeeping slide blah blah blah. Um, I am wearing my company shirt, but they didn't they haven't seen my slides yet, so um, it's not on the company branding either, so you know, don't take Cusari's word as being my word. Um, they probably agree, though. Um,

I've put my social media handles up there. The lighting is not great. I'm not sure if you can read it, but you know, tag me if you think I say something great and insightful. Um, you can send all the unkind things you have to Devnull. Uh, John Green had a quote that years ago that I just I've internalized. It's in my speaker notes to say, um, nobody

can dislike me with the depth and precision that I bring to the table. Um, and then we will keep we'll have time for questions at the end if you have those. Uh, depending on how things go, I might even let you make a comment instead of a question. Okay. So, real quickly, we're going to talk about what a software supply chain is, just to make sure everyone's

on the same page. Um, talk about why open source is a little different from maybe like a vendor software supply chain. And we'll talk about some frameworks and tools to help. And then, like I said, what you can do when your downstreams come calling and saying, "Hey, I need you to do this thing for me." So, let's start out by just coming to a shared understanding of

what a software supply chain is. Um, but because we're in tech, we have taken a concept that already existed, added the word software to it, and pretended like it's a brand new thing. It's not. Supply chains have existed for millennia, right? And the idea of a supply chain is basically, you know, the inputs and efforts required to produce and deliver a product, which is very inspiring. I

know there are people who are actually legitimately thrilled about this concept. I'm not one of them, but I do appreciate the outcome. Now, you've probably gone most of your life without thinking about the supply chains in your life. And then you tried to buy toilet paper in March of 2020. And then you tried to buy, you know, anything else throughout most of 2020. Um, and it was

hard because all of a sudden, you know, they were still making toilet paper. It's just that it was stuck on a boat in a dock waiting for the people to be able to unload it and load it onto the truck and bring it to the store. And of course, the demand had shifted um pretty dramatically uh with very little time to plan for it. I don't think

anyone actually was pooping that much more than they were a week beforehand. Um, but now everyone was worried and so it affected the supply chain on the demand side. Or maybe you started thinking about supply chains a little bit later when when the boat got stuck in the Suez Canal and we all had a great laugh about that. Um, wasn't that fun? It lasted what seven or

eight days. It was a good time. Um, but it's still like it caused problems because there's a lot of stuff that goes through the Suez Canal on a daily basis and it really couldn't because there was a boat in the way. Um, a little more recently, you know, gas prices have gone up quite a bit lately. Uh, because it turns out like 20% of the world's oil

goes through a little tiny stretch of water that is uh not a safe place to be right now. So, you know, supply chains are real. They affect things. that cause problems. Okay, great. What about software? It's different, right? Yeah, kind of. Um, it still has the inputs and the efforts, right? So, you have dependencies. You have the code that you're sitting at the keyboard writing yourself or

you're asking your AI agent to write for you. You've got the tooling, you know, compilers, frameworks, your operating system, like all these things kind of come into a supply chain. Um, and then you got the efforts, right? You got develop, you're testing your code or you're shipping it to your users and then letting them test it for you. Um, you're building it, you're deploying it, etc. So,

all these things still happen in software even though it's all mostly ones and zeros. And also the hardware supply chain does come into it too because unless you're just like thinking directly into uh your git repo um you're probably at some point touching a keyboard, clicking a mouse, looking at a monitor, things like that. That's kind of out of scope for what we're talking about today though.

Um and especially in open source though, software is people, right? It's not just you take some raw materials, shove them into the computic and then out comes software, right? there are people doing this work. And uh again, as we learned in 2020, if people are unavailable or are restricted in some sort of capacity to be able to do the work, that affects the software, the supply chain.

If people can't show up to your project, if they're too busy, that affects um you know, if they're being held hostage, if they're impersonated, whatever. They are an important factor. So modern software is uh complicated machinery, right? Um I first my first program was written in basic. Um if there were libraries available, my uncle didn't teach me about them. I just wrote silly little programs that told

you how much you weighed on other planets. Um, I took my first uh uh programming class in college was a C programming class and the most the biggest dependency I had was include standard io.h. Um, again writing silly trivial programs that were enough for me to get my meteorology degree. Nowadays, um, this is a little bit dated, but it was hard to find up-to-date information because Google

is not what it used to be. Um, but a 2020 octaverse report from GitHub found that uh the average npm package has 638 transitive dependencies. You probably don't know what those are in your project. You probably hopefully know what your transitive dependencies are because you've added them. You've done an mpm install. you've done um you know whatever in your particular language to add that library to your

application what happens when that dependencies dependencies get pulled in and then so on so it gets really big really quickly. Now, if you think about how capable you are of writing bugs in your software and you look at the people around you, and of course, you're the smartest one in the room, so everyone else is even more capable of producing bugs. That's 638 opportunities for people to

introduce bugs into your software without you doing a thing. Um, so the software supply chain kind of matters, right? So you know all of this applies in open source and in proprietary software. Uh but open source is a unique uh and special snowflake for real this time because first of all there is no like you know respon assumption of responsibility. Every software license I've ever seen pretty

much I think um let me just keep dialing back the certainty on that. Uh, but they say, you know, software is provided as is. I am bringing you a bucket full of bits. You can do whatever you want with them. I make no guarantees that they're any good at all or they're what you need or that I will fix anything in the future. It's yours now, right?

And you know, that's obviously healthy. Um, we don't want to have people who are doing volunteer developers assuming this mantle of legal risk because they decided to create a fun little fiveline library that somebody else found useful. But the the real key factor and this is where the I'm not a supplier argument comes in and it's completely right. Traditionally in software or any other sort of purchasing

you have a birect birectional relationship. your purchasing department talks to the salesperson. They both of them bring their lawyers in. There's a nice big contract. It says exactly what you're getting, when you're getting it, how you're getting it, what gets fixed, what happens if it doesn't, who's irresponsible if something breaks, all of that. And if you've ever been in a large company and you're trying to purchase

a new software, especially from a new vendor, it's like a 6 to 12 month process in a lot of times, right? So there's a lot of negotiation that goes on. everyone knows everyone on the both sides of the table. Um you've you know you remember their babies and now you're at their graduation before the contract actually gets signed. But there is a in open source. I have

no idea if you're using the the code I wrote unless you come tell me. Um there is no relationship. I've put it out there. It's on GitHub or wherever. You find it. You come get it. We never talk to each other. Um, that's sort of the unfortunate case because, you know, ideally you come back and you say, "Hey, Ben, um, this is not this not good. Can

you you fix this part?" Or, "Hey, this is not good. I fixed it for you." Or, you know, you're like, "Hey, thanks for doing this." Um, that doesn't happen all that often, right? And depending on how you distribute the software, you know, if it goes through uh a Linux distribution um then you know you might know that that distribution has a package but you might not know

if anyone in the distribution is using it. Um I'm a Fedora contributor. I've maintained some packages for many years. I really we have no way of telling how if this package is used at all. Right. And that is a feature from a privacy standpoint. It is a bug from a let's know what's going on here standpoint. So again, you're putting the software out there. Somebody's using it

for whatever purpose. You don't know about it. You don't owe them anything. You never agreed to anything. And honestly, like there's a aspect of I thought this was supposed to be fun, right? People get into open source for a lot of reasons and not everyone does it because they enjoy it. Um, but hopefully even if you're doing it for other reasons, it brings you some amount of

joy. Um, but when somebody's coming to you and saying, "My big company needs you to fix this thing or needs you to provide this information or just needs you to spend two hours filling out this form." That's not fun. And it adds up over time. It adds to maintainer toil. people just don't want to do it anymore. And again, I get that 100%. So, there's reasons people

are coming to do that, and it's not just because they like making work for you. In fact, it's probably never that. Um, but your downstream companies, and I'm I'm really talking about like the enterprise downstreams here, um, they care because governments tell them to care. You may have heard of the Cyber Resilience Act in Europe. um that is adding a lot of new uh supply chain responsibility

to companies that provide a product with a digital element which is the term of art there. Um CRA is very complicated. I am not an expert. I'm not going to try and explain it but just know that a lot of companies that incorporate open source software now have some responsibility for handling that securely for their customers. Uh in the US there was an executive order um that

has been superseded by uh an OM memorandum. Um very thrilling titles. Um but it basically you know if you want to sell to the government, you probably ought to be following along with those. Um and then medical device manufacturers have recent um updates to the food drugs and cosmetics act which pro um requires increased supply chain Medical devices are literally life or death. That's one of the

few times when we as software people can like literally have that significant impact on people's lives. If your web browser crashes, it's annoying. Whatever. if your insulin pump crashes, someone could die. Um, and so the FDA is starting to take a really serious look at like, all right, we got to make sure the software that goes into these devices is uh secure and well-maintained. So, if you're

producing software that ends up in a medical device, again, you might not know it until they come saying, "Hey, we need this information for you to meet FDA compliance. So, this is all that was all important to companies who are making bajillions of dollars and whatever. Um, but if you're not working for or owning shares of those companies, why do you care? And honestly, maybe you shouldn't,

right? Again, software is provided as is. You've made no promises. You are under no obligation. You can do this as you see fit. you've put your bucket of bits out there. Um, if people use your software in a way that you don't want them to or you think is a bad idea, they're allowed to do that. But that becomes a them problem. but you probably should. And

I'm going to start off with an analogy. Um, I when I was in high school, I worked at McDonald's. Sadly, this was before the age of selfies. So, you've had to you have to do with my um just adding a McDonald's hat to a picture of me in high school. But when I worked at McDonald's, we had health department regulations and we had corporate policies that said

things like um you know, you must cook the meat to this temperature. Meat could only stay in the warming trays for 20 minutes. You had to wash your hands for 20 seconds after using the restroom, after handling raw meat, etc. There was a lot of rules and there was a lot of things and that was there because we as a society have agreed that food outbreak or

food poisoning outbreaks are really bad. uh both for the individual involved but also just as a society um you know if half the people at a company went out to McDonald's and then they got sick and then they couldn't work the next day that's bad for the company so you know there are a lot of rules that you follow when you're working in food preparation but also

you eat food at home um when I make food for myself for my friends or my family I still do things like wash my hands after I go to the bathroom or after I handle raw meat. I don't leave things out on the counter all day to thaw. Um, it turns out that even though a company made me do this thing, it just makes sense to do

at home. And that's really where I'm trying to go with the rest of this talk is some software supply chain security things are busy work that you should never have to worry about unless it's part of your day job. But there are a lot of things out there like wash your hands um that are really a good idea for anyone who's producing software or using it. Mark

Rinovich mentioned a few things this morning. I won't go into detail, but you don't have to wait very long for a new software supply chain security thing in open source to come up. Um npm is good for at least a few a year. We've had Shy Halude, Shy Halude 2.0, know and I thought I remember hearing something about a a new new variant of shy hallude very

recently. Um there's the uh hackerbot claw that was going through and compromising uh repos. Uh just I think I was on the train up from visiting my sister in San Diego earlier this week and was reading news articles about that. I was like well guess I got to add that to the slide All right so by now you've all agreed with me. and you said, "Ben, you're

a genius. This is so smart. I really care about software supply chain security now, but what do I do about it?" Um, Marinovich also stole my thunder on uh the OPS baseline. Um, I am a maintainer of that and the current lead of the SIG. But the idea is that we have a tiered set of security controls that open source maintainers can apply to their project um

and use that to improve the security posture. Um to going back to food analogies because I love food um you know it's not about ensuring the quality of your recipe it's about ensuring the food safety of the process you use to make it. um you can make terrible food in a very safe way. Um that that's that's for somebody else to figure out. Um oh, and I

should I should mention that um it is like a real honest to goodness open source project. We have a GitHub repo. We accept pull requests. We get a lot of feedback, especially some of the early stages. Um, you know, I kind of shared it out with some friends and he's like, either you don't mean what this reads like or you're just never going to get anyone to

adopt it because you don't know what you're talking about. And we're like, ah, yes, it actually did not say what we thought what you thought it said. So, we should improve the language. Um, so it is an open SSF incubating project. Um, so, you know, go check out the website. Um, I should mention there are a lot of things I will mention in the next few minutes.

Um there will be QR codes at the end and um I will upload the slides as well once I find the email where it told me how to Um so the bas the philosophy behind the baseline is uh fram because I could never think of a really solid e to make it frame. Um but the idea is that it's you know written by open source maintainers for

open source maintainers. So it's focused. There's no should. There's just must. There are a lot of great ideas out there. The best practices badge, OpenSF scorecard, a bunch of other things have additional things you can do if you want to be even more security posture. But these are sort of like the the things that are like really core. Um, and we want to make it realistic for

a project size and importance, which is why there are tiers, right? So if you're familiar with like sandbox incubating graduated levels used by CNCF and open SSF and stuff like that like not everything needs to be the most securely done out of the box like that's not realistic. Um we provide actionable recommendations. So specific things we don't want you to like all right now first go learn

what a threat model is and then think about how to apply like no just do this do that. Not all of them are as quite as like here click these three buttons and it's done. Um that is an area where we'd love some contributions and like or examples of real real world implementations but we really don't want to make homework for people. Um and the last thing

is meaningful which kind of ties back to focused is like there you can do it but does it actually protect against something? Um, I actually have some homework for myself of kind of mapping to like OASP top 10 and salsa threats and things like that because we want to make sure like do all of the controls we've come up with actually map to a real thing that

people should be concerned about. Um, so I talked about the three levels. Um, you know, level one is basically any code or non-code project should be able to do it. It's very like foundational stuff. And then you up go up to like level three where you're talking like the Linux kernel, Kubernetes, things like that. Things that are like the core infrastructure of the modern computing world. Um,

those should probably have a little more security posture uh built So yeah, the website shows a bunch of stuff. Um, you can't really read it because the screen is kind of dim and also you're there and the screen's up here. um you don't need to see the details but one of the things that it includes is a mapping to external frameworks. So um talk about that more

in a little bit but like if you're if somebody comes to you and says hey I need to meet these CRA requirements you can say well I'm OPS baseline level two and you can see I the level two requirements map to you know these CRA things and then they can go off and do their own homework instead. beyond the OPS baseline, if that feels a little daunting

to get started, that's Um, there are some basic steps that you can take just, you know, in the 10 minutes you have between here and going to the closing keynote while I'm talking because you've kind of tuned me out already. Whatever. You've got your laptops out. Let's go. Um, you know, basic steps like update your you know, if a vulner just because there was no vulnerabilities the

day you added the dependency, that doesn't mean three years later somebody hasn't noticed a vulnerability and fixed it. Um, the the fun thing about updating your dependencies is you actually don't want to do it too quickly. Um, because a lot of times what happens is somebody will have inserted some malicious code into a new version and if you happen to grab that right away before the security

researchers find it, oh crap, now you're compromised. Um, it seems like about a week seems to be the the general consensus of the people I've talked to of like how long you should wait for the nonsecurity updates. Um, you know, depends on uh, you know, your risk tolerance and all of that. Depends on how big uh of a lift it is. and you know, like, yeah, there's

a lot of dependencies and so there, you know, you're going to constantly be getting updates and it's kind of a pain to just like validate the build, merge it, whatever. Um, but we also know that the longer you let that stuff build up, the more difficult it is going to be to actually merge them. And at some point, you're like, "Oh, wow. Uh, there's this thing called

log for shell. I guess I better update my log forj version, but I haven't touched my dependencies in a year and a half. Now you've got a lot of work to do. Um, so this is one of those cases where like doing a little bit of work on a continuous basis does actually save you time at the end. Um, because you never know when it's going to

be suddenly, oh crap, I got to update all my dependencies and fix all of those um, new changes in behavior and all of that. when you're adding a new dependency, just kind of look at them, right? Like don't just, you know, you Googled for library that does foo and you get like lib fu and you're like cool. Um I think lib fu is actually a package. So

sorry if I'm disparaging anyone here. Naming naming is hard. Um but I don't know about you, but I am like the world's expert in finding a piece of software that does exactly what I want and then looking and seeing that it hasn't been touched in four years. Um, I don't know how many times I've had to redo the static site generation on my website because I found

a really cool tool and then they decided not to port it to Python 3 or they decided to just abandon it, right? Um, and it's not that software that hasn't been touched in four years is necessarily bad. It might be feature complete. It might, if it's very small, it might even have no bugs. Um, but it's kind of a bad smell. Um and for most things, yeah,

there's probably something that needed to change in the last four you know, you can also use tools like OpenSSF scorecard to look at the health um or you can use other metrics to like, you know, is it one person working on this and they are um they get to, you know, issues and pull requests once every few months. Is there sort of a core team working on

it? issues get responded to very quickly. Um, you know, is it well-maintained? Is there a breadth of contributors? Uh, so it's sustainable so that you can, you know, trust that when there is a vulnerability, it will get fixed. Um, that sort of thing. Um, and so like just those two, just kind of managing your dependencies. Again, it's not that it's hard conceptually, it's just that it's boring

and no fun. Um, but it does really avoid a lot of risk for you in Um, another thing that is obnoxious but also uh real quick win is just turn on two-factor authentication on anything that supports it. Um, if you're on GitHub, they added they made that mandatory a couple years ago now I think. Um, so basically if you have right access right access to any repo

on GitHub, you have to have two-factor authentication. And every time I have to pull out my phone and get the the soft to the PIN from the token, I'm just like, "Oh, I don't want to do this again because first I have to unlock my phone and then offy I put a passcode on that." So I'm like, you know, three steps in by the time I actually

get the little six-digit number I need. Um, but also I I understand why like it's really important and especially for things like package registries that has been a huge problem because people will just kind of disappear and if they don't have two-actor authentication, it might be really easy to guess their password that they created in 2005 when nobody was really thinking about secure passwords for stuff like

that. And so you get account takeover and now it looks like a package is coming from the real maintainer but the real maintainer has been on an island for 15 years um living the dream and now you're Um again with package registries if you're publishing to one um trusted publishers is a program I think it started in Pippi. uh Seth Michael Larson was a big part in

getting that started. Um but it's now expanded to multiple things and again it's kind of the same idea of like instead of having this longived credential you can now um use short-lived OIDC tokens and avoid credential leakage being a vector for um uploading malicious packages and affecting your users. And if you're on GitHub, this is a relatively new feature. Uh, I'm pretty stoked about it though. Um,

it's called immutable releases and the idea there is that with that enabled once you've published the release you cannot change the artifacts. Um, you can change the description, you can update the readme or whatever, but you cannot add, remove, modify what actually, you know, the the binaries or the source zip file or The reason that's important is you probably realize that git tags are mutable, which is

super convenient sometimes because let's say you have version 2.0 of your software, you tag it v2.0 and you tag it v2.0.0 and then you release 2.0.1 because you found a bug and you fixed it and that's great. So now you update that v2.0 tag to match the same commit as v2.0.1. That's a super helpful feature when it's used non-maliciously. Um, but it also means that somebody who

has the ability to modify tags on your repo can now update a safe tag uh to malicious content. Um, and so using immutable releases instead of relying on the git tag for things like that uh does just protect you from an entire class of vulnerability. Again, it's a GitHub feature. So if you're not using GitHub or you're getting your software from you know from a package registry

or something that doesn't help you but again it's a step you can take. Okay. So we talked about some of the concepts and the the broad class of things you can do. I wanted to give you a list of tools um that that can help. And I want to be very clear here. This is a small subset of tools. This is not Ben endorses these tools. Um

some of them I endorse, some of them I'm just aware of. Um so you know again use at your own risk. Software is provided as is, presentation is provided as is. Um so I mentioned the the QR code. So that has um it the recording will be on that site as well, but it also has a list of all of these and um also some of the

other concepts I've mentioned earlier on. Um, so I'll just talk quickly about what each of these do so you kind of have an idea. Um, Dependabot, if you've used GitHub, you're probably familiar with it. It's their automatic tool for uh opening pull requests to uh update your Very handy. If you're on GitHub, I recommend using it. Um, could be better to be honest. Like it's, you know,

very like, oh, this one. Oh, this one. Oh, this one. But it beats having to do it manually, right? And like that's the hard part is with boring tasks, you're not going to go remember to go do them because you don't want to do them in the first place. So let the robot do it for you. Um, if you're producing uh Docker containers, Docker Scout is a

tool that will look for vulnerabilities and provide you security reports on the containers. Um, as last I knew, that is only available either on paid customers uh or if you're a member of their sponsored open source program. Um, I should probably point out that not all of these are free as in freedom. Some of them are just free as in beer or free as in um give

me your information and I'll give you this for free. Um, most of them are all probably free as in puppy. Uh, GU is a project that I contribute to. It's uh in the open SSF and it is a a tool for um ingesting your software bill of materials which also is the first time that word has that phrase has come up in a talk. I think it's

a record 33 minutes into a supply chain talk and that's the first time I've mentioned sbombs. Um I'm really thought leadering out here. Uh but the idea is like it takes that data and enriches it with additional dependency data finds vulnerabilities and stuff so that you can say all right where in my like dependency graph is this vulnerability actually and how do I best fix it? Uh

I will caveat that guac is kind of heavyweight. Um, so if you don't have like a dozen different applications that you're kind of keeping track of, it might be a little excessive for you. Um, last summer, Red Hat contributed their Trustify project to the GUAC umbrella, which is a little better suited for um, you know, sort of single application supply chain analysis. Um, so that may get

better over time. Uh, Cousari Inspector um, I I work for them. Um it's a tool we provide to open source projects and obviously to paid customers that will do an analysis of supply chain issues in pull requests. So like oh hey this dependency is has a vulnerability update to this version instead. Uh hey you've got a problem in this GitHub workflow things like that. um LFX insights.

Uh if you're looking to adopt the open source project security baseline, you don't have to be a Linux Foundation project to uh start to start getting um metrics from that. Uh also provides a lot of community health stuff um informed by a lot of the work that Chaos and others have done. Um and it's free to just dump your project in there and start getting tools or

start getting analysis. So it is really helpful. Uh, Minder is an OpenSSF project that will allow you to do things like, hey, we've got five different GitHub re repos in our org. Let's make sure they all have the appropriate security settings. Um, and things like that. So, that's, you know, again, like if you have multiple repos, kind of a little bit of a sprawl, um, keeping things

together. Um, you know, there was an attack earlier this week or last week, I guess, um, where people didn't have the, um, must get approval before running CI tests setting on GitHub. Um, which, you know, it's great to be able to run CI tests as soon as somebody opens a pull request and then, uh, you know, get those results and then use that to inform your review.

Um, it's also really good to not have malicious code get read in by the the CI pipeline and do bad things. Uh, so it's an unfortunate reality that you should probably have that turned on. Uh, something like Minder can do that. Um, there's things as simple as npm audit. If you're using uh, NodeJS, you're using npm, just type npm audit every once in a while while you're

in your terminal and it'll just tell you like, hey, here are some vulnerabilities and packages. Um, it's easy to do. can even like alias another command so it runs every time you do whatever. Um, OASP makes dependency check. It again looks for known vulnerabilities in your open source Uh, and there's a cool little project called Zismore um that you feed it your uh GitHub uh workflow definition

files and it will look for all kinds of things um you know not pinning to specific commit hashes and and you're using tags instead not the best idea. Um you know allowing arbitrary code injection because you didn't um properly handle variable names and things like that. Um, so all these tools are fairly easy to, you know, at least kind of get started with and do some basic

things and then you don't have to worry about it anymore. It's solved or or not, but um you you at least raise the bar for All right. So, as I promised, here are some things you can do when somebody comes to you and says, "Hey, please help my trillion dollar company um not pay a fine that we wouldn't even notice because it's just change lost in the

couch couch cushions to us. You can just ignore them, right? Like, we're all good at ignoring things we don't want to deal with. That is a valid answer. No is a valid answer. Uh Daniel Stenberg from CURL has a a great approach that I really like. When somebody comes to them, he says, "All right, here's an invoice for me to do the work." And you know what

happens when he does that? I don't think anybody has taken him up on that yet. But you know what? If they did, then he'd get paid for doing that work. So he wins either way. Um, as I mentioned earlier, you know, if somebody says, I need you to help me with my CRA, you know, audit, you can say, well, we meet this this baseline level, whatever it

is that's appropriate. And then, you know, they can go look and see how that maps to the things they care about. And if they need more, then again, no or okay, here's an invoice is an option. Uh, and then the last thing you could do, it does not scale well, but I admire you if you're willing to do the work, is you can be super helpful and

just give them everything they ask. Again, it's up to you. You're the maintainer. You get to decide how you want to deal with these. Um, so there is a a sort of a scale from how of how helpful you want to be and you know, you should do what is appropriate for your project and your workload. Okay, so that brings us to the end of the prepared

comments. And now for the adlib section. Um, once again, here is contact information and the same QR code that you may have scanned a couple of slides ago if you want to scan it again. Um, or if you want to scan it for the first time. With that, I'd be happy to take questions. Thank you. Wait for the mic, please. >> Uh, first of all, thanks uh

for a great talk, Ben. Um, I really liked it. Um, I'm kind of like um a small uh source open source developer. I put a bunch of scripts on Pi. Um, I quickly looked through level one. It looks like I meet all of their requirements. Is there some badging or something that you do? That is a great question. Um, so right now the best way to um

get a a badging level is to go through the best practices badge um best practices.dev which I think I've put in the links there and if not I will go back and add that after the fact. Um so best practices badge is sort of a separate effort that's existed in the open SSF for a long time. Um, but they recently added support for basically you kind of

fill out it'll try and auto detect from your GitHub repo. Um, excuse me. Um, you know what can prefill and then you kind of fill out the rest and then it'll produce uh a little you know badge you can enable. Um, officially the baseline project we basically right now just say you know put in a read me or something. this project meets OSPS baseline level one version

uh I should know the most recent version but you know they're version by date so you know version whatever as of this date like we don't necessarily we don't intend for it to be something that you have to like manually reertify on a regular basis um because again like we're all volunteer maintainers and we understand that that's not realistic um on the other hand you could if

you choose to um so yeah so the best practices badge is the best way to get a badge. At this point, we do have a um add a station uh proposal to into that is being considered. Um so there be like more of a machine readable at a test station you can use. Um so you either use the badge or just self assert we >> more questions.

Yes, sure. Uh sorry me again. Uh so my second question would be um most I have a web page for one of the projects but I mostly just uh um upload the source to pi um from where people can download the source or the wheels or whatever. Is that the recommended way to do it? I know you mentioned Pi is a trusted publisher. So um once it's

given over to pi um everything else that's applicable is applicable to a pi pi. So um I'm guessing that um is there any way that I can say hey this is in the pi repository um so everything appable to them is applicable to the project etc etc. I'm not sure the way to go about doing that. Yeah. Is this still in the context of the uh OPS

baseline? Yeah. Um so most of the baseline controls um kind of treat the area your area of control as sort of like the the boundary, right? Um so like once you've you know however you choose to get it into Pippi, if you do that securely, that's good. Beyond that, you know, it's a Pippi then is responsible for it. So we don't um ask maintainers to take responsibility

for third party services things like that. >> More questions. >> Well, thank you very much. >> Thank you everyone.