Vinicius Campitelli 5:27
Thanks, Dan. like to welcome you all. Thank you, Dan. Thank you, Brian, for the opportunity. Dan already introduced me my name is Vinicius Campitelli, you can say whatever you, you can. I’m from Brazil, I live in San Paulo, like then also mentioned, I’m here today to talk to you guys about something that we all hate, which is, right. So we don’t need the 10 anymore. We haven’t actually needed them for a while now, because of this standard. Even though it’s a standard that has been around for a couple of years. It’s still at early stages of adoption. But I’ll get into it. So what we’re going to see here, what we’re going to talk about here, basically, we’re here, lost my purse that I lost my my focus here on my keyboard. Sorry about that. So we will go over what is web authn, we also cover, I do care why it is standard about what’s going on? We’ve entered it. What does it look like? What it doesn’t look like? But actually, there’s so we also see what can be used with trouble work with web authn. What are the protocols involved, actually, is web open protocol, which is a standard protocol does have something that goes alongside with it. We’ll see. In just a few slides, we will see about something called ceremonies, what are ceremonies and what are the sermons that are, are happening in web offense. So that is something that we’ll cover as well. And finally, how you can implement it in the guys are going to see that it’s actually really easy to implement. So at least the browser stuff, the project stuff is pretty easy to implement. I’ll tell you something, the back end stuff, it’s a bit harder.
Vinicius Campitelli 7:35
So let’s start saying what is web authn. It’s another way to authenticate. So things invasion of computers of personal computers, we do have a way of authenticating ourselves. The web authn is just another way to authenticate, right? It requires something called an authenticator. We’re going to get a good look of of this decent health indicator in a few slides. So there’s record there, the information that we require something called an authenticator is authenticator to stay home, a great part of the cryptography, the private keys, we’re gonna see about them in a few minutes. And it’s what actually the browser’s interact with, but we’ll get to it. So hold on a bit. And like I said, it the main purposes of web authn is to remove the need of a password. So I’m going to go about a bit about the history of passwords and why password things, and why we don’t need stinking passwords anymore. But the idea is, the idea is to replace passwords when authenticating us. Though, it’s pretty much all about standards. So I’ll talk to you guys in a bit about who created who is maintaining this protocol. So you guys want to see that it’s all about standards. And why is that secure? How can we replace passwords with stuffing and still maintain the security? It’s because we use public and private key players, right? So we use asymmetric cryptography to handle the authentication process. And I’ll tell you guys, why’s why that something of concern why is that something that you want to do in our apps just start this off talk a bit to explain a little bit of something called a man in the middle attack.
Vinicius Campitelli 9:39
So imagine that that there is someone named Alice and Alice wants to talk to Bob. If you guys are not familiar with these names, they are very commonly in cryptography right. So instead of saying person wants to communicate with another person or system A wants to talk to system B, with just creating a few placeholders But when he bought back these placeholders, so if Alice wants to send a message, let’s say a message called M, bought, right, so when Bob receives that message, how does he know that someone hasn’t tempered that message. So imagine there’s another one other person in the middle of Mallory have a placeholder here for stuff that Mallory is. An intruder is someone that has an evil goal. And it’s eavesdropping, the communication but not only eavesdropping. It’s actually replacing modifying the message that Alice was about to sandbar. So instead of the passage M, Mallory, capture that message, and change it a bit or changes the entire message.
Vinicius Campitelli 10:44
And then another message. So I’ll just bought note that that message really came for us.
Vinicius Campitelli 10:52
There, we have public and private key pair. So imagine the Alice generated a key pair, public and a private key, Alice would need to send her key to Bob. So Bob would start Alice Q, in, in his theory assistant in his application, there are a lot of algorithms to do that. Probably the most common is the Hellman key exchange. But in this scenario, Alice would have her key pair her private parts of the keeper, curve her in her own device, and Bob would have Alice’s goalkeeper. So whenever Alice wants to talk to Bob wants to send a message to Bob, she would send a message and time her message with her private key, the signature. For those of you who don’t know, the signature is hash for the message. But it’s, it’s an authenticated hash. So we use the private key from Alice to generate a hash isn’t on the private key. But Bob has also been keeper. So Bob can use that book key to check the signature to validate the signature. So whenever Bob receives a message, you will receive both the message and the signature. He texts the signature as part part of the paper to check if they match. So if they don’t match, which would be the case, if Mallory or someone else will do stuffing words in the middle, like changing the message, the signature wouldn’t match. Because Mallory doesn’t have Alice’s private key private key is private, because you don’t need to send it, you will have to start somewhere secure in your servers, your server, your device, your theater, your phone or something like that. So even if Mallory could be somewhere in the middle, like I said, it’s called a man in the middle attack. So if Mallory is eavesdropping, the network connection is attacking the Wi Fi or something like that. Mary doesn’t have as private keys, so he can’t generate another signature for that message. So when that message comes to Bob, Bob is going to check the signature, and they wouldn’t match. So Bob could start a signature. And hey, that, hey, is not what I’m expecting. You’re not Alice. So I’m done talking to you. So that’s pretty much what private key cryptography for, like I said, asymmetric cryptography is all about, right.
Vinicius Campitelli 13:35
And this is the main standard for SSH for TLS. And a lot of secure communications all around the internet nowadays. So it’s something that relies on have heavy math to actually do some calculations. We have multiple mortgages, comorbidities are RSA and elliptic curves, which require a large power component computational power to actually calculate the large numbers or just 30 degree equations into something very hard to do with the computers that we have nowadays. So is the most secure way of talking to other computers or these systems. Actually, we have quantum computers in our house. But let’s hope we can have a few more years of this general cryptography right now. So the signature wouldn’t match and Bob would be the starting that. So this is what public private key cryptography is all about. Right? And that is what we have often uses under Jihoon. But before actually going into that, then we talk about bit something about something called Fido. Fido is a global organization. It was created in the 2012 a 2012 July doesn’t work. And I’m staking. It stands for fast identity online. So it’s running for fast identity online. It was a joint effort between each companies. If I remember, the people in Lenovo, what are some of the companies there? There were there in the beginning for Fido. And their main goal was work with protocol for authentication, without passwords. So they would call it password less authentication. And some of the later, Google and Yubico joins, and are you guys doing Yubico. But it’s a huge company that creates cryptographic keys. Everybody knows what Google so in join the FIDO Alliance is the that organization, but their goal was to create another protocol. They weren’t, they didn’t join the phyto. Alliance to work on the password less protocol to join to develop a second factor protocol. Google started using that protocol with their employees back then in 2013. And so finally, like I said, about standards is all about creating passwords, authentication process, and protocols. They’re secure. And they’re user usable for the web. So actually, this is part of an hour called Vital to vital choose the second version of a standard. And it’s also a part of two other protocols. So web authn is just one protocol. It has a complimentary protocol there, we’ll just take a quick look at it. We won’t get much to deal with that. But basically, web authn is a joint effort between vital allies. And so that’s what we’ll see. For those who don’t know is the World Wide Web Consortium, pretty much is the organization that is responsible for web standards like HTML, CSS, and XML. And their goal when they decided to join Fido gnarly to create this protocol, or to standardize their protocol across all web browsers. Right. So this joint effort is joint vamper, would become what we know as final should. Like I said, it’s something that we still haven’t heard about a lot. When I say we, like the among developers that aren’t much aware of crypto, but it’s actually been awhile for for a few years, right. So it’s been around for a few years now, was first limited to damages to in 2015. So eight years ago, it was the first draft we had achieved. It’s the candidate status for this specification in 18 2018. And it was finally standardized in 2019. So it’s been alive for at least four years of stable release, right? Okay, so besides web authn, there is another protocol called CTAP. And I’ll show you guys in the next few slides, what’s the difference between web authn and CTAP? What do they do and how they can complement themselves? Imagine that you have an online store, we’ll call it a possible supplement store, because we’re good at naming stuff. So we have online towards the cosmos comm store, you want to sell some stuff. So you communicate with the browser, right? Yeah, HTTPS I hope if you don’t use EGS in 2023 plus two, Let’s Encrypt been there for a while. Caddy has been there for a while. So please use HTTPS, your websites, your API’s in whatever backends you have, and your front ends as well. And the browser is going to communicate with something called the authenticator with you guys earlier about the authenticator, how you want to explain much of it, but it’s kind of a physical device or virtual device that we will publish, but we’ll get into that in a few minutes. So patients, so pretty much that’s what the user will interact with. The user will interact with the authenticator, the authenticator will direct the browser and the browser is going to interact with your phone Mind store which are right. So web authn is all about this part of browser in your app communicating with so web authn, just about that, and see that it’s the other part of the stack. Right? So sedap is about the protocol between the browser in the authenticator. Actually, sea tap is an acronym for clients to authenticator protocol. So pretty straightforward, right? Let’s see what they do. So we do have these two protocols that go alongside each other. We’re not developing browsers here. No module, guys, but I’m not. And I’m not developing any hardware devices to hold the values. So I won’t talk much about C tab. I’ll focus on my mouse. But nobody asked me, Hey, do I need? Yeah, buddies already have a login process? Sorry, I had to have a form there with user and password, already implemented two factor authentication via email or via push notification or via a Google Authenticator app or something like that. So why do I need to change my app to do that? So again, let’s go back to our star, or Cosmos Wildstar, where people want to buy technical things. stuff, right. But they have to log in, right. So pretty much what ERP already does. So they have to log in to see their status to see the history for the purchase they made to save the maintenance that they do want to buy in the future, like clown hoses, or that maybe they want to purchase some funny hats, or their own circles. But you want to focus on we are already your audience, not someone that is a heavy user, not a hard user for the computers are in smartphones, or something like that. So it’s not a tech savvy people. So they’re not tech savvy nowadays, so you want to ensure that the users can log in because you need to protect the resources. But you also have to make sure that things are easy to login. Because one of the most frustrating things that we have is when we are about to buy something, and we have to login. And we forget password. So we have to go there and recover a password that sends us an email. We don’t have passwords to access anymore. It’s an old email that really like 15 years ago, we don’t remember the password. So not easy, right? Backwards are not easy passwords. They have been around since the mid 60s. So passwords are on for six years now. And they are hard. Yeah, hard to balance for a user. Because especially for users, they’re not heavy users, like I said, because they can be simple enough, because otherwise other people would guess it. Funny story here in Brazil, last month, there was a there was a data breach. And like our DOJ, the equivalent for our US DOJ was a data breach. And the hacker just went to do to the jury. And he said that he found passwords like 123 change in Brazil’s DOJ, someone really left out 123 Change Password there. So that, but that’s what should be simple enough for the user to remember. And at the same time, they should be hard enough or awkward or system or someone who doesn’t crack it. So people take the ball for years or 1000s of years to crack a password. So it’s really it’s very hard to get this right amount of badness. One curiosity. I don’t know if you guys know about it. I hope you do. But there is this website called have I been pounds and website I suggested just that if you don’t know it, please register yourself there. It’s pretty much a unique location that that informs people that tells people when there’s a data breach with their email. So if your email has ever been hacked, ever, ever been partnered is gone notify you’re saying hey, your password has been leaked. Data Breach phone company X. So please go there and change your password. Make sure to change all the passwords as well. So it’s a great website. And it has 12 point 6 billion. But the accounts account stuff have been leakage there. So passwords are heart. They get reused, right people use the same password. I don’t know you guys, if you guys do that, please don’t don’t use the same password, right? Create different passwords for for your, for your different services. So, just to prove your i this D, the first digital password that we have record off was ziens t 6561. Sorry, 61. System from MIT called CTSS. If I’m not mistaken, supposed to mean compatible time sharing system. So it was the first system to ever use a password. And the first data breach was in 65, in that same system. So the first reason to ever use a password was the same system to have ever have a data breach or the password. So interesting, right? That’s why I said that password stinks as easy to get, get a breach, get a data validation, get a leakage or something like that. So then everyone else like the bar, or the it cloud with each cloud would love to put their hands on the basis that would have passwords, or backups that aren’t encrypted with hazard passwords.
Vinicius Campitelli 26:41
So we should go through shorter alternatives, right. So what are the alternatives that we have? And thinking about it actually, the thing they stick to because for, like I said, for people that are very tech savvy,
Speaker 1 27:00
if they use a password manager, don’t think that no hard end users use a password manager. But if they decide to use one, it’s very hard to get the right. And, yeah, a lot of options in the market. But if you are, if you don’t have a central server, like a bouncer, you’re going to have different passwords on your phone or on your laptop, or tablet, or desktop, or home, or desktop for your workstation or something like that. So it’s very hard to synchronize all those passwords, right? And other thing, who watch the watchers, right? There has been a lot of data breaches in those password managers as well, because it’s a very, very valuable product, right? So imagine, for for those scared, folks, for those clowns, those scary folks, right? From the previous slide, they will just go after this is solutions, because they they store passwords for 1000s, or millions of millions of users. So they’re very, very valuable targets. And I’ve been using password managers for a while now. And some sites, they don’t work well. Because if the farmer logging doesn’t have a very good experience, I don’t mean their their farm fields correctly. So maybe the app doesn’t know about it and can’t autofill the password, because he actually can see that there is a login there with a username and password combo. Or maybe there are some forms that first ask your email or your user. And the next step is going to ask er your password. So some non standard login forms can break those those apps as well. So have trouble Derek, cop, copy, and paste. So it’s not very soft, very good experience for the user. Okay, but I can add a second factor of vacation, right? So I can multi factor authentication is that it’s great. You should add multi factor multi factor authentication to your apps. But again, it’s another very hard thing to get right because of the US. Because we can have some experiences that aren’t that great. Like, hey, I’m about to buy something, I need to grab my username, my password and any children my phone, hoping the authenticator app and type of goes from there like a six digit code or something like that. Or I receive according my email, I decode those, those long time passwords which what are these codes are about? They have a window of time window that they are valid. So maybe if you’re blocked On your computer or your device is not synchronized, it’s gonna get you wrong code. So not that easy. But again, you should add even with two factor authentication, there are some methods that are that they like SMS. SMS are, are very widespread, but they have some security flaws. Especially when, when targeting some other countries that use some older versions for the protocol. Again, here in Brazil, a couple of years back, we had a minister who has his data, who has his cell phone hacked with some, it’s due to some SMS flaws to take care of when sending codes. The SMS prefer emails or push notifications are the standard Google Authenticator app that of SMS. Users can be fished, right, you users can receive a phishing email, saying something asked me something. So very easy thing to do that just called some, I could call up the person say, Hey, you just received the call, I need to type the code here to continue if they say or continue to support, or in order to apprise author price or something like that. So there are a lot of phishing campaigns. So users can’t be fished, right. And another thing that we sometimes we forget that we also have to require two factor authentication in some scenarios, we also instead, besides just the login process, we should ask for the factor, vacations, communications, some some parts of our system that requires like a change for the car, like changing the credit card, or changing the email, or deleting the account. So those are processed, those are our workflows that should require factor authentication, we call that step up, authentication. But there aren’t a lot of people that remember to do that, it just put the two factor authentication process in their login and they forget this parts, right. So again, a great feature, but it’s easy to get lost. We could use an SSO Single Sign On process. So all all of our Asian and authorization policies would go in that system. Like everything, we don’t have bullet proofs, we don’t have silver bullets, everything as a as a problem. And in this case, is because you’re depending on the third party service, if this dish is perfect for third party process goes down, you don’t have logging anymore. Or if you have something going on with the business part and you need to deal with a new contract or something to to maybe some part of the negotiation for the new year or something like that. What happens if the third party solutions asked for double the price is three times the price that steady or are in pre. So it’s hard to depend on someone else. But again, all these things have their pros and cons. So it’s just like a matter of fed up of balancing them and and weighting them are. And that is something that I’ve often offered. So it’s useful feature of rocks here. Because web authn offers that’s the first thing it offers security. There was, like I said, it’s the same technology that is used in SSH and in TLS are the private and public key cryptography. Only available on TLS. Two, you can enable HTTP only server. So in this case, those those information data information is not being transmitted in a secure channel. So that’s very good. Another thing that we’re going to see we have something called the relying party ID and take a look at the person. The browser itself is going to validate the information that is being transmitted with the domain name for the server, or the start date that you’re browsing. So you can fish users using a site that looks like your site. Just change something the URL something because the browser itself when deeds did the domain name, it’s not part of the developer to do that. So it has a standard security process which the browser does Like I said, a lot of parts, smartphones, workers on this standard, by the way, Google PayPal Yubico, we have the W 3C, gathered stands. So very, it’s very secured. And it’s very safe to use that. And another thing that’s very cool about web authn is that the actual, meaningful piece of information stays with the use. Server side only stores public keys, like I told you guys in there, Alice and Bob communication example, right? It only stores Alice’s public. And someone tend to tend to do anything with the public, private keys to a meaningful part of education. So even if someone could get their hands on a backup, or the actual database dump for server side application, they couldn’t do anything. Because like I said, the private keys they with the user, so they have nothing just yet. That’s very cool, right? The user experience is better because the process is beating in browsers. So they would have a standard way of logging and registering e applications via browser interface. So we don’t have the different user interfaces for the login process itself. So if someone use Safari or chromium, pay for Firefox, etc, all the logging process would be the same. After logging burdens, click it. It’s all the browser that does the heavy lifting.
Vinicius Campitelli 36:42
Oh, that’s pretty cool for user experience. Another thing that there are no better studios, because you don’t use passwords, the private keys will be stored in the authenticator. And it’s phishing resistant. Like I said, the browser validates and verifies the domain name. So someone can just send you a email saying, Hey, I’m Osmose Southstar. But we could see in Cosmos, I need your password or logging here to see our latest update, or there was something wrong with your purchase, please login to see updates. You wouldn’t work closer with verify the domain name right. So and another very cool thing that I will see. Again, in a few minutes, you can combine two factors in one. And I’ll explain a bit more about it when I see when I talk about user presence versus user verification. But it can combine two aspects of security. So that’s pretty cool. Hold on to that thought. And I will get back to it in a few minutes. Another very cool thing about reablement is that T Mobile, they they went to two offers for identity diversity, a lot of guys heard of it. And they showed the report that they have implemented web elfin in their app. And they made a survey with their users. And it seems like 80% of the users using often methods instead of password. So we have a huge company with a real market base with users that actually are referring back often. And we’ll talk about what titles methods like biometrics interesting for that, instead of actually having to type. So that’s pretty cool, right?
Vinicius Campitelli 38:45
Vinicius Campitelli 45:32
Vinicius Campitelli 48:18
Vinicius Campitelli 54:59
They also have this kind of off, put in cages like Windows 11. If I’m not mistaken, always come from such a TPM Trusted Platform Module, which would be responsible for for storing those keys. Mac devices also come with them. So you can use Apple’s Touch ID to use to store keys. Android phones have the TPS do change that your devices have TPM T, as well. So you don’t actually need to buy those internal keys if you have devices from the past few years, like Windows 11, or newer Macs, and Android and iOS devices. So you can use the built in solutions for your own platform. That’s pretty cool, right? The only thing that I would say is different from those external hardware, they are being changed or their software, right. So not easy to get a key from Android phone on others. So we should never lose that Android phone, you are using those keys for the web authn has a new standard, that’s right to bring down synchronization for the key. So even though you’re using the building module for your device for our platform, you’re still going to be able to synchronize with the cloud and restore it if you ever use the device. So that’s pretty cool. And also, Google Chrome has a virtual device where you can enable from the, the console to for developing purposes, you can just open the console, go to Mark tools different I’m mistaken. And you can enable Web authn there any, you can create virtual devices to actually store and retrieve credential. So that’s pretty cool. I use that a lot for for developers. If you guys want to see how that how that works, just open our Chrome console and enable Web authn. Like I said, browsers, they use CTAP 2, to to communicate with those authenticators. So it’s not part of the job to talk about that. Because we’re not building devices. When I’m building browsers, we are building web apps. And that’s what well that often saw about. I know that I have a question slide here. But we will charge time, I’m going to skip it and just talk about the ceremonies. And then we can leave room for some questions. In the end, if you have time. To basically ceremonies are the process of login and registering they, they have some cryptographic features as well, which we’ll call attestation. And assertion. Basically, whenever we the browser calls the authenticator to sign a message for a login or for a restriction process. The authenticator should return a certificate using the private key that made it and that certificate has a lot of information about the device. So you can know if the Vindicator is a UB key, you can, you can make sure that your indicator is using elliptic curves, or you can make sure that your indicator is not a beautiful device or something like that. So even though you can just leave this settings, restricted, you could have stolen some sort of constraints to make things even more secure, even more restricted. But personally, I would only recommend this kind of constraints, you are creating, like a banking app or something for the government, because it requires a high level of, of, of security or something like that. Because if you know too much about the the educator, you could have some problems with the GDPR because you’re storing data for the user. So even though you could retrieve and save information about the user ice user indicator process, I don’t recommend doing so. Solid indication is, like I said, just that simple process. And the difference between registration is actually that the browser would need to send users public key to your causes cluster right? So remember, when Alice was talking to Bob needed to send her public each book is the same thing the browser needs to the browser receives the challenge from the backhand that’s done to the to the authenticator and the authenticator calls the user for ASAP pitcher do something like that, and then generates a key pair, it will be securely store the private key within the the device. And it will return the public key with a certificate to the browser. So the browser could send that public key to the back end. And then our backend should register that public key under that username. So imagine if I’m registering for Vinicius dot Capitole, at version of.io. And I receive that public key for initials, I know that every time that Mrs. Wants to logging in would have just send me some information that I can check with. If the public key so it’s pretty much the same Alice and Bob, except there are a lot of other few things that you can do, you can have several public keys are the same user, it depends on the business logic that you have. Maybe no one allowed that maybe just want the user to have a single source of login like that their app or something like that, their their phone. So if you want to allow more than one login more than one device for a common cloud store, I would say that you don’t want to have so such higher constraints or requirements for security. So you could allow the user to register several public keys for his username. That’s also pretty cool. But it’s part of our business logic for the backhand itself. And that’s part of the protocol. But it’s a fun thing to mention, right. So just this process is the cool thing is each website whenever there is a process of signing up, the authenticator is going to generate a key pair for that specific relying party. So it has private keys for Cosmos Pastore for oppo is great a con for Amazon, or for CFE.dev. So it has different private keys for each one of those sites, right. Just to finish things up, the registration entry point for your browser API is pretty much the same.
Vinicius Campitelli 1:02:23
The differences between not get in Morris create so just called navigator dot potential rate. And you should pass desktops actions, which would be the relying party ID, user name or user, it’s been a challenge that your backend created. You can also say that you want to use elliptic curves with DSA. So that’s what that meant minus seven stands for an algorithm identifier that stands for ECDs DSA. So you can have such constraints. So that’s pretty cool as well. We’ll see the relying party the user to read the challenge from the back end. And you have some constraints about type of, of algorithm that you want to allow. Again, it’s a promise. So it’s going to resolve to the new credential info, revenue, credential info has a lot of information, like the challenge. And he also has this object called the attestation object, which has the Credential ID, the credential public key, this is the this is the object that you need to send to your backhand, right? Because you’re registering the user. So you need to send this information to the back end to the back end can store it in their database. Again, the only thing that is stored in the database is the public key. So not valuable at all. The only thing that can generate certificates are the private keys that are safely stored. Procedure. Normally, we use what about when, when registering, we need to ask some other kinds of information. So the user could ask them app could ask the username or the email to associate that public key. Right? So imagine you go to Cosmos club store, I click I want to register the store. Well, that’s okay. So what’s your username or your email? I will delete my email. And then when I hit next, we’ll send some information to the back end. The back end would return Okay, I want to register the user who is stylish and then sit up with
Vinicius Campitelli 1:04:47
Dan Moore 1:08:24
Yes, yes. That was amazing. Thank you so much. You cover a lot. I know you had to skip some things due to time constraints, but really appreciate candy in depth. Look at that. So thank you, Denise. Yes. And thank you, everyone for joining us for this session about how we can avoid stinking passwords. So thanks for your time. And don’t forget two weeks we’ll be talking about sessions and awesome continues. And we’ll we’ll see you later.