Multisig Security

Transcript

and welcome to the May edition of the Defi Security Summit webinar. Um, welcome everybody whether you join us from YouTube or from the Zoom meeting. Um, to remind you all this week, this year's DeFi Security Summit will be held in Buenosirus in November. Um, stay tuned for the exact dates and more information concerning the venue by following us on Twitter. Today's webinar is about multisigs. Um, they've been used for over a decade in crypto and they're all over the place securing billions of dollars. But are they

safe? So, I'm moving the stage to the head of protocol security in Etheum Foundation, uh, Friedrich. The stage is yours. Thank you very much, Yuri. Uh, super happy to be here. It's a super exciting topic in my opinion. Uh we also have two amazing and super knowledgeable people uh joining us. Tay uh working with security at MetaMask and Mudit who is the CISO at Polygon. Uh both of them are also members of the security alliance.

So very high quality people uh who's going to present and uh have some discussions here today. Um I think Mudit wanted to kick it off with a short presentation about multisig. So Mudit the floor is yours. Thanks for the kind intro Frederick. Let me just share my screen. So I'm going to just reuse my slides from my last Devcon talk. Hopefully people can see it now. So this time I will use the same slides but instead of focusing on Lazarus I'll just focus on the multis bit in the slide. Um so yeah

the original presentation was about Lazarus and how to stay safe from them. What attack vectors they use u and it included some tips about multisix. So we'll just go very quickly over all of that things. So Lizard as who uh they are essentially DPRK they are state sponsored hacker group in North Korea and yeah we'll keep it quick and short for now. Um these are some of the top hacks by Lazarus which honestly you can just also say top hacks in crypto like all of them are Lazarus. All of the top hacks are uh Lazarus. It's the Scooby-Doo meme. You pull out the mask, it's always Lazarus under the

hood. Um, so how they how do they do it? So there's one common thing in the techniques used here. If uh you notice that is fishing like it always starts by fishing and fishing. Social engineering also includes fishing. So it it's just always starts by social engineering or or fishing. Um that's something to understand and focus on. It has always been fishing under the hood. Um but one more thing to notice well let's talk about social engineering first uh before we get on to more interesting bits. So yeah I'll give I'll give some basic examples of different social engineing

techniques being used right now. Uh some of them are getting more famous day by day. Uh first one is getting hired at your company. So they might just join your company. They might even work for you. They might do good work for a few weeks and just in on the side try to get more and more access and move laterally in your infra uh from within the company. So that's the most common one. Uh VC investment picked up quite a bit last year. it's still very active where uh especially targeted towards uh newer companies and founders um they would come to you and say hey like we are this big VC they can impersonate a real uh VC

and say hey like we want to invest in you they'll do some calls uh sometimes even I've seen them do legit zoom calls for first few times and then four time they will say hey like we are having some issues can you run the script can you use this different software for video call uh or whatever and if you if you do that then that's game over like as soon as you run an untrusted software on your machine that's game over. Uh same thing with news interview uh they'll say hey like I work for I want to do a piece on you uh you are now 30 under 30 on Forbes let's do an interview whatever and then they ask you to install their software or uh run the script to fix your network issues and then again game over.

um bunch of things like that. A more nasty one I've lately seen is uh uh like when applying for a job. So usually in the past I've seen okay, they will try to actually get the job and then uh go from there. But I've also seen lately like that some companies share um like a coding exercise or something for during the interview stage and they can potentially even compromise that. So they return you the solution here like you just run the solution npm run and you expect it to be okay. It's the code you sent but it's you're not you haven't

verified the changes they sent you back. you do npn run and it's it's game over. Uh you think you are verifying a coding exercise but you just lost your computer. So yeah, lots of things to be careful around fake docuign is very big. Um this yeah like it's people especially in the business side just click on docu docuign pages without even realizing what it is. uh they get a new contract open docu sign but it it's very hard to compromise them this way bunch of other ways uh I can keep going on and on on and on but that gives you a summary of social engineering techniques the highle idea is just don't trust anything uh

always double verify anything don't run any unsafe application on your system and you'll be fine how to stay stay from social engineing yeah be aware of different fishing fishing campaigns. Do awareness trainings, things we just talked about. Be skeptical of any unsolicitated communication. Verify identities independently. If someone says they are from Forbes, ask them to send an email from an FOB's uh email address. Uh avoid clicking suspicious links or attachment. Uh use strong passwords. Enable 2FA. Uh avoid SMS OTP. They are the least secure of the bunch. uh like UB keys are perfectly good hardware keys or if you

don't have access to hardware keys the ones on your mobile apps u and Google authenticator and so on are fine as well keep your software updated educate yourself and others uh limit sharing personal information especially now that $5 wrench attacks are getting more and more commons if you don't want to lose a finger don't post where you are uh on Instagram on your public profile You can post your photos and so on after you have left the place already. But just some basic object can help you stay safe. Uh and yeah like if you see anything suspicious, report it. Report it to your company security team or to seal or just post on Twitter. There would be a bunch of people willing to

help you. Like I I bet like if you just post a tweet on Twitter and you have like even a 100 followers and you say like can anyone help me figure out if this is a scam or not, you will get good responses there. We are a helpful community. Uh the other thing is if they are after you, they're going to get you one way or another. So you need to prepare a step beyond. Uh layers of security comes handy there. Fishing or humans, humans are the weakest link in security always. So they should never be your only link. But it doesn't mean you shouldn't secure that link, but you should have multiple layers. Going back to the original image, another thing to notice here is

apart from fishing like there's no hack which just happened purely because of fishing or social engineering. There there is always something else involved. Fishing or social engineering is just your entry uh into the infra. If there are proper layers in place, you would still be fine. So what are those layers? So number one and my most favorite one which people still don't do is principle of lease privilege like if you don't need access to something don't have the access like don't take on that liability and the biggest culprits here are usually especially in startups where it it's a bit like ego based that okay if

I'm at a higher level than you I should have more access like I should be admin of everything. It should be the opposite. Like at Polygon, I am not an admin of anything like not a single security tool. If if I need anything done, I have to create a ticket for it. Hey, can you change the Slack channel name? I need to go through it. I need to create a ticket. Everything gets logged and then IT people can do it or whoever has access in the company can do it. So yeah, just limit access to whoever needs it. uh don't have super users which have access to everything like there is there should not be a single person in the company who has access to everything like people should have specific access

for things they manage uh and yeah things just go through them have multiple factors of authentication always uh automated ways like 2FA via AI and uh hardware keys what we just discussed about but also in terms of communication If especially on Telegram, we have lately seen a lot of Telegram handles being hacked. So if you get a message from someone uh on Telegram and you know like this at least used to be their handle, but if the request is out of the ordinary like they're asking for money or something, just use another medium to verify their identity. Email them, call them, ask a friend, do

anything except asking them on Telegram, are you real? And you would be fine. uh then always this is especially applicable to more corporate teams which I would say is anyone over 20 people have MDR MDM/EDR on your devices um it really helps save 90% of the attacks like if if most of the hacks that have happened uh with uh uh with Laz Lazarus and DPRK if the machines that were compromised had EDR or MDM, they would have been caught.

Maybe they would not have been prevented immediately, but there would have been signals sent that okay, information is being transmitted to one of these blacklisted uh servers or domains and something is up and uh people would have started looking into it. Um so it's definitely important to have MDM/EDR especially for big companies. The only reason I say you should start thinking about it at 20 people or so is to balance security versus just like how quick people need to move. I usually recommend companies to have one security engineer for every 20 people you have in this space. Um that's a good tradeoff uh or a good balance of security/ IT

engineers uh per cost spend on them. Uh but yeah, definitely have it. Security monitoring and alerting super important. If we had proper monitoring and alerting lots of big hacks would have been prevented by bit hack could have saved if safe had proper monitoring uh and alerting. Um the horizon hack they would have realized it uh it happened like a week before they actually did. Uh so it's it's just lots of things can be saved and prevented if you have proper monitoring and alerting in place. Also make sure you don't have any single point of failure like a single developer should never have access to put push anything to production. Everything

should go through multiple reviews and approvals and so on. Make sure what you're developing is secure from an architecture level as well. At the end of the day we are in this crypto space uh in DeFi space because we want to trust code. We want to trust the architecture not people. So yeah, it's yeah, you just can't eliminate people right now, but at least you can architect your things that people are just a small part of the equation, not the whole part. U minimize trust on things, safe custody. We'll talk about this in detail. And yeah, just how have a spider sense like if if things are going wrong, you would have that tinglish feeling like if if something seems too good to be true, it probably

is. So yeah, just never give up on your spider sense. how to custody safely. So we'll get to multisigs with this um as multisigs are a way to custody. But just talking about the basics, first things I would say is if you don't know how to custody assets or if you don't know do if you have no idea how to do key management, just use a professional custodian. like it's good to learn by yourself but if you are putting millions of dollars uh at play just use someone professional c like Coinbase Prime Anchorage uh Fireblocks just just use a proper custodian and you would be much better off than trying to set it up all

your all by yourself. Now let's get into a more technical space where okay you are not day it's not your day zero in crypto space you know the basics uh you are techsavvy and you want to hold your own assets um then number one thing you need to do is use hardware wallets I know we have Taylor from MetaMask here but I think she would agree as well use hardware wallets use Metamas to use your hardware wallet but your key should live in a hardware wallet if you or managing any significant amount of funds. And this goes without saying, but I'll say it again because this believe it or not is the most common attack vector and like most of the funds are hacked this

way. Just seed phrase or private key compromise and even the big players get hacked this way. We just had uh one of the oracles of Lido get compromised by by a key compromise. So it it is still the most uh impactful attack vector here. Uh but yeah, don't write don't share your private key with anyone. Don't type it on a computer. Don't share it with support. Don't put it on in your N file in npm. Um just keep it in a safe uh if if it's a hotkey, keep it in a safe vault. Just do signing. Um if it's a hardware wallet key, don't put it on any digital medium. Just write it down

on paper. That's still the safest way and that's fine. And also, yeah, don't type your key on favor to send it to someone to print on an iron block. That that's also stupid. It's if you can't uh CNC it yourself, don't don't send your key to someone else to CNC on an iron block. Um, yeah, connect hardware wallets via browser wallets. that just gives you another layer of security in the sense that it is much harder to compromise MetaMask than to compromise a random D5 application you might be using um and connecting your ledger to directly. So just connect via MetaMask you verify everything is seems fine on MetaMask then you verify everything on

your hardware wallet if it seems fine you move on. uh if possible especially for corporates and people managing large amount of funds use dedicated semi-airgap devices for signing. The reason I say semi-airgapped is like what at least we uh try to push over at Polygon is these devices are not completely offline that would make it very impractical to work on. They have a whit listed set of domains they can talk to which include domains for security updates. They include domains uh of safe. They include domains of some private um security domains that we run on polygon. So it's semi-airgapped in the sense it can only

interact with whisted domains. By default everything is blocked. Um you can use that or if you want to be super safe you can also use a completely offline device. Uh but even just using a dedicated device is a good security step even if it's not airgapped. I usually like if hacks happen because you uh mingle bad things with good things. Uh verify what you are signing use multisig. Uh do I have dedicated slides? Okay. So multisig we'll talk about now. Um so with multisig there are few things. The first one is that you need to have a secure threshold for your multisync. We have had cases for example

the zks sync uh uh mint hack that happened recently they were using a multisig a multisig of a threshold of one of one so just don't do that maybe don't do one of one don't do one of two especially when you want security additional security go with something like so should have ti because it's at the end of the day it's it's all about uh like usability versus security. So for small funds, use 2x3 or even 1x3 if it's very negligible amount of funds.

But as things get more serious, move on to 3x5 uh 5x7, 9 by 11 as well in some aspects. And I think the biggest one we have at Polygon is uh 11 oh 10 by3 which probably you don't need unless you are managing something um super critical but yeah just keep increasing. So have a proper threshold number one. Number two still use hardware wallets. So the keys within that nosis safe should be hardware wallets. Just don't put in your random keys in there. Always individual signers should be hardware wallets. Uh thirdly, verify hash on your hardware

wallets. A good tool to use this is safe TX hashes from PC. Uh you can also use a UI that open Zeppelin built. I'm forgetting the name, but they built a UI on top of safe TXashes which is actually super handy, super useful. So use that in combination with the official UI from safe. You can also diversify the set of hardware signing devices um for your multisc. So you can have some of the signers on a mobile device uh using the mobile app from safe uh some on a Mac machine, some on Linux and so on u because it's much harder to compromise a diverse set of signers than just one

set. Uh you can even switch up the UIs. You can use uh official UI or uh you can host your own version. You can use an IPFS version. Uh you can use a completely offline version or so on. So build a mix uh based on your requirements. And the important part here is having a mix. If everyone is using the same set, it kind of defeats the purpose. Um but yeah, just have have a mix of u devices here. Uh do not ignore failures. I know in this space like things usually just work after failing 10 times for no reason. But when you're doing critical action, just focus on the failures as well, figure out why something failed

before retrying to sign something. Um because like you you don't know what's exiting from your hardware wallet. You see the error on your computer, but you don't know what exited from your hardware wallet. Maybe a perfectly fine maicious signature exited from there. Um so yeah just just stop and figure out what happened before moving on. Um those are some basic tips and like so with multisix safe nosis safe is kind of synonymous synonymous. Um like if anyone talks about multisig on Ethereum especially they they mean safe they are um the most trusted ones right now but they are also the one that just got

hacked a few months ago. So there are alternatives you can consider. Um I still recommend safe because they have improved a lot since the hack. So at least now we know okay now they are using a good uh architecture now they are focusing on the right things while for the other companies you might figure out at a later date if they are or not. Um so just use a safe provider. Um yeah that's the summary of it. Main basic talking points. I know Frederick has lots of questions and and I've overshot the time a little bit anyway so we'll move on. Uh back to you Frederick.

Yeah, thank you Mith. That was that was really good. Um yeah, there's been a few questions in the in the chat as well and if uh anyone else have any questions then feel free to to post them. Um I have uh a question for you T. Um so Mud mentioned that you know there are a lot of social engineering attacks happening and there were quite a few suggestions on his list. Um Mhm. which might be a bit maybe overwhelming for someone uh just starting out. Uh so do you have any like your top three tips of uh like areas to focus on to prevent these social engineering attacks?

Yeah. So sorry you guys can hear me good, right? Yes. Okay, awesome. Um, yeah, so there's I guess two ways to approach it. One is you become like aware and you live a very paranoid life and you have controls on devices and you have all the threat intel and all these things, right? And then that will protect you and prevent you from being socially engineered into, you know, uh, getting wrecked. The other option though is that um and in my opinion this is actually an easier way for most people to go about it is um to just not do important money crypto things on the same device that you live on dayto-day.

Um, and the reason why this is uh can be easier, especially for newcomers, is that what it what it means is that even if you do get compromised, uh they're not going to be able to steal all your money, right? Um, and so one thing that I think a lot of people don't realize is, you know, your iOS devices, your iPad, your your iPhones, those are just sort of inherently more secure due to the built-in sandboxing. That's a good place to do crypto stuff. It really is. Um, if you want to run around and be crazy and uh download torrents and play all sorts of video games and do all these things, that

should definitely not be on a device that you're also doing your work on, accessing AWS on, signing multisigs on, etc., etc., etc. Um, and then obviously like the threat intel and being paranoid and being skeptical and being aware of your surroundings and you know staying up to date on these things, those are also super helpful. Um, but if you really want if you if you don't necessarily trust yourself to uh detect all the social engineering, the best way is to just uh don't let those worlds collide, right? Keep keep some things over here and keep other things over here. Um, yeah, that's that's I think my best advice for newcomers.

Okay, awesome. Um, and would it I think I would argue that the MDM EDR topic is a bit spicy in our ecosystem. um maybe not so much in like large corporate level but for smaller teams and you mentioned that as well like if it's smaller than 20 you probably maybe shouldn't look into this but Isaac uh was wondering if you have any recommendations for uh EDRs or MDMs and also how complex these are generally are to to implement and what kind of costs there's usually involved with this for sure.

Yeah. So, for cost purposes, they have bunch of different add-ons and pricing plans and like it's it's like honestly the one of the most complex products you can buy. Uh, but you can on average get started with like $5,000 a month for the company for a small startup and then go up from there. Um, usually if you're just starting out, I recommend so like CrowdStrike is a good one. There are a bunch of others as well. Uh most of them offer a managed plan. So when just starting out, I really recommend get the managed plan. So they do all of the triaging themselves for all of the issues. And as you get more comfortable with seeing, okay, what was a false positive? They whitelisted it, what was

a real threat and so on. You can take it on yourself to do it, but I find value in just letting them do all of the ground work and us building just rules on top. So uh you would have to build u like a bunch of whitelisted things uh because ads usually don't like crypto stuff. So even if you are working on your actual uh blockchain no software they might block it. So a bunch of things you would have to whitelist bunch of uh DPRK things you would have to blacklist because you can be faster in getting intel especially if you are in seal Isaac and similar groups than these bigger companies are. U but overall yeah

when you combine their coverage and your coverage you would be uh in a good place and yeah is the uh EDR being SPOF is uh is a valid concern where EDRs themselves can be a single point of failure. uh but there are ways around it to some extent uh in the sense that one yeah like for signing you can for signing device you don't need to install the EDR uh on the signing device plus you can have much more of authenticated logging on uh EDR so like any anomaly is detected uh in time plus you don't need to give so if you have MDM you would usually have root

access to devices But for just EDR, you don't need to have a root access. So you can have EDR running just as an antivirus which can read things but can't uh really modify things beyond a certain level. So there are different configurations that you can play with there based on your risk appetite. Yeah, I guess also worth mentioning um is that if you do go with MDM for example um you need to be very sure that you protect the administrative accounts since that account is likely to be able to control most of the devices in your organization. So if that specific account is then compromised and

depending on the setup obviously then that could uh have quite severe issues. Um you mentioned hardware wallets and I I definitely agree that this is a like very critical area. um which in various discussions seem to be a bit of I'm not sure like why why the adaptation of adaptation of the hardware wallets isn't like going up as quickly as it probably should be and not being utilized in these kind of critical settings. uh you know you mentioned lido and there's uh obviously multisig and other parts where this is

potentially uh useful to to be used um do you I'm curious to hear both of yours take on this um but say do you have any ideas why this isn't like why are people still using software wallets instead of uh hardware wallets um I think there is you know And I talked to a lot of victims of a lot of different things. I think there's two primary reasons that we see. One is that um they have been fine for so long and they've never been hacked. So why why would I need to upgrade my security, right? And I think this is especially common in crypto where um the reality is

a lot of people are security aware. A lot of people have also uh perhaps uh grown up, you know, sort of on the edge of a lot of like deeper internet culture things. Uh and they're aware of malware and they've probably uh maybe even been wrecked by malware before. Um but you know, years ago in like a gaming environment or something, now they're in crypto. They're just like, "Yeah, yeah, like I know what I'm doing." Like it's not also like not that bad. But the reality is that crypto threat actors, what they're going after, the malware that is specifically targeting crypto people, it's just a completely different um genre, right? Like installing like um

like a game or a skin or something in a gaming environment, it's very broad. They're just trying to like grab everything. They don't really care who you are. In crypto, you're actually being targeted. Like you specifically, your colleagues, they know who you are. Um and it's not some general purpose thing usually. Um, and so I think people just get a bit complacent and especially if they haven't been if they haven't experienced loss yet, it's easier to just keep doing the same thing. The other one that we see a lot is um that uh for whatever reason their system or their processes or their whatever like either didn't allow for hardware wallets

or it was like much harder to use a hardware wallet or it would be another step if they had to do a hardware wallet. This usually applies to um uh systems that have like deep integration with other systems. So, for example, if you're like an exchange, um obviously you can't have someone like sign uh every single time a user wants to withdraw, for example, right? They'd be signing literally like potentially like millions of times a day. Um and so in that sense sometimes, you know, as as like say an exchange or another system as they're growing and the volume is going up, um they realize that they can't have all the funds in the hot

wallet that they don't necessarily fully upgrade the other systems for storage. Ideally, you want to have like a really um like a really you want to have different layers and different um sort of thresholds, right? If you're going to have a billion dollars in a wallet, you should you should not be accessing that very much at all. And when you do, it should require a huge amount of effort to do so. Um, if you want to have other levels that are sort of more accessible or like, you know, you're expecting that you might need to access those funds sort of um very quickly, right? Like say like within an hour, then you have to sort of like anticipate, okay, so what's the threshold that we're going to be at to be able to move those funds in an hour? Um, and then you have to say,

okay, and that's that's going to be a bit riskier, right? Like more people are going to have to have access. They're going to be moving faster, etc. Therefore, we should not keep a lot of money in this in this wallet, right? Either have more wallets, segregate by say assets, have a more diverse set of signers, like all of these things. Um, and so I really encourage people to like think about um, yeah, the you always want to be looking at the trade-offs and the risk, right? And if you find yourself in a position where the hardware wallet seems to be a blocker to be able to doing to do what you need to do or how often you need to do it, the answer is probably going to be adjust like the systems and and the the asset totals and like what these these

hardware wallets are protecting before you uh Yeah. before you just like write it off completely. Yeah. Right. So you could have basically a wallet which you don't interact with very frequently which might have $1 million uh which requires other wallets but then from time to time you transfer a smaller amount 50k or 100k or something to this other wallet which is less secure but also more agile I guess.

Yeah, exactly. And it's it's you know it's going to be different for every single team, every single system, every single set of circumstances. And it's also probably going to evolve over time, right? A lot of of what um what I do with my teams is we sit down and um if uh there's two indicators. One is that people are moving just too quickly. Things are getting signed too quickly. That's a bit of a red flag. the other hand is that the teams cannot get things signed and they're always complaining that they can't get things signed enough. Um, and there's like, you know, constant follow-ups on it. Both those are red flags that your systems are just not set up in an ideal place. You might not have the right signers, the right processes, whatever. But it's um it's it's a good indication that you should

just, you know, spend an hour, sit down, understand the situation, and then, you know, either change the processes, change the signer, change whatever. Because the reality is is that if you're in either one of those situations, meaning like you're either you either have people just signing willy-nilly or you just like people cannot seem to sign the transactions as needed um in an emergency situation or if something is compromised. That's you're going to be in trouble. So, better to fix it before you get in trouble is my recommendation. And there was a question in QA uh in QA chat now which uh is related to this in I guess uh which is about having different types of uh protocols in place

for different things. Uh so in this question it was about uh using a different mod protocol for proxy upgrades compared to other types of critical transactions. Yeah. And again, this is like these are getting pretty in the weeds and specific. Um I think that you really you have to understand your risk. Um I I do think that the the proxy and the delegate situation is a bit rough in terms of detection. Um however, it also increases the security in some other ways. I think one thing that most teams are probably underutilizing at this point, which is where I would recommend if you're going

to play with like the contract implementations and uh sort of like the nested system of smart contracts that you have, I would definitely recommend starting with um looking at like time locks over perhaps the specific implementations or how they interact or proxies or whatever. Um, I think that time locks are vastly underutilized. Um, and there's a couple different ways that you can do time locks where, you know, by default everything is just like held for 24 hours. Um, and you can basically like click the undo button and then if no action is taken, it goes through. But you can also, you know, set that up on a

faster timeline or, you know, have other um either automated or slightly automated systems that might sign off or or not sign off, right? And so by having this layer of things, you're creating opportunities to click that undo button in case something goes wrong, but you're also just spread like making the the attack service that much bigger where if they really want to steal that million, 100 million, billion dollars, they're going to have to like hit every single layer of this stack. And it just uh it makes it that much safer because it's that much harder to compromise all those layers.

Yeah, just adding on that definitely time lock in certain places 100% help. The more layers you can add the better. Uh for the pro like proxy upgrades though I'm personally not a fan of uh adding time blocks there and just contracts upgradability. Um this is a bit spicy topic I would say like first things where like lots of people might disagree with um and like honestly I was one of the first people to start working on upgradabilities uh like structures and had lots of tutorials and articles but over time like I've started to just like uh treat upgrade so I' I've gone back and forth

in this where I I've been like okay upgradability is the best thing just always do it to like everything should be non-upgradable and code is law and you should not upgrade anything. If it's deployed, it's deployed. And now I'm back in at a mid level where I I I'd say like okay like we have learned that we just can't write software that is bug free. So you need upgradability when you are building something for lifetime and you need it in emergency functions. So, I don't like time lock on upgradability, but I want a super high threshold on upgradability functions and they should be rarely used. They should not be used to add a donation function to the contract. They should only be triggered when it's absolutely mandatory with

proper due diligence and so on. um but without a time lock so you don't end up in a situation where so even the bigger protocols compound had a comp inflation bug where it was caught very early but the upgra time lock took 7 days to actually upgrade the contract and we just sat there seeing $250 million worth of comp getting drained or something like that. Um something similar almost happened with a sure how many how much detail they have already publicly shared but there was a dangerous scenario detected uh a patch was applied and then for 7 days we were just crossing our fingers hey like hopefully nothing goes wrong um nothing went wrong so that's

good but that was a close call and you don't want to be in those situations again and I'm sure like same thing has happened with a bunch of other protocols so yeah for security upgrade trades don't have a multisec uh don't have have a multisec have a multi don't have a time lock for all other actions yes have a have a time lock so changing some admin parameters and so on uh put a time lock in front of a multisig uh and that works well so I I personally do treat proxy upgrade separately from other transactions yeah but that's the important that's the important call out right is that you actually do have a completely different threshold and and controls on the upgrade. It's not a time lock, but I

think what at least one of your your your upgrades it had like a threshold of like 12 or some crazy number, right? Yeah, some the highest one I think is 11 by 13. Um, so yeah, we it is hard to achieve. Uh, so definitely need to have a secure threshold. Yeah. How do you feel about that mood? It's um like there is a balance obviously between security and usability. Um if you have a multisig with $10,000 in it, you probably don't want 11 out of 30 uh to control it. Um obviously there are different types of numbers uh that people should be

thinking about. There's a lot of different kind of security aspects that people should take in consideration as well. Um, maybe they shouldn't be focusing on threat to Intel the first thing they do. Maybe they need to focus on uh getting a hardware wallet or something like that. Um, do you have any thoughts there on like how to balance this? Yeah, it's very so every company needs to figure it out on their own. I can give general recommendation but it's very dependent on your use case and your risk appetite because even for like $10,000 if I was like a high school student I would have like 20 of my friends on that multisgram if I'm saving

that much amount of money. So it really depends on your situation. Uh but in general um I would say like for up to $10,000 even a hot wallet is fine. uh for up to 100,000 uh you should have a hardware wallet but don't need a multisig uh when you go to uh 500,000 you definitely need a multisig with hardware wallets and 2x3 is where I start u like you can if you want operational efficiency you can have a 1x3 multisig even on $10,000 so any one of three people can transfer those 10,000 but just when talking about security 500 100k 2x3

uh couple million dollar would be 3x5 10 million would be uh 5x7 4x7 and like 50 million uh I would say would get into the category of 9 by1 11 uh 10 by3 things like that over 100 million similar uh like up to 500 million I think like 11 by 13 or so it's same if you're going over 500 million just don't just split it up like unless unless it's a D5 thing you can't split if you are just an exchange or someone who is using it for cold storage just just split it up put it in a different wallet you don't need to move $500 million in a single transaction almost

never so yeah just just don't don't keep that sort of amount in single wallet yeah yeah exactly and then also like another thing that I think people um perhaps uh forget about is like when you first start using a hardware wallet, it's uh it's like a different flow. The same thing for like a Ubi key, right? It's like and it's also the same thing when you first turn on MFA. Um you're like, "God, I have to open my authenticator app every single time I want to log in.

Oh, so annoying." Um but the more you do it like um the more familiar you become with it and and the more that your sort of your workflow works around it and um I think like the first like few times the ease it it's the biggest burden right the same applies with multiigs and signers and the processes if it's not um if you don't if you don't do it frequently enough right you're not going to be prepared to deal with an emergency situation but it's also going be just like a burden to you and the team. Um, and I always think that when things are a burden, they're they're ripe for exploitation, right? Because people are naturally going to try to like take

shortcuts or, uh, you know, avoid the situation entirely. Um, and so when it comes to like teens that are say rapidly growing, um, and you know the amount of money is growing from like 10K to 100K to a million sort of practically overnight like definitely one definitely a hardware wallet and start using them like full stop. Um, but also start using multistakes. And maybe that doesn't mean uh switch every single thing around right this very second, right? But like the sooner that you start using these things, the sooner that you become familiar with them, the sooner you get used to the workflow and the processes that you need to do so securely, the better off you're going to be. Um, and

so often teams come into like CL 911 after they get racked. And uh, one of the hardest things is is basically trying to take this team um, you know, some of sometimes seven figures, eight figures, nine figures, right? um trying to take them from like zero to one overnight in reaction of incident. It's it's nearly impossible. Right? This is you need to be constantly learning, constantly iterating, and constantly sort of like um understanding your risk, understanding what you're capable of, what you're not capable of, adjusting things, iterating things, um having conversations about these things. Um and understanding what works for you and

what doesn't. Um I think that's gonna that's gonna put you in the best position to be actually secure and actually not exploitable, right? Based on um it becomes less about a money thing, but based on again like you know when Mood talks about risk tolerance, right? Or risk appetite. These are these are the things that are they're really specific to you and your protocol and your team. Okay. Um, so like from a risk point of view, there are a lot of things that uh users can and should do uh when it comes to

verifying transactions and so forth. Um, I don't think we have like that that alone is probably a one-hour uh session on all the steps that people should be should be taken. Um, a bit of a self plug. You can go to how to multi.com to get this type of checklist of things that are probably good as a user to verify uh before signing a transaction. This isn't optimal though in my opinion. uh I don't think that you know people users should have to go through 20 different steps in order to verify that a transaction is uh actually what it what it says it is. So, I'm I'm

curious to hear your thoughts about like what can be done on a protocol level or a wallet level um or a DAP level to kind of improve the current uh UX for this to ensure that users are safe no matter if they you know follow all these 20 steps in order to verify it. Do you have any thoughts on how how we can improve the current situation? I guess we can starting with it since you are not muted. Sure.

So, okay, this would be spicy, but I put most of the blame on wallets on this one. The the UX there is just just a nightmare right now. Like, it's it's getting better. Uh, but it it's still far from where I can tell my granny to go do a crypto transaction. Like it just it's it's not there yet. Um, we will get there, but we like we are still expecting for most transactions for users to just blind sign random things on the screen. um even when you do simulation simulations are rel relatively easy to sort of switch context on. So it's it's very

it's very tricky problem to solve but we definitely need more and more of security controls more um like uh so like at a protocol level honestly the account abstraction EIP that just uh went live uh which allows you to put code on on the address uh itself I think 7702 if I remember correctly that has that has a lot of potential for good security hygiene Um because then you can define rules at a protocol level for a transaction you are signing. Like if you are expecting to get like $500 uh for selling your 0.001 ETH then you can define it at a contract level in

the transaction like only do only move forward with this transaction if you get this money back. Um so you can add security that way. Same with uh transfers and so on like uh it doesn't exist right now will not exist in 3 months it will take time but over time like wallets will get smart that okay at one level they are seeing um these are the expected impact of this transaction they show these to the user the user verifies okay yes this is what should happen in plain English uh not gibberish not lawyeries or whatever um and then smart contracts would convert it back into protocol rules, put it uh in code and then submit the transaction. So

actually Ethereum verifies that what is happening is what the user signed for uh and then only the transaction happens. So there are lots of things like this which we can do. Uh we are getting there slowly like right now we can't even like on our hardware wallets do clear signing like Ledger doesn't uh let you convert things uh uh into actual uh readable things before signing. You just have to sign gibberish there. So we we are very far from perfect. Uh I know great minds are working on this. We'll get there but lots of things to do.

Thank you. Yeah. paid. It's Yeah, I know. The wallets wallets are wallets suck on this regard. And for the record, we actually blame the EVM. The EVM sucks. It's not human readable. That's the issue. Okay. Not the lawless. But the reality is, yeah, like there's a lot of things that are um uh just just sort of insane about how we do things and especially when we're talking about signatures and especially we're talking about um how transactions are constructed, but also how signatures are constructed to then make the multi-IG transaction. Um there's just a lot there's a lot of work that needs to

be done on that front. Um in terms of like you know you as the end user what are realistically right like really realistically what are some things that you can do. Um one thing is again going back to this like uh you you should be familiar with a multi-IG. You should be familiar with how these things work and you should do it in a lowrisk environment um before you do it in a high-risisk environment. Um, the more you get used to verifying the transactions on different tools and stuff, the better off you're going to be. Um, and then I think something that is always just really apparent to me when I'm talking to teams post exploit

about specifically multiix stuff or signature stuff is there were often red flags and sometimes they even detected the red flags. for example, like there were a number of errors that happened uh and they continued to click sign and be confused. Um, and a lot of times the public is like, why would you continue to sign? The answer is because uh because errors and issues happen a lot. Um, and they've always continued to sign and nothing bad happened, right? Um, however, you have to uh create, I guess, a culture and uh some I guess self accountability for things that are

unusual, right? And like just not sort of tolerate them. If you're getting into a situation where your team is so used to errors and failures that they're not a red flag anymore, I would recommend uh addressing the underlying issue, whatever it may be. Maybe that's the UI that you're using, maybe that's the wallet that you're using, maybe that's the process in general that you're using. But a failure, an error should be a red flag that something's wrong, and it should be something that people stop what they're doing and look into. Um, another thing is that [Music] um, people often like in hindsight they realize that what they were signing on

their hardware wallet wasn't necessarily like the usual thing. It's not that they could necessarily read it, but it may not have been what they were used to signing or there may have been some other indicator. Um, and again this goes back to, you know, sort of like understanding what you're doing, becoming familiar with it, understanding sort of like the flow on the hardware wallet, on your computer, on the multisig. Of course, like you should be like verifying all this information, but even if you don't, there's a lot of opportunities for you to notice that this doesn't feel right and this doesn't look right and this isn't normal, right? And all again, all those things are red flags that should make you go like, "Wait, hold on.

Let's pause. let's stop what we're doing, let's examine the situation, and then let's carry on if it's if we're 100% sure that it's safe. Um, and I think a lot of people just there's just so many situations where people are either distracted, right, or in a rush or um the the urgency of a situation or the perceived urgency of the situation, right? like uh they have to sign this thing because users get angry when withdrawals aren't processed quickly and also I need to pick up my kid from school, right? If that's a situation, you should empower your team and your team should be empowered to say like, "Hey guys, like sorry, like stop. I got

to pick up my kid from school. People have to wait a couple hours, but I'm not going to just click sign on this." And these are all sort of what I would consider like culture things um more than uh security checklist things. Um but they all add up over time and a lot of times those are going to be uh give you a better chance at not getting wrecked, right? Especially in in really broad situations like multiszig. Yeah. Yeah, for sure. And uh I guess an emerging threat here is also um Francesco brought up the uh the risk of AI uh moving into into this space.

Um I'm not entirely sure how they have been uh kind of growing into the whole drainer space and and and that but uh it is an emerging risk for sure. Um do do you see any what are you thinking about that and what kind of [Music] uh like there will obviously come improvements from AI as well from a defensive point of view? Um is there any like interesting tooling with that regards that you're excited about?

Yeah, on the offensive front, honestly, AI is most dangerous for uh the people don't have good security hygiene. Um because like now they are easier to target as well. When humans are doing targeted attacks, they only go for high target uh high value targets uh people who they have intel on and so on. So it's like very limited set of people that are being attacked. But when there is AI that can do uh like customized social engineering attacks, they will go for everyone. It's just the computers doing the work. It's same as like how spam emails got like everyone gets spam.

Like it doesn't matter if it's uh like a high net worth person or low net worth person. Same thing will happen when AI gets more and more common. um more and more social engineing attacks will happen at a lower level. Uh the good thing about AI and most tech is that it gets in the hands of uh good people before it gets h in the hand of the bad people ignoring governments in some cases. Um but what that gives us is like gives us an ability to build defensive tools before the offensive tools have been built and we are already using AI like if you know it or not like a lot in

our analysis anomaly detection and so on uh everywhere for security purposes. Um so over time I'm more like I I think like for secure folks or people who care about security they will get more secure by AI but people who don't care about security unfortunately will be a bigger or easier target uh through AI. Perfect. Thank you Munit. Um I see we're almost at the hour. So, we have a lot of questions uh still in the chat, but perhaps those can be transferred over to the Telegram chat that exist or something like that to be answered there. Um, but yeah, there's a lot of things to cover here. Unfortunately, we

can't cover all of it in one hour. But, uh, yeah, thank you. And, uh, Uri, I think you want to say something. Yeah. So, first of all, thank you Friedri Mudit and Taylor uh for teaching us on such a wide array of topics and equipping us with the information to keep our funds secure. Thank you all for joining us and asking questions and please follow us on Telegram and on Twitter. You can continue to ask more questions and be updated about next month's webinar and the DFA security summit itself. See you all next month. Thank you all.

Hi. Yes. Thanks for having me. Bye. Thank you.