New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Loading player…

How to Secure 12 Words on the Internet | Asta Li - Privy

Ethereum DenverWed, Oct 9, 2024, 12:00 AM

APPLICATIONS FOR ETHDenver 2024: #YearOfTheSpork ARE OPEN APPLY NOW https://ethdenver.com/apply

Transcript

all right we're gonna have orange slides today um hi everyone my name is AA I'm CTO and co-founder at privy and this is a a primer on how we think about uh web application security so to start off with like why why does this matter why is this different than was last year or the year before um it's because the DAP has evolved daps have historically been Thin Client wrappers around smart contracts and smart cont smart contracts the blockchain was your backend and your account system your user model was a users metamask and your dap was a thin bit of JavaScript tying it all together and uh providing some uis that make things look nice um but it means that all of of the security burden was on the user um and also on the smart contract side so users had to protect their seed phrase they had to download some thirdparty key management software to manage cryptographic Keys um they had to check their transaction hashes and parameters and verify their smart contract code and make sure they weren't signing anything that was suspicious uh they were fully responsible for their own security and that has changed so today we build apps the the DAP has evolved now it's um Rich user experiences that are accessible to mainstream audiences um they are largely built on a standard web stack and combin sources of web to data and data stored in a traditional backend and they use blockchain as infrastructure that provides incredible valuable properties like user ownership public verifiability interop posability decentralization but it's woven together with the rest of your stack and back end to provide an experience that is uh unlike what it used to be and that's accessible universally so the age of daps has shifted to the age of apps and what that means is uh a paradigm shift in terms of how we think about security as well um so to walk through some examples of uh consumer products and other products that are built with blockchain infrastructure that um that represent this phase shift um here I'm showing a screenshot of Courtyard um where you're able to buy digital Collectibles for a US dollar amount um it's a userfriendly presentation of a digital asset um you're able you know it uses userfriendly language and um you may not know that it's touching blockchain at all um this is another example of uh a product that's launched you know within the last couple couple years uh blackbird a restaurant loyalty app where you download an app on your phone and you check into your favorite restaurant and on your second visit maybe you get a free drink um and you get Fly tokens which are like Airline points but for restaurants and again you may not know that these tokens are onchain and there's an abstraction between uh your user and the low-level on train activity um hyper liquid another example you know oneclick trading with no wallet approvals you've got sending usdc via venmo um you've got connected to openc via email and checking out with a credit card and so again social apps all these experiences are hybrid web 2 web 3 Stacks um and this is a a paradigm shift from the adaps of the past so what does this mean for security because your app provides user-friendly context and an abstraction layer on top of what's happening on the blockchain you also take on more responsibility for security and Trust um and and this is really important like why why should you do this why should you take on this burden uh it's because we're in the age of building applications that use blockchain but also achieve massive scale and if you want to build an app that achieves massive scale that's that means you have to uh build trust in your product you take take on more security burden and you have to build incredible user experience um user experiences that are accessible to uh people who may not know how to custody cryptographic keys and that's like that's got to be okay if we want to uh build a product at massive scale so that's why we have to uh we have to think about application Security in an endend way and um you know build build apps that are deserving of the trust that widespread users uh place on these apps so how how how do we think about application security there's a few mental models that I wanted to walk through uh one is approach your application from the point of view of thinking through threats and building out threat models like reasonable um well structured threat models uh avenues for attack um mitigation mechanisms and and you know thinking through your system from a uh secur and threat model perspective um this is like basically the biggest framework for uh application security and um it starts with modeling your system like really understanding uh what do you care about what are the security requirements what are the kind of invariants that you want to provide and also like what's what's valuable um if people were trying to attack your application what is the thing they're actually going for is it data is it assets is it accounts like think about your app from the point of view of what could go wrong and what are people what do people who want to attack you what are they trying to go after from there think about how are they going to you know what are the things that go wrong like how are they going to try to attack those places of value um and this is not only like it's not only important to figure out what are the Avenues for threats but also to prioritize them because you're like a human with a limited number of hours in your life and a limited number of hours that your team can devote and so you have to attack the things that are most important first so prioritize by risk prior prioritize by value and similarly uh determine the countermeasures that make sense according to the threats that uh that you've modeled um so so bring this like structured thinking into your uh threat model process it's like really easy to build an app and like either not be thinking enough about this or be like losing sleep constantly and not know how to prioritize things because uh because there's like a million risks present and so um by breaking it down into structured components you like have a foothold with which you can start tackling these important security parameters the second guiding principle that uh has that's a a really important part of application security is defense and depth which is as you think about threat avenues for example someone trying to go after your user data um you can say oh well you know I have uh this password on my database and like call it a day but defense in depth is about thinking about what can go wrong and making sure there are layers and layers of Protections in place in case something does go wrong like why do we have MFA turned on our accounts well technically your like first login method should usually be fine like probably if you're logging in with email most of the time your email hasn't been compromised but that's like not the end of theory story you know your your user account is too important for it to be only locked down with one mechanism we want to turn on multiactor off so that you have another form of authentication in case something goes wrong and that's an example of Defense in depth which is um that each individual layer provides coverage but uh if you think about the multiplicative amount of improvement that you get where you know a 1% odd um of attack or or uh compromise is Multiplied against um you know the second layer defense which is like another you know like 1% risk uh you've you've decreased your risk um significantly compared to only having one protection so think about defense of your critical areas of value in terms of layers and uh and and think about those layers in a balanced way which is again like you are a human with a limited number of hours and you're also trying to build a great product that's you know achieving massive scale so how do you balance that against like maximizing the the places of um protection um you you focus on areas of greatest risk and it's like overall you want the surface of your product to have uh a balanced risk everywhere and that means places of deepest value and uh you know highest like cost if something goes wrong uh you build the most Protections in those places so this is like a part of a structured way of thinking about and approaching security and the last one is again we're trying to build um security applications that are also accessible to everyone and here you want to deliver an experience that provides both security and incredible user experience like the most secure application is one that nobody can access nobody can touch and then uh you know you'll like you'll be fine because uh nobody will use your app and so it'll be really secure but like that's not what we're trying to go for either um so thinking about uh security as a Hardline constraint um that you you then optimize user experience on top of and you have to think about both at the same time so those are four principles for thinking through uh online application security and here are some best practices to um you know in terms of just concrete things to bring these to life so one as a baseline protect your user accounts U build in strong authentication and authorization systems use MFA and also you know when you issue uh tokens to your user to um represent a validated account make sure you validate the expiration of those tokens make sure that you validate the signatures um set them as HTTP only cookies so they're inacessible to JavaScript um yeah so protect your user accounts and follow like best practices around these things uh protect your application code so this is really critical like make sure only the code that you expect to run actually runs in your app um this is it's not trivial like the internet and the browser are places where uh there's you know a lot of a lot of things happening and so um build in these defense in-depth protections against things like cross site scripting or csrf um an example is um setting a Content security policy this is a uh another part of a defense in depth strategy around protecting your client side environment um this is a policy that you should ship to a user browser along with your page that says hey um no other code except for the code that I really really want to run is allowed to run here so you can set things like a image source or connect source and say like okay my front end is only expected to make API calls to my backend and uh maybe to this like wallet connect server or maybe to this other thing and like those are the only three things that your front end should ever be talking to um and so you can ship this policy along with your client side code to the user's browser and the user's browser gets to add an extra layer of security and say hey the developer told me that like this client side code is not supposed to be interacting with like my malicious site.com and so even if something bad happened there the browser goes in and says um no we're going to uh you know prevent this request from happening or going we're going to prevent these scripts from running from these untrusted sources um and so s content security policy on your application um other major uh sort of source of risk is supply chain and dependency management um we may have heard of the The Ledger connect kit uh compromise from a couple months ago that was a mix of fishing and supply chain um compromise it's like one of the most significant sources of risk in uh software in the software development process and so um like pin your npm package versions you know make sure that only the code that you expect to run is actually running in your app even if it's Library code that you didn't actually write um so you know you're also shipping other people's Library code to your end users and you're responsible for that make sure your cicd is doing what you expect uh for for instance cicd is like the is the process of taking the application code that your team has like very lovingly reviewed and actually deploying it to your user's uh client but um it just just because your team has reviewed some code doesn't mean it actually is the code that gets shipped to your client and so there's an entire cicd process that you need to lock down to make sure that the stuff that you're shipping is actually the stuff that got written by your team and got approved um and then of course internal team security is essential like how you know what happens if someone on your team loses their laptop in a Starbucks like does that mean that someone can then ship malicious code to your users like it can't so uh look for uh places to lock down your internal security uh internal team security this is you know setting multiactor off on uh internal services and also um provisioning access with principles of lease privilege uh like this list goes on but here are a few things to think about and the high level is like there's like a there's a a laundry list of things that you need to do to make sure that only the code that you intend to run on your user computers is is is running um a topic that's close to a lot of people's hearts here is mitigating automated traffic um this is something where we see a lot of apps that are affected by Bots uh dods and uh Auto malicious programmatic traffic um so use use a web application firewall use dos protection you know protect with capture uh there ways to mitigate automated traffic Cloud flare provides all three Cloud flare protects most of the internet and yeah use Cloud flare uh another thing to keep an eye on um protect your user data so in addition to um you know the the account values that are important um your user data is also very precious um it has besides the regulatory concerns around user data it's also you know one of the things that is most dear to your users and that they are trusting you with and as a part of building trust you have to live up to protecting your user's data um so be careful about what you log and follow guidelines around user data privacy and so on uh there's a list of OAS top 10 uh web application security risks um this goes into a few of the things I covered already and more um so a great resource here and then uh the last one is like do inform your users too so uh the greatest source of risk generally for account security is actually fishing and it's like it seems dumb but it's like you're you know someone getting an email that says hey I'm your CEO please give me your password and then people do it like we've seen reports on Twitter of um some person pretending to be a Bloomberg reporter hopping on a 30-minute Zoom call with people in crypto users in crypto and like convincing them to share passwords and that's uh fishing is a massive risk and so um inform your users help them set up MFA and like don't have them install untrusted browser extensions and so on um so how we think about security at privy um we build with a secure audited architecture and crypto system defined uh designed with the principles in mind that I mentioned and defense in depth and we build customizable security features that are that adapt to your app and your user's threat models um and above all we think about it from a user first perspective users are in control self self-c stal it's user Sovereign um cool so you know how do how does this play out in practice like when you use an app uh with a privy embedded wallet on a new device takes like three seconds you're logging in you're recovering and you're good to go but what's happening under the hood is every application of all the things I mentioned um this is you know everything from like invisible bot protection to verified authentication to um cryptographic uh uh you know systems underneath the hood that make sure um that malicious activity can't happen um and you know much much more so um but the the outcome is you still have really balanced user experience you know the heavy lifting is happening under the hood um it's only happening on un devices and there's Progressive onboarding which means a user um doesn't even uh you know encounter uh like recovery until it's needed cool so at privy we do a lot of this heavy lifting we build secure authentication wallet connection and cryptographic Key Management we're battle tested um all the the customers that I mentioned before are built on top of privy um this is massive consumer scale um you know sort of protected by our infrastructure but modern application security is end to end it exists uh Beyond even cryptographic Key Management it exists beyond smart contracts it's a end to-end responsibility um that you know everybody has to live up to so together we work to build mainstream trust in the crypto industry as a whole every single online application needs to protect users and in order to deliver the kind of transformative user experience that makes applications accessible to every single user universally app developers need to take on more responsibility we have a a joint duty to continue to improve the user experience and security Baseline for our entire industry thank [Applause] you

Automatic transcript — names and jargon may be misspelled.